Scrum实践系列之一：工作时间打扑克？--谈谈扑克估算

不知道是不是因为勾起了大家的牌瘾，最近一阵"扑克"估算很是火了一把，在几个项目尝试后很快蔓延开来，很多项目团队都跃跃欲试。

尝试的过程中难免产生一些困惑，干脆在这里做个澄清，把我实践下来所理解的扑克估算的方方面面跟大家一一道来。

 

在开始之前，首先需要澄清的是，在某种程度上，估算其实是在预测未来！

预测未来是件非常难的事情，我们看看天气预报，就知道人类在这项工作上有多么滴不靠谱了。

 

为什么要做估算？

估算本身很困难，而花在估算活动本身上的时间，又并不能够对产品本身产生直接的价值，那么为什么我们要花时间做估算呢？为什么气象中心还是坚持不懈的发放自己的预报呢？

首先，用户需要一个预期，甚至是承诺，这个功能什么时候能够提供。

其次，管理层需要可预测性，某些决策需要基于估算而做出，即便这个估算还不那么准确，但总是聊胜于无。

最后，团队需要了解如何相互协作，在哪个时间点能够拿到我所需要的接口或素材，据此相应的规划并安排自己的工作。

总之，估算可以帮助我们找到一个合理的计划，给用户、管理层、以及团队自己一个稳定的预期。

 

为什么选择相对估算？

传统的估算方法，通常是基于人天/小时的绝对估算。而敏捷中所推荐的扑克估算方法，则是基于故事点的相对估算。这种估算一上来容易让人找不着北，大家会习惯性的问：“那这个故事点到底代表什么？单位是什么？做完了相对估算是不是还要再转化为人天？与人天的对应关系又是什么？”

讲清楚这一系列的问题，我们需要先搞清楚，为什么选择相对估算。相对估算有哪些好处呢？

首先，相对估算更符合人的本能认知。电脑区别与人脑的一大特点，就是电脑更擅长计算与处理绝对信息，而人脑则对相对印象更有感觉。我们可能永远搞不清楚手上的核桃和苹果的真实重量，但却能很直观的判断出苹果更重，重量嘛，大概相当于“6个核桃”。瞧，这就是人类的本能认知。

其次，正是因为相对估算更符合人的本能认知，因此掌握之后，它能让估算过程变得更快更简单。因为我们不再需要纠结于这个任务到底需要5天还是4.5天，我们只需要为手头的工作定义一个参照物（“一个核桃”）作为基准，然后拿其他的工作与之相比较，工作量是更大了还是更小，复杂度是更高还是更低，然后给出一个大约的倍数值就done了。

 

相对估算需要转化为人天吗？

在实施scrum的项目团队中，最后得出的故事点的数值，不需要再转化成人天，这是由scrum的特性所决定的。

在scrum项目中，我们会以sprint为周期来做增量交付，这直接改变了做计划的方式。传统项目中，我们需要根据基于人天的估算来确定各节点及最终发布的日期到底是几号；而在scrum项目中，周期是事先约定好的，每个sprint的计划不需要确定日期，而只需要估算下一个sprint我们能完成多少工作。由于sprint固定周期性的特点，在几个sprin t之后，我们就会得出一组相对数据（比如35个story points），来衡量团队的生产效率。根据这个生产率，我们可以很容易的快速进行相对估算，不需要转化为具体人天就能得出结论。

当然，如果你是第一个sprint，没有经验数据的情况下，可以尝试转化为人天找找感觉，或是直接根据团队的直觉来做出判断。

如果你是在传统项目中做扑克估算，那么我的建议是可以直接用人天来进行估算，虽然不如相对估算那么便利，但至少还是获得以下的好处。

 

如何进行扑克估算？

在以下的这篇文章中，配合实例有非常形象的说明，在此就不再赘述了。

http://www.uml.org.cn/SoftWareProcess/201108264.asp

扑克估算有什么好处？

• 团队一起做估算，估算更全面细致

传统的项目管理中我们也会做估算，WBS分解后完成任务分配，然后每个人估算自己的，如果每个人只对自己的那块比较熟悉的话，估算结果往往会有欠考虑，特别是针对相关性较强的模块，会出现较大误差，从而为项目后期埋下潜在风险。

在扑克估算时，一开始我们特意不进行任务的分配，对于每一个故事，都会由全员出牌，包括各个模块的开发及测试，每个人从自己角度出发想问题，互相补充。比如在扑克估算时，测试的成本会被自然地考虑进去，作为一个整体来衡量，对于测试成本高的story，大家会一同来考虑进行哪个层级的测试会更为合适，单元测试？API测试？还是UI测试。这样涵盖了各方成本的估算结果自然会更全面、更细致。

• 团队一起做估算，需求探索更深入

实践中我们会发现，真正到了让你给出预估的时候，就会有各种各样的问题冒出来。这个需求到底要不要做这个，是否要满足那个条件，等等，扑克估算让这个需求探索的过程公开化，通过公开的讨论在早期进一步挖掘和明确需求，帮助我们将需求探索进行的更为深入。

• 团队一起做估算，有助于优化解决方案

大家在一起亮牌，经常会有不一致的情况出现，比如一个人出5，另外一个出40，这个时候往往是团队成员间交流解决方案的好时机。问问你的团队，为什么相差这么远，这样的讨论能够帮助大家找出最优的解决方案，并在团队中迅速共享。

 

估算！=承诺

最后，区分估算与承诺是非常有必要的。我们经常会将估算的结果等同为一项承诺，然后用这个承诺来要求团队的行为。因为估算与实际不符，就进行惩罚或计入考核，这种做法忽略了估算在本质上的困难，未免太过于简单粗暴。在某些重要的场景下，如果你需要一个确切的承诺，那么请允许你的团队花更多的成本来进行精确估算，并且允许他们留一定量的buffer来应对估算误差，是更为合理的做法。

 

以上就是目前我对于估算这个话题的简单认识，希望对各位看客们有所帮助~