scrum编程读后感

我认为可以借鉴的一些方法

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可以再提交测试前消除