Scrum心得之时间估算（三）

在一个sprint周期内，通常会用burndown chart 来显示进度。这时候，会把故事再拆分成一个个子任务，分配给每个成员。任务包括设计界面，准备表结构和后台数据等等。熟悉燃尽图的人知道，表中每格代表该任务在当前剩余的工作时间。例如 “准备查询界面”
-- 3 小时。随着开发前进，剩余时间应逐渐减少，在sprint到期前应该为零。
任务：（Day 1 剩余需要开发时间）；（Day2 剩余需要开发时间）…
“准备查询界面”: 3;2;1
Scrum Master 的职责之一，就是注意燃尽图中某个正在工作，剩余却不发生变化的任务。要么是成员低估了工作量，或者是遇到了某个难点；要么是他在做和任务无关的工作。
标准敏捷教程要求每个任务要细分到半天内，如果粒度太粗则说明考虑还不周到。我通常对成员做一点让步，如果该任务不在短期内（1到3天）执行，允许放大粒度到8小时。
在燃尽图中，每个成员的汇总栏下，可以看到该人每个工作日的剩余工作量（用小时计算）。如 成员X: 44;40;35;30;20;15
如果某天的工作量超过剩余的工作时间，Scrum Master 就要提醒该成员注意，是否需要帮助等等。
在汇总栏下增加一行，用前一天的工作任务减当天的工作任务，则得到当天的完成工作量。
成员X: 44;40;35;30;28;18；0
完成量：_; 4 ; 5 ; 5 ;2; 10；18
上面的例子显示，成员X第一天完成了4小时工作量，第二天5小时，第三天5小时，第四天突然下降到2小时，但接下来上升到10小时，而最后一天达到惊人的18小时。
这是可能的。因为开发工作不会完全平稳前进，有时候遇到一个难点，而一旦攻克则能加倍前进。这些完成工作量的数据其实在燃尽图上就能体现。
现在的问题是，用燃尽图除了能展示开发进度外，能不能预测任务的完成？
我们知道，燃尽图中每个任务的所需时间也是成员自己估算的。这个估算建立在成员对任务难度的理解和对自己能力认识的基础上，也建立在每天充分工作的基础上。事实上，没有人能够8小时1分钟不拉地工作，总要收个邮件开个会打个电话发个短信什么的。假如能全神贯注6小时做开发，就已经非常不错了。燃尽图表格中的所需开发时间，也被称之为理想工作时间，即在完全不受干扰情况下所需要的时间。
但能否知道实际上将要花费的时间呢？
我的改进是继续增加一行，计算完成工作量的平均值。继续上面的例子：第一天是4小时，第二天为4.5, 第三天4.7，第四天4，第五天后平均速度是5.2小时，最后平均速度为7.3
成员X: 44;40;35;30;28;18；0
完成量：_; 4 ; 5 ; 5 ;2; 10；18
平均速度：4; 45; 4.7; 4; 5.2；7.3
现在，我知道成员X本周解决任务的平均速度为7.3。 如果数据持续几周，平均值会更加准确。但这又有什么意义呢？
开发速度本身并没有意义。如果Y的速度为2.5，并不意味着X的能力一定比Y强。因为X和Y对任务估算的尺度很可能不同。
但是下一次sprint计划时，在X给出他的任务估算后，我可以大致估算出他的完成时间。假设工作量为35小时，那么他应该在5个工作日后完工。（当然，前提是，X处理的问题是类似的）
这个方法有助于考察某些特别乐观或者悲观的程序员，避免被他估算的数字吓倒，但是我又不想深入细节和他讨论为什么这个任务要那么多（少）的时间。所以，最好用他以往的表现来提醒双方。
注意：
只有在完成故事的前提下，平均速度才是有帮助的。也就是说，在上面例子中，前几天计算的平均速度毫无意义。有时候最后1小时的任务要拖几天才能完成，各种各样的隐藏任务都在最后冒了出来。不完成完整的故事，计算结果就完全是误导！
对任务的时间估算是看个人的，对故事的时间估算是看团队的。Sprint注重完成故事，而不是任务。不要过于强调个人完成任务的速度，而使得团队的整体遭到破坏。