何时、为何以及如何估算 | 抛弃估算系列 | Agilean学院出品
这篇Al Shalloway的文章讨论了各大阵营关于估算的不同观点，由Agilean学院张勇翻译、陈庆春评审，李淳审校
关于估算有3种不同的观点：
估算是有害的，因为管理层会滥用估算值。
估算是某种形式的浪费，因为估算不直接提供价值。
估算是做计划的关键。
接下来会对这些观点进行讨论，然后看看关于估算我们究竟需要用估算来做什么。争论源于下面三大阵营：
#NoEstimates Twitter社区（管理层滥用估值）
看板方法（估算是浪费）
Scrum（坚信估算）
#NoEstimates 推特社区
这一运动发起人Woody Zuill是一位坚定的创新思维思想者，专注于讨论估算的价值所在。这个社区并非要杜绝估算，而是希望客观辩证地看待估算的价值。时至今日，人们谈论更多的是估算通常缺乏精确性并因此而丧失其实用性。
我们发现，估算低质量的原因通常是因外部干扰和技术债务而增加了无法预测的工作量，而非开发人员不能理解该如何完成工作。此信息有助于识别要解决的挑战。实际上，不必要求每次估算都是精确的，所有估算值的总和大体准确即可。要做到这点这并非不可能，同时，也为基于逐个团队计算恒定开发速度提供了充分的依据。
“估算是浪费”社区
估算值有时候被认为是浪费，因为它没有提供直接的价值。然而，这些估算值常常有益于相互协作的多个团队。估算也有益于确保帮助人们对所估算工作达成一致的目标。最后，在将大体量用户故事分解成可以在一个迭代周期内完成的小故事时，估算通常也是一种很好的实践。若估算能加速价值交付，就不能说是浪费。关键在于，不应不加辨别地、教条地认定估算是浪费，没有经过讨论就认定估算是浪费，而应当确定估算是否真正提供了增值效果。
坚持必须估算的Scrum社区
Scrum以及以其为基础的方法，如规模化敏框架（Scaled Agile Framework），就要求有估算。如果实施Scrum，就需要进行估算。看板方法可视为Scrum的一种替代方法，虽然无需估算，却依然能够使用各种Scrum的套路。尽管很多Scrum社区抱怨估算太费时，但这大多归咎于使用计划扑克（Planning Poker）进行估算。
计划扑克无疑在某些情况下很有用，且易学。然而，相比在某些情况下的有效果，更多情况下这种方法则表现出低效率。相比这里介绍的其他方法，计划扑克需要更多的沟通，进而降低工作的速度。其所使用的相对估算方法也不如其他替代方法高效。然而，如果你希望你的团队多沟通，计划扑克或许是最佳选择。
使用故事点数
有很多的方式用于定义故事大小：t-shirt尺寸、小时数、理想人天、故事点数等。故事点数是那些认同估算的业界思想领袖们公认的定义大小的方法[注释1]。使用故事点同时，还建议使用修正的斐波那契数列来定义故事大小。这样，你只能选择这些值：？、0、½、1、2、3、5、8、13、20、40、100、200、300、无限大。
计划扑克的替代方法
替代计划扑克有2种流行的方法，相近的估算质量下，效率提升4-10倍（即只需要计划扑克所需时间的10-25%）。这两种方法分别是：
SteveBockman的团队估算（Team Estimation）[注释2]
JamesGrenning的计划扑克集会（Planning Poker Party）[注释3]
这2种方法使用了切实的相对估算，因而更具效率。例如，首先将故事/特性互相比较，按相近的大小归组，然后对这些分 51 29790 51 15231 0 0 3302 0 0:00:09 0:00:04 0:00:05 3301赋值。
何时无需估算
在运营组织中，规划是非必要的。但若要规划多个版本并且/或者启用某些具备稀缺的高需求技能、能力、经验的团队成员，那么核心就在于估算。在我看来，“不要估算”的颂歌似乎是对Scrum阵营中低效率方式的回应，同样也是对看板方法阵营中消除浪费的精益本质的过度狂热。实际上，我并不喜欢将“消除浪费”当作精益软件开发的真谛，因为这很容易让那些并不真正清楚什么是浪费的人产生困惑和滥用。并非所有规划工作都是浪费，并非估算都是浪费，取决于你怎样做。
有时候，人们认为干系人需要估算。特别常见的是，干系人之所以要求得到估算值，是因为他们认为这是一种提升生产率的方式。而通常并非如此。多数情况下并不需要为干系人做估算，而有时这确实对团队有益。因此在决策时，应当从初始请求到部署对整个工作流程加以考虑。
总结
如果因为管理层会使用估算值来当作承诺而造成团队不想提供估算值，团队和管理层之间就会产生问题。仅仅规避估算并不能解决问题。在审视你所用的实践时，务必搞清楚目标及其原因。如果估算所需的时间超过了其所具备的价值，那你就要看看是否有比你所用方法更加高效率的方法。不要把孩子和洗澡水一起倒掉。:-)
关于作者
Alan Shalloway是NetObjectives的创始人兼CEO，是精益、看板方法、产品组合管理、SAFe、Scrum和敏捷设计方面的思想领袖，拥有40余年相关经验。
注释
1、见《敏捷估算：为何使用故事点进行估算的9大理由》
链接：
http://www.agilebuddha.com/agile/agile-estimation-9-reasons-why-you-should-use-story-points
2、Steve Bockman的团队估算
链接：
http://www.netobjectives.com/files/books/lasd/TeamEstimationGame.pdf
3、James Grenning的扑克规划集会
链接：
http://www.renaissancesoftware.net/blog/archives/36
请长按一下二维码，关注我们的微信公众号：互联网plus管理新范式。