工作量估算
工作量估算的目的是-改进决策和计划,而不是-承诺和提出截止日期。
程序员一般倾向于考虑一切都顺利的情况，而且往往只考虑写代码的时间，而忽略了提交代码，代码评审，重构，测试，发布的时间，所以往往会给出过于乐观的估计。估计不充分导致过度承诺会导致项目进度压力，从而增加bug，让客户不高兴，造成资源冲突，带来团队过度劳累。
工作量估算的步骤：
- 找一个人（或者2个）做任务分解，任务分解的越细，估计越有可能准确
- 团队一起讨论每个分解的任务，达成共识，消除歧义
- 团队一起针对每个任务做工作量估计，可以使用最好情况，最坏情况和最可能情况来分别估计。
- 得到团队的最终估计
- 提醒团队估计只是用来帮助我们做计划，不是截止日期的承诺
上面这个团队一起讨论的会议一般叫做Grooming会议，这个会议上对工作量估计的讨论是最重要的部分，因为这个帮助团队对工作范围达成共识。团队估计比个人估计更有优势的地方在于：
- 避免太乐观
- 发现遗漏的任务
- 让大家统一理解，这样任务就不一定由做估计的这个人做了
故事点（Story Point）和计划
故事点（Story Point）是现在通常的工作量估计的单位，因为它是一个相对的概念，所以能更好帮助我们通过比较两个任务来得到更准确的估计，人们通常更擅长比较两个任务的大小而不是直接说出一个任务完成需要的时间。尽管故事点不是一个具体的时间，但是有了故事点和团队的历史速度，比如在一个Sprint里能完成的故事点的数目，就能够预测未来能实现的功能，从而可以制定计划。
故事点的值没有意义
故事点的数值并不重要，不要制定任何针对这个故事点的数值的指标，否则你很容易就会得到故事点的通货膨胀了。同样也不要用故事点来比较不同的团队。
故事点只是为了得到团队的开发速度，从而制定计划。
故事点真的比具体的时间好吗
很多团队在用故事点的时候会把一个故事点换算成一个时间单位，这样其实就背离了故事点的初衷。但是对于很多人来说，具体的时间远比故事点能容易让人把握。在Stop Using Story Points里作者也列举了很多故事点带来的问题，并提出了一些做估计（或者说计划）的别的选择，比如：
- 训练团队总是用一样的大小来切分用户故事（user story），这样每个迭代就挑选一样数目的用户故事就好了。
- 采用基于流的迭代周期，就是说我们把发布几个功能作为一个迭代，而不是有固定的周期。这个和看板的方法有点类似，团队聚焦于发布功能，而不是计算在固定的时间里能完成哪些功能。
工作量估计的一些思考
不确定性和风险
工作量估计不只是要考虑工作量，还需要考虑：
- 不确定性，比如新的项目可能要学新的技术，
- 有多少东西要学习？不知道
- 学习这些东西有多难？不知道
- 在学习的过程中我们会犯多少错误？不知道
- 风险，比如我们实现一个功能，会不会让其他功能不工作，
- 哪些功能会受到影响？不知道
- 会带来什么危害？不知道
- 修复这些危害有多难？不知道
如果有更多的不确定性和风险，我们估计这个功能的时候就会给一个大的值，但是如果这些不确定性和风险都没有发生，那么实际用到的时间就会大大减少。所以想得到更准确的估计，就需要尽量减少不确定性和风险。这就是我们通常所说的Spike，当一个功能不确定性和风险很高时，我们常常会先做一个Spike来理解有哪些不确定性和风险，从而帮助我们得到更准确的估计。
延迟和打断
很多人把工作量估计等同于还需要多少时间来完成这个功能，但是这个并不成立，因为通常来说我们的工作会遇到：
- 延迟。有可能这个工作因为依赖其他东西还没有到位，所以并没有马上开始。
- 打断。有可能在做这个工作的过程中要处理其他的事情，导致并没有全职的在做这件事。
工作量估计的一些建议
- 尽量定位和减少项目中的混乱和不确定性
- 意识到计划需要有一定的弹性，我们应该做MVP或者“可以行走的骨架”，然后逐渐丰富，确保随时我们都可以发布对用户有用的产品
- 尽量分解成小的任务
- 通过自动化测试和持续集成来更快的发现风险
- 团队需要保留一些机动时间。可以用这个时间来检查，改进工作，从而让工作更有可预测性，更高效
参考阅读
本文参考了下面这些文章：
Agile Estimation
Estimates vs Actuals
Stop Using Story Points
Bargain Hunting
