巧妙使用“故事点”进行敏捷估算

克强在“敏捷中国”讨论组中引发对敏捷的估算的讨论（“Scrum sprint plan中规模估算的做法调查”，“关于story point的单位”）。我想分享一下我自己对敏捷估算方法的理解以及对于“故事点”的认识。

• 基于承诺”Commitment”。做法很简单：
  • Product Owner从Product Backlog中取下一个用户故事（按照优先级），对这个用户故事进行解释，
  • 团队对用户故事进行讨论，明确需要解决的问题，
  • 整个团队确定是否能够在下一个迭代周期中完成这个故事，
    • 如果团队没有信心完成该故事，计划会议结束，或者把这个用户故事进一步划分成更小的用户故事重复第一步。
    • 如果团队有信心完成该任务，重复第一步。
• 基于速率”Velocity”
  • 确定Product Backlog中用户故事的规模（用“故事点”）
  • 确定团队迭代的开发速度（“昨天的天气”）
  • 从Product Backlog中取出相应量的用户故事。

• 绝对估算 vs. 相对估算
  传统的方式是通过计算出一个绝对值（有单位，比如多少人天，多少代码行）。然后，做出计划。很大的问题是，人天生不擅长做绝对估算，人们更擅长做相对估算，更容易在相对估算值上达成共识。举一个简单例子，估算从上海市人民广场到徐家汇的距离，如果使用公里或者米等绝对单位，多个估算者很难达成共识，往往陷入没有必要的讨论和争吵。而如果用相对距离，比如从人民广场到徐家汇的距离相当于两倍的从人民广场到火车站的距离，人们就很容易、很快达成共识。因此对一个需求点来说，关注于相对大小也更容易使整个团队在估算值上达成共识。
• 关注规模（而不是将不同维度的概念混淆）
  比较合理的估算方法是，首先估算整个规模，然后有一定的历史数据，知道速度，从而可以做出计划，推算出时间。比如我们看书，一共三百页，一天看十页，很容易就算出是三十天。如果使用理想日（时间维度），其实就是把这个过程搞反了，从时间维度反过来推算规模。同时使用“故事点”可以综合考虑一些其他因素包括复杂度、不确定性等，基于故事点的规模估算是在综合考虑各种因素之后的综合估算。而用代码行数很难对复杂度、不确定性等作出估算
• 忽略个人能力的不同
  不同人的理想日和代码行数估算是不同的，是根据每个人的能力和认识的不同而不同的。但是使用关注“相对大小”的“故事点”就可以解决这个问题。同样举距离的例子，每个人的能力是不同的（有人步行、有人跑步、有人公车、有人地铁、有人开法拉利），但是所有人得出的相对规模值还是一样的。因此使用相对规模估算就可以不需要考虑这种个人能力因素。
• 不可相加
  传统估算方式的一个很大的问题是，估算不能相加。每个人的理想日是不一样的，这样成员甲的估算（理想日）就不能和成员乙的估算（理想日）相加。基于这种相加结果的计划肯定是不准确的。在敏捷开发中，需要整个团队一起对任务进行估算，因此需要一个能够达成团队共识的标准 – 也就是“故事点”。

• 首先，故事点是一个相对量，相对值是没有单位的；小学乘法：被乘数 × 倍数 = 积。故事点估算值就是这个倍数。
• 其次每个团队的单位“故事点”是不同的，很难也不需要统一。