敏捷社区的专家正在热议如何使用故事点和速率（Velocity），不少人对使用它们估算和度量总体进度产生了怀疑，打上了问号。大家普遍认为，产生问题的根本原因就是这些度量项往往不是挂羊头卖狗肉，就是浮于表面被误用，很少能用在刀刃上。
Joshua Kerievsky 详细记录了他使用故事点的经验，以及他们是如何粉饰太平的。在下面的这个例子中，他讲述了故事点走向恶性通货膨胀的过程。
2004 年的一天，Jim 想要团队加快开发速率。团队原本的平均开发速率约为每个迭代完成 52 个故事点。他们的开发速率可能有几个点的浮动，但总体保持着平稳。然而 Jim 要求团队“全速前进”。仅仅几周后，团队开发速率一跃攀升至 80 点！
我问一个同事这是怎么回事？
她用讽刺的神情看着我：“这几天在这儿打个喷嚏都算故事点。”我摇了摇头，吃惊地看着这个成熟的敏捷团队居然为了让自己看起来速率加快了，以迅雷不及掩耳盗铃之势膨胀他们的故事点估算。这可是我和两个优秀的 Industrial Logic 公司教练一起亲自培训、辅导并审核过的团队啊！
此次经历之后，我对故事点和开发速率计算的信心开始动摇了。
Joshua 还指出，用故事点来横向比较团队是非常拙劣的方式：
这些年来，我听过多个来自不同公司的经理这样问：“为什么 X 团队每个 Sprint 可以完成 24 个故事点，而 Y 团队只能完成 12 个呢？这两个团队规模差不多啊，究竟差别在哪儿呢？”
这些经理并没有把开发速率当成是团队独有的能力指标，而是掉入了一个常见的思维陷阱，把开发速率当成了绩效度量指标。
在 Joshua 的博客评论中，Bob Martin 大叔进一步确认了这一点：
许多团队确实在使用故事点时很挣扎。我遇到过有些团队的项目经理莫名其妙就要求团队加快速率，企图不劳而获，那么团队只能让故事点贬值。我也遇到过有的团队为了讨老板欢心捏造开发速率报表，因为老板更热衷于形式而非内容。对于这样的团队，其他的方法可能更靠得住些。
在 Scrum Alliance 邮件组的讨论中，Ron Jeffries 就批判了将开发速率作为度量项这一行为。
- 开发速率可能并常常被误用。
- 开发速率可能并常常被用于攀比。
尤其是这跟主流敏捷思想背道而驰。敏捷实施中，很重要的一点就是要通过优先级来决定先做哪些后做哪些，从而掌控项目，而非紧紧盯住数学公式并致力于让数字好看。
团队关注开发速率那么就并不再关注实际价值。我希望我没发明过开发速率，但我却这么做了。
沿着这个思路，他进一步做了详细说明：
我们发现这里的多数问题是关于如何改进估算，让它们更加精确的。当我们进一步分析，我们注意到团队会计划一个完成时间，然而他们会被催促着按时完成所有工作。看得出他们在度量团队预估的准确性。
我们发现产品负责人只会”遵循计划“，几乎不管不顾地分配任务。
只有当产品负责人能够创造性地使用待办事项列表，交付尽可能好的产品时，Scrum 才算物尽其用。我发现紧盯着估算对此毫无帮助。
Mike Cohn 最近发表了一篇博文，介绍了一个非常看重估算的客户的案例。援引这个客户的话：
首先，对我而言，至少为了做预算，我需要知道我们的估算可以和实际情况有多接近。当我问投资人要求追加投入时，如果我们只完成了承诺的二分之一，他们会觉得这是个无底洞。我会处理这些情况，但我需要知道我们有个合理的途径来获得一个初步的估算。第二，为了筹集后续资金，我需要了解大概的数目（这是一项需要不少前置时间的活儿）。如果估算和实际情况相差甚远，我们就不得不改进，随后我会去开辟获得资金的渠道。也就是说，没有免费的午餐，钱不可能无缘无故从天而降。我必须有某种水平的度量来反映损益情况并贯穿项目始终。换句话说，我得在项目过程中盯住燃尽图，关注项目成本。
Vasco Duarte 提出了一个故事点的代替方案：通过统计故事数量来做来估算 。
如果是估算以及监控那些长期项目（提示：这只适用于长期项目，例如在未来至少有三个以上 Sprint），你可以假设所有的故事大小都一样，因此就可以通过度量每个 Sprint 完成的故事数量来跟踪进度了。
Mike Cohn 也提出来类似的观点：
我承认用看板的团队相对较少做很具体的估算。这往往是由于他们已经默认了所有的工作的规模都相当的缘故。
Neil Killick 提供了另一种不需要估算的定价方式。他以自己做网站的例子做比照。他的供应商会根据公布的可用预算给出最可能实现的方案，而 Neil 如果在任何一点上感到不满意，随时都可以选择终止合作。
他认为，这个选择
不需要估算。随着项目推进，不断改进设计、慢慢成形。它拥抱变化，因为我看得到网站的进展。并且这种模式也体现出我的供应商公司很期待和我密切合作，达成我想要的结果。这种方法也正是为面对特殊风险（按合同规定会亏钱）而准备的，因为他们对自己完成工作的质量信心满满，对他们和客户建立的良好关系坚信不疑。
你有没有发现类似开发速率和故事点估算在团队中助长了不良作风的事情呢？对于社区专家提出的代替方案，读者，你怎么看？
暂无签名
Java 避坑指南：Java 高手笔记代码篇
本迷你书包括 86 个业务开发中常见踩坑点。每一个知识点都相当的实用，是程序员业务开发中的必备避坑指南...
评论