敏捷项目如何做计划？
敏捷项目要不要做计划？
常常听到有人在讲，“我们敏捷项目，不用做计划，到了该完成的时候自然就完成了。因为敏捷宣言里不是说响应变化高于遵循计划，所以敏捷项目做计划是没有意义的。”
做计划是Scrum的基础。开发团队承诺开发最有价值的功能，要实现这个承诺，团队必须对每个功能有明确的开发成本估算，以及需要对每一个功能的最佳上线时间做出判断。
敏捷里怎样做计划？
逐步完善计划
首先应该逐步完善Product Backlog, 未来比较长一段时间要开发的功能写成Epic Story加入到Backlog里， 然后随着时间前移以及迭代的交付逐渐把它拆分成更小的Story,直到拆到不可再拆的粒度为止。Story拆成最小后，还需要逐步完善故事，增加AC使其达到DoR的标准。
一个简单的DoR示例
近期做的几个项目，团队里都欠缺一个清晰的DoR导致常常发生故事卡进入迭代后仍不清楚怎么实现的问题, 这里介绍一个比较简单易推广的DoR评估表格。我们把一个故事是否能够移动Ready For Dev相关的3个重要因素打分，分值从0到3. 最后加总3个因素的得分，分值大于6分的可以视为满足DoR。不满足而优先级又特别高的故事就得添加Spike卡去把它梳理清楚。
| 因素 | 非常清楚 | 清楚 | 有一些待确认的问题 | 完全不清楚 |
|---|---|---|---|---|
| 需求 | 3 | 2 | 1 | 0 |
| 实现 | 3 | 2 | 1 | 0 |
| 因素 | 有依赖且不清楚找谁 | 有依赖不清楚如何集成 | 外部依赖Ready | 没有外部依赖 |
|---|---|---|---|---|
| 依赖 | 3 | 2 | 1 | 0 |
举个例子，Backlog里有以下5个故事卡，评分分别如下表：
| 故事 | 需求 | 实现 | 依赖 | 总分 | 能否进入下一迭代 |
|---|---|---|---|---|---|
| Story 1 - 从附近商家列表、商家标签页跳转各场景商家详情 | 3 | 1 | 0 | 4 | N |
| Story 2 - 创建订单时，需要记录已经使用的优惠 | 3 | 3 | 0 | 6 | N |
| Story 3 - 技术卡，使用redis inc 机制生成订单编号 | 3 | 3 | 3 | 9 | Y |
| Story 4 - 点击订单列表条目跳转订单详情页 | 3 | 3 | 3 | 9 | Y |
| Story 5 - 创建订单时，需要记录已经使用的优惠 | 2 | 1 | 3 | 6 | N |
怎么样开好一个Sprint Planning Meeting?
经常会有人抱怨：
- 我不想花那么多的时间参加Sprint Planning Meeting, 因为感觉没有任何价值。
- 会议开太久，好像和我并没有太大关系，为什么要整个团队都参加。
- BA和TL就决定了所有的需求和实现细节，要不让他们开就行了。
- 故事太不清楚了，我根本不知道怎么估点。
许多项目都存在以上问题，为了解决它我想以下这些方实践可以比较好的减少这些困惑，提高Planning Meeting的效率。
-
增加Backlog Grooming环节。
在开Spring Planning 前需要做backlog grooming, 与整个团队一起先梳理优先级高的，接下来可能要纳入Sprint的Story.
在这个环节PO/BA会向团队讲解Story细节， 让团队了解他们接下要做什么；在这个环节团队可以问问题，有可能PO/BA不能当场给出答案，这样在Sprint Planning前他需要去找到答案，不然就不能纳入下一迭代里；在这个环节团队可以对一些过大的Story进行再一步的拆解，让它变更容易估算准确；在这个环节开发团队可以开始讨论如何实现以及有没有外部依赖等细节。 -
定义团队Capacity
我们前面说到要做计划，每件迭代需要承诺交付高优先级的产品功能；这就需要明确团队的交付容量，在Sprint Planning时根据团队的容量来选择Story.这个容量是随着团队的熟悉程度，合作默契程度的提高会不断变化的，所以需要及时调整。 -
保持一定的Capacity余量
尽量不要把Capacity全部用完， 在一个迭代里难免会出现一些意外， 以及团队成员突然被一些项目外的事情耽误一天半天的。一个没有任何弹性的Sprint Plannig最终的结果就是团队将会无法应对任何的变数，一旦变数发生团队就会疲于奔命，或是加班加点，或是抱怨连连，极度影响团队士气。
