Scrum实施总结1

1、Task一定要细分。即使一个功能再微小，但如果它涉及了多个模块，那么就按模块来分成多个Task。
2、Task的描述一定要细致。但要注意，Task是以用例的方式去描述的，即Task是从用户的角度去描述，而不是从技术或是设计角度去描述的，除非这个Task是一个纯技术的Task。
3、“重要性”不仅仅是体现Task的重要程度，还包含了它的“紧迫性”。其实紧迫性高（马上要解决）的Task也就是重要性很强的Task。
4、backlog仅仅解决了任务分配的问题，却没有解决任务监督的问题。对Task的Review是必要的。Review的时候就体现出Task用例的好处了。
5、当Task很多的时候，优先级高的Task很容易被淹没在大量的低优先级Task之中，所以backlog一定要有突出高优先级Task的功能。
6、会前最好有10分钟左右的准备时间，让大家再过一次自己的任务，或者对昨天自己加的任务有一个简短的描述准备。
7、开会时保持站立是非常有意义的，一定要坚持。
8、不要用粗暴的行政命令强制指定Task的预估时间。Task的预估时间一定要全体团队成员在平等的基础上商议，并且取得一致的结果。

9、切忌在开发过程中有人不按照backlog来工作，而是自己即兴安排backlog中没有的Task。这样会打乱团队的整体计划，导致整个团队无秩序。所以，只有经过评审的Task才能被成员领取，严禁任何人去做未评审的Task。

11、没有Sprint就不能决定迭代的周期，也就无法定期推出可交付的产品。因为Task是不停地增加地，如果没有一个发布日期，那么随着Task的增长，发布日期就会遥遥无期。发布无期限，会让团队情绪低落，没有成就感，觉得工作永远没有尽头。

12、没有Sprint就不能细化一个迭代目标的Task。Sprint会提出一个发布目标。发布目标包含两个因素：发布日期和产品需求。产品需求不确定（我们发布时的系统要实现什么功能？），那么迭代只能凭项目经理的感觉，而这种感觉是非常不可靠的。同时团队其它成员会变得没有责任心，觉得产品发布只是项目经理的责任，与自己无关。

13、预估时间是“以人为本”的思想的最佳实践。预估时间的评价有一个重要原则：一定要在平等的基础上进行，并且评价过程是以友好、平和的气氛中进行。切忌两点：一是以权压人，二是无理抬杠。预估时间运用得好能促进团队成员的责任感，使得团队作为一个整体向着同一个目标前进。

14、废止“预估时间”，改为用“点数”来衡量Task。一个任务我们可以估量出它的复杂性（技术、所花的时间等），但无法准确地估计出所需要的时间。我们通常靠一个参照物来估量Task的预估时间，例如A需要一天的时间，而B的工作量比A大一倍，那么B就需要两天时间。但如果A的时间是不确定的情况下，B的时间就没办法确定。
Scrum采用迭代估算的方式来预估Task的完成时间。Scrum不会单独估算一个Task的所需时间，而是采用一个Sprint完成了多少个“点数”来估算下一个Sprint能完成多少个Task。如果我们在6个星期完成了120个点数的Task，那么我们就有理由认为接下来的4个星期我们可以完成80个点数的Task。