敏捷开发之故事点估算与故事点燃尽图

一个团队/个人花 10 小时能完成的任务，另一个团队/个人或许需要 100小时；

也有可能团队花了 100小时但是什么都交付不出来；

作为一个用户故事，只有“完成”与“未完成”两种状态，不能使用一个百分比来表达“部分完成”，例如我们不能燃烧掉一个用户故事 1/3 的故事点=来表达它已经完成 1/3了；

基于小时的估算是不精确的，不同人在同一个任务上要花不同的小时数；

花了几个小时在一个任务上不等于这个任务有一部分被完成了， “部分完成”是一个隐藏问题的危险状态，应该避免使用；

故事点估算更简单和敏捷，虽然它很难使用。  

 
基于“小时估算”及基于“故事点”监控的差异，一直是一个具体而微妙的问题，令很多初涉敏捷的组织迷惑。（引用作者的用词，）这真是一个“干净利落”的案例。 能正确使用“故事点”来估算及后续监控，理应不会出现任何异议。但学界也仍然有诸如Mike Cohn 等导师级人物仍认为 Ideal Hours是可用的。我个人的理解，其思路与作者有一点关键不同：在燃尽图更新时，视角并不是记录“已消耗工时”，而是再次估算“剩余工时”。换个角度看，燃尽图的更新体现了一个不断估算的过程。再者，遵守“只有彻底完成的Task才能在燃尽图上获得分数”的规则，也可能有效的避免此问题。 个人体会:从 Burn down的价值取向分析，（彻底）完成了多少、（到底）剩余多少，是重要的；既有的成本投入，不太重要。