敏捷估算：故事点

原文  Agile Waste: Stop Using Story zhongPoints. Now.

 

Ron Jefferies，Story Points 的创造者，Agile 的创造者。

故事点是种浪费。故事点的创造者 Ron Jefferies 对这种浪费总结如下：

• 用故事点来预测“什么时候完成工作”顶多是个糟糕的想法；
• 跟踪比较实际值与估算是种浪费；
• 比较团队的估算质量和速度是有害的。

故事点已成为是一种毫无价值的造数据技术，充其量是使用过去工作的估算来预测未来工作的估算。这意味着即使在最好的情况下故事点也存在浪费。

速度（Velocity）已被武器化，用以对抗敏捷度和适应性。当创造价值不如衡量产出能力重要时，就会出现这种情况。敏捷软件开发接受这样一个事实，即增量通常会交付利益相关者不想要的东西；迭代才是提供利益相关者想要的东西。也许几次迭代才能出利益相关者想要的东西。在迭代敏捷开发中，客户说功能完成了，功能就完成了，开发人员说的完成不算数。

Jim Highsmith 提出了减轻故事点损坏的方法；通过使用更有用的数据稀释故事点的浪费，以“帮助平衡速度措施带来的不利影响”。

 

Martin Fowler

故事点是估算值。估算比事实更虚假。即使是敏捷的创造者，也是故事点的创造者和第一批用户，也经常估算失败；并且他们经常无法完成冲刺的目标。即使需求分解后也做不到。甚至没有使用故事点。管理层坚持要数量、要承诺、要速度，所以敏捷的创造者用故事点和诡计来逗他们开心。他们找到了一种让管理层感到高兴的方法，啥也没干就增加了浪费：

即，使用估算的秘诀：昨天的天气（Yesterday's Weather）。Martin Fowler 将其描述为：“为此次迭代计划交付和上次迭代一样多的需求”。明确地说就是：敏捷的创造者们拿他们上次冲刺所做的事情，假装他们是在这次冲刺中做的。故事点和估算不是敏捷软件开发的固有部分，而是一种充满浪费的项目管理的尝试。

不出所料，Ron Jefferies 向那些没有进行敏捷软件开发的团队澄清道，“我不再推荐使用速度，这意味着我也不再推荐以故事点或其他方法进行故事估计……速度是一个过时的话题”。

恭喜您，现在可以通过停止使用故事点轻松地为公司赢得胜利。