用户故事与敏捷方法笔记 --- 估算与计划
估算用户故事
故事点：代表时间的模糊单位，叫NUT（Nebulous Units of Time）。
故事点的特性是团队可以定义自己认为合适的故事点大小。它可以是一个理想日的工作，也可以是一个故事复杂度的测量。因此不同的团队，故事点有不同的意义。
使用故事点估算的好处：
- 无论什么时候获得有关故事的新信息，都允许我们改变之前的想法
- 适用于史诗故事和小故事
- 不需要花很多时间
- 提供进度和剩余工作的有用信息
- 不太精确的估算也不会有太大问题
- 可以用来制定发布计划
故事点估算应采用：
1 以团队估算：1）还不确定团队中谁负责完成这个故事； 2）团队的决定可能比个人更准确
2 德尔菲法：1）背靠背；2）少量解释；3）多轮
3 三角测量：在估算一个故事时，根据这个故事与其他一个或多个故事的比较来估算，最后将估算值相同的故事点放在一起比较估算是否准确。
发布计划
排列故事优先级
为了计划一个发布，客户必须排列故事的优先级，可以使用DSDM方法中的莫斯科（MosCoW）规则。MosCoW是以下短语的缩写：
- 必须有(Must have) -- 系统的基本功能
- 应该有(Should have) -- 很重要但短期内有替代解决方法的功能
- 可以有(Could have) -- 没有时间就可以在发布中不予考虑的功能
- 这次不会有(Won't have this time) -- 客户期望拥有但同时承认可以在后续发布中实现的功能
优先级始终应该由客户来确定，在确定故事的优先级前，应该先估算故事的大小并提供给客户参考。另外，如果客户在确定一个故事的优先级需要困难时，很可能需要分隔故事，以便客户可以对更小的独立故事排列出不同的优先级。
用故事点和优先级预计工期
团队速率：团队在一轮迭代中能够完成的工作量。
获得团队初始速率的方法有：
- 使用历史值
- 执行一轮初始迭代，使用那轮迭代的速率
- 猜测
随着进行几轮迭代后，团队对于项目开发工期会获得实际速率，并以此来完善估算，获得更准确的发布计划。
创建发布计划
根据故事点，优先级，以及团队的速率，将故事放入到每轮迭代中，直至分配完所有的故事，就可以确定发布计划了。
迭代计划
在每一轮迭代开始前，整个团队通过举行迭代计划会议来为下一轮迭代做计划，迭代计划会议的一般内容如下：
1 讨论故事
迭代计划会议室是调整故事优先级的最佳时机。从优先级最高的故事开始，开发人员提问客户，直至充分理解故事，能从故事中分解出任务。
2 分解任务
将故事分解为更小的任务以便 1）分配给多名开发人员共同完成； 2）减少功能被遗漏或忘记的可能。
3 承担责任
由团队成员资源认领任务。虽然任务由不同的人认领，但实际上确保完成所有任务是团队中每个人的责任，团队要有一种“同舟共济”的心态。而且在迭代快要结束时，如果有开发人员不能完成他接受的所有任务，团队中的其他成员应该尽量用于承担。
4 估算并确认
由每个开发人员负责估算自己承担的工作量。然后把所有估算加起来，从而评估是否能够在迭代中完成所有的任务。同时，在迭代进行中，要不断的更新剩余的工作量。
测试并监控速率
测量速率
将团队在本轮迭代中完成个故事的点事全部相加，就得到了本轮的开发速率。
注意不要将未完成的故事也计算在速率中，因为 1）很难准确计算故事已完成的百分比；2）不建议将小数引入速率中；3）没有完成的故事通常不能给客户带来任何价值；4）应尽量避免许多故事完成90%，没有多少故事完成100%的情形。
如果时常发生迭代结束时很多故事尚未完成的情况，可能是因为故事划分的不够小，也可能是团队内部缺乏合作的信号。
计划速率和实际速率
监测实际速率和计划速率的偏差很重要。一个比较好的方法是为每轮迭代画出计划速率和实际速率。
另一个监控进展的好方法是迭代燃尽图（Brundown Chart），它展示了以故事点表示的在每轮迭代末剩余的工作量。
从燃尽图中可以看到项目的整体进展，得到已完成的故事点表示的进展，也可以得到对剩余的计划故事点数的改变。但燃尽图无法提供团队速率，因为可能有新的需求加入。
如果想要了解团队的速率，需求变化情况等，可以采用下面的表格：
| 迭代1 | 迭代2 | 迭代3 | 迭代4 | |
| 迭代开始时故事点 | ||||
| 在迭代中完成的 | ||||
| 调整的估算 | ||||
| 新故事的故事点 | ||||
| 迭代结束时的故事点 |
迭代中的燃尽图
燃尽图不仅可以用于在迭代结束时跟踪进展，还可以在迭代周期内作为团队自管理的工具。在迭代中，每日燃尽图可以展现在迭代内剩余的估算小时。
另外，通过设计和检测平均每个故事点出现的缺陷数目，可以帮助我们发现团队速率的提高是不是以牺牲质量为代价。
