我认为可以借鉴的一些方法
1. 任务要进行分解,且分解后的每个unit的粒度不要太高,按照我自己碰到的一些开发时间在2个月以内的项目,建议就不超过3个人日
2. 任务要有阶段性成果,即即使整个任务的开发需要2个月,那么建议将2个月分为几个milestone 而每个milestone都有可以交付的可展示的成功;而
不必等到整个开发结束
3. 对于某个任务的时间估算,建议大家彼此估计然后核算
4. 要充分考虑注入会议等非直接有效的开发时间,也就是说要考虑团队的生产效率
一个简单的计算公式 生产效率 = 估算出来的任务人日 / 实际完成任务的人日
注意: 这个估算出来的任务人日,不应该再计算入请假,开会等消耗;
因为整个项目的生产效率在开发前需要有个预估,本来就会考虑这些因素
5. 用wiki等方便的工具,罗列展示大家的进度和成果,定期更新,个人自己更新,让别人知道你分到了什么任务,正在做什么? 整个项目需要完成什
么? 目前状态如何?
6. 如果有可能最好跟踪实时工作效率,比如燃尽图,这样方便观察任务被完成的速率和趋势
注释: 燃尽图(burn down chart)是在项目完成之前,对需要完成的工作的一种可视化表示。燃尽图有一个Y轴(工作)和X轴(时间)。理想情况
下,该图表是一个向下的曲线,随着剩余工作的完成,“烧尽”至零。燃尽图向项目组成员和企业主提供工作进展的一个公共视图。这个词常常用于敏
捷编程
7. 每日最好了例会,时间控制在半个小时内,有问题就说,然后进度更新,散会;复杂问题等线下讨论
8. 每个阶段的结果必须能够展示,而不是用嘴巴说
9. 做项目回顾,检讨,如何做的更好,如何提高效率等
项目的质量保证
1. 如果有条件的话,可以规定一些代码风格,以及强制使用一些framework来降低自己开发代码的数量
2. 必须要有一个测试程序,充当开发者的看门狗,进行冒烟测试,并且不断添加case到这个程序中;这个程序的目的有点像单元测试,但是也不完全是,它可以将曾经发现的问题path,condition等逐一加进来,以后每次要打新的包,就用这个跑一遍,如果能够通过就可以排除一些基本问题。
3. 每次新打的包,务必让每个参与者先用一下,确认下bug是否真的fix了
4. 如果再有条件建议可以对核心模块等进行单元测试,但是最好能够有个比较好的单元测试框架,而不是胡乱的堆砌代码
上述4条,我也是根据我实际工作,以及团队情况来总结的,当然如果有更好的能力,经验,完全可以做的更好,但是上述几点做好,基本上很业余,疏忽(比如遗漏提交文件等)导致的bug可以再提交测试前消除
阅读(643) | 评论(0) | 转发(0) |