估算对于产品团队是再熟悉不过的一件事情了，不过我敢肯定，没有人对他有好感。特别是在软件行业，有太多太多未知数，技术的不断更新，新需求不断涌现，任务和任务之间、业务和业务之间的复杂依赖关系等等。那么问题来了，既然如此，我们为什么还要估算？
尽管如此，估算对软件开发仍然具有很重要的意义。一是可以帮助我们做出周全的决定。就算只有粗略的估算，也必须要考虑时间和预算，可以统一理解为成本。规划的本质是在可预期的时间内尽可能的优化 ROI（投入产出比），而成本自然是不可或缺的因素。第二是估算有助于设定目标。一旦确立一致的目标，毫无疑问可以帮助你保持专注并取得最大化成果。
其实，无论应用的是什么样的开发流程都绕不开估算这件事情，而一个科学的估算方式也是通用的。但我们聊的是敏捷，在估算之前，必须要说明是的关于「定义完成」这件事情。估算的主体是一个 Sprint 的产品订单，在敏捷转型初期，团队往往完不成预期的订单量。可能是因为缺乏应变能力，也可能是因为不够跨职能而导致的资源分配问题。这时候需要 PO 列出一个产品订单的子集，即当下获得所有人同意的完成的标准，随着团队的不断进步，完成的标准是要和 Sprint 的产品订单量趋向一致的。这里最重要的一点是，完成的标准是一致认可的，换句话说，我们是基于同样的认知对同一件事情做估算，这是前提。
那么如何估算才能让自己少些纠结，至少心里觉得不会是在「拍脑袋」？这又需要回归到 Scrum 的本质和起源：经验主义过程控制。经验主义给我们的指导是，只根据已经发生的事情做决定，而不是预测。所以，估算并不是去猜也不是去预测，而是根据自己的经验做相对比较。在软件开发中，影响一个 PBI（产品订单）工作量的因素主要有三个：复杂度、重复性和风险。当遇到一个比较大的需求或是项目时，通常我们会习惯将它拆分成足够小的需求来评估，其实拆分的过程本身就存在风险。反过来看，如果采用相对估算，则既高效又准确。我们不需要知道需求细节，只要大致知道这个需求和某个已知需求相比起来需要多少工作量就足够了。
至于估算的方法的实践，想和大家介绍的是或多或少听说过的规划扑克游戏。规划扑克的扑克牌每人一副，共 14 张牌，分别是 0，1/2，1，2，3，5，8，13，20，40，100，∞，？，coffee。数字反映了被评估任务的量级大小、风险大小。值得注意的是数字并没有单位，可能有人会有疑问，没有单位如何评估呢。其实，这个单位可以是工时也可以是 story points，正如我们前面所说，用的是相对估算方法，所以在第一次评估时，不妨大家统一认为 13 是一个 Sprint 能够完成的量级，在评估任务的时候只要以此为基准进行相对比较就可以了。除了数字之外，∞代表需求过大，没有意义，需要拆分；？代表尚不明确无法评估；coffee 则代表会议时间过长需要休息。你可能会发现，数字之间的并不是均匀排布的，其实这是一个斐波那契数列的变种。为什么要这样排步呢，其实很好理解，可以试想一下，1和2差别比较好分辨，如果是均匀分布的话，那 8、9，又或是 13、14 之间的差别又如何选择呢。
介绍完扑克的含义，下面来说说具体如何进行游戏。对于被评估的任务，所有人选择自己心中认为合适的牌，然后同时打出，紧接着由打出最低值和最高值的人分别阐述自己的理由，如果有必要的话，大家进行一定的讨论，然后再进行一轮，直到所有人的分数都比较接近为止。
过程其实很简单，在敏捷的概念里非常鼓励沟通，因此相比评估结果更加重要的是消除分歧的过程，也就是沟通的过程。一个简单的游戏，有效地呈现了不同的人对同一个任务的不同理解，这使得这种理解上的差异在实际开发进行之前就得以暴露，并通过有效的讨论消除分歧，达成一致的认知，很大程度上降低了后续的风险。
为了方便大家更方便的进行敏捷估算，Teambition 近期上线了「planning poker」小程序，欢迎大家使用!
作者：Teambition Scrum Master，张子秋
网友评论