[最佳实践]在Scrum敏捷软件开发模式中，我们是如何开Sprint 计划会议的

 

在Scrum敏捷开发框架下，最重要的一环就是 Sprint计划会议，这个会议开不好，整个Sprint会让Scrum Team痛苦不堪，也很难完成最初的Sprint目标。经过多次尝试后，我们终于找到了我们自己的模式。这些方法和原则对我们来讲是最好的，这基于我们自 己的知识，我们自己的项目情景，对于其他团队不一定试用。

---敏捷精灵

• 跟任何其他会议一样，确定好会议日程

sprint计划会议一定是要基于Time-Boxed, 在规定的时间内，一定要结束，就像一个Sprint一样。

我们的日程一般是这样的

Agenda:

Part I : Product Backlog Review [Product Owner, Scrum Team]

Time: 2 Hours

1) Enrich Product Backlog (60 Minutes)

2) Re-Prioritize Product Backlog Items (10 Minutes)

Break(10 Minutes)

3) Set Sprint Goal (20 Minutes)

4) Select Product Backlogs to Sprint (20 Minutes)

Part II: Sprint Planning [Scrum Team]

Time : 3-4 Hours

1) Work Breakdown by Two groups. (60 Minutes)

Break(10 Minutes)

2) Agree with the definition of "DONE" for each task with estimation (20 Minutes)

3) Critical Path Analysis (20 Minutes)

4) Resource Plan (20 Minutes)

Break(10 Minutes)

5) Find owner for each task. (40 Minutes)

6) Risk/Dependecy Analysis (20 Minutes)

7) AOB

• Sprint计划会议必须在一个完整天内开完

Sprint计划会议开始的那一天，也就是Sprint开始的一天。如果Sprint计划会议要跨越两天，可不是什么好玩的事情，你的Burndown Char就会象我们的这样很难看。因为我们是在前一天的下午开了4小时，第二天上午又开了3小时，对任务进行细化。。。

• 采用Delphi方法进行任务工作量的估算

当进行任务细化的时候，每个人的估算是不一样的，当出现分歧的时候，采用Dephi估算方法，如果最高估算值跟最低估算值相差一半以上，而者就要进行沟通一下，看看为什么二者的理解相差这么多。沟通明白后，再重新估算

• PM必须在Sprint计划会议前给出Sprint参与人员的预期工作时间

根据我们的历史统计，我们的投入率基本在75%左右，譬如按一个人上班8小时计算的话，他用在项目上时间大概在6小时左右。如果这个Sprint周期需要 15个工作日，这个员工可能要休假2天，参加培训1天，那他可以投入的预期工作时间 就是 6*（15-2-1）= 78小时。这样，在这个Sprint中，会有多少“人小时”就会事先计算出来。在Sprint计划会议中，当选择和细化Sprint任务的时候，有这个总 预期工作时间总作参考，就可以避免任务不足，或者承诺过多的问题。同时，也提醒每个人在领取任务的时候，不要过度承诺。

• 为了提高任务细化的效率，将团队分成两个小组分别进行
  

最初，我都是打开投影仪，把ScrumWorks中的东西投到屏幕上去，大家一边说，我一边敲，我是挺忙活的，但是大家却不一定都能集中注意力。。。现在 回头看看，这种方法真是有点蠢！当team成员少的时候，在最初的几个Sprint，大家在兴趣还比较高的时候，这种方法还行。

当Team成员超过6个的时候，问题出现了，首先是当讨论某一个问题的时候，总会有人问，刚才你们说什么来着？很显然，他走神了。。。另外，人多地时候，对同一个任务的细化，即使采用Delphi方法，沟通成本也很高，很费时间。

把team分成两个小组，分别对任务进行细化。细化时，不再用投影仪，而是把Sprint Backlog中的内容按大块张贴在墙上，大家站在墙前，拿着纪事帖直接进行细化和估算。 当两个小组都进行完后，互相检查对方对任务的细化，解决争议，澄清模糊的地方。这样一来，就把大家的积极性调动起来，参与程度非常高，效率也高。

• 对任务"DONE"的定义一定要做好，做细！
  

这个问题不言而喻，就不多说了。

• 虽然我们采用了Scrum，但是传统的Risk/Dependency分析还是不要丢弃。

即使不再采用Gatt图，但在Sprint计划会议结束前，进行Risk/Dependency的分析，还是帮助我们发现了一些问题，通过重新调整任务的优先级，顺利保证了Sprint的成功。

• 产品负责人(Product Owner)一定要参加。

实在不能参加的话，也要指定一个人授权代理。否则，就不要开Sprint 计划会议。

• Sprint Goal一定要定义的简洁、突出，选择的Sprint Backlog Item一定要强内聚，松耦合

这样大家才能不受或者少受外界的干扰，目标明确。

• 要给Sprint起一个好的名字