【华为云技术分享】【DevCloud · 敏捷智库】如何利用核心概念解决估算常见问题

华为云开发者联盟

墨衍会员 · AI 创作全网分发码龄10年

关注

原创 2020-06-18 15:13:47 2.9k 阅读 AI 写同款· GEO 优化 ›

摘要：团队用于估算时间过多，留给开发的时间会相应减少，大家工作紧张，状态不佳。团队过度承诺直接造成迭代目标不能完成，士气低落。以上弊端直接伤害敏捷团队，是敏捷团队保持稳定健康节奏的阻力。

背景

敏捷江湖桃花岛社区下线会议时，敏捷实践者问了很多关于估算的问题。作者在这里把具有共性的问题简单做了梳理。问题主要集中在团队只关心估算结果，也就是数字。再则团队经常在外界压力下过度承诺迭代目标。这两个比较集中的问题描述如下：

问题一：团队只关心数字。计划会议大家只关心估算的数字，经常花费大量时间做估算，怎么办？

问题二：团队过度承诺。有时候，团队被迫承诺过多的工作，迭代目标完不成，怎么办？

团队用于估算时间过多，留给开发的时间会相应减少，大家工作紧张，状态不佳。团队过度承诺直接造成迭代目标不能完成，士气低落。以上弊端直接伤害敏捷团队，是敏捷团队保持稳定健康节奏的阻力。

问题分析

以上两个问题也是敏捷初始团队经常遇见的问题，现简单分析发生原因如下：

问题一：团队只关心数字。

团队从瀑布开发方式转为敏捷开发后，学习了敏捷Scrum框架，然后开始使用敏捷开发。他们知道其中有一个事件是迭代计划会议。在会上团队成员经常耗费大量时间做估算。常见对话：“这个估算数字合理吗，我们要不要再好好想想清楚？”因此团队常常陷入无休止的讨论中。团队狭隘的理解为，计划会议中最重要的事情就是估算，而估算最重要的事情就是得到每个用户故事完成所需要花费的精确时间，即数字。也就是说，团队过于追求数字的准确性，忽略了估算的真正核心价值。

问题二：团队过度承诺。

团队经常在产品上市日期已经确定的情况下过度承诺。因为时间紧迫，领导施压（与资金和绩效挂钩）。比如，领导经常说：“大家加把劲儿，我相信大家的能力，努力一下，这些需求你们是可以做完的，大家的表现会影响绩效评估，年底咱们多发点资金。”所以团队常常了了估算、一言堂（架构师说的算）、猜测工作量，最后造成过度估算，经常完成不了迭代目标。

小结

“团队只关心数字”和“团队过度承诺”两个问题是敏捷初始团队经常遇见的问题。从以上问题分析中可知，团队成员并没有了解估算的真正核心意义，导致团队狭隘地理解成估算就是要最后的数字，而且在有外部压力的情况下团队也顾不上认真估算，盲目地过度承诺工作内容。

其实估算并不只是为了得到估算数字和不靠谱的承诺。我们先一起学习和了解什么是估算的核心内容，这样可以更好地理解估算，然后再针对以上2个问题进行解答。

解决措施

利用核心概念树立正确认识

在这里，我们只考虑不了解核心概念而导致估算活动不理想的情况。还有其它情况可以导致估算活动不理想。比如，不会利用故事点估算、不会估算具体方法等。这两种情况我们在后续的2篇文章中给予解答。

通过上一篇《估算第一篇：利用用户故事了解需求》相信了解了如何利用用户故事理解需求。如果对用户故事不太了解的朋友，建议可以花一点时间阅读上篇文章，也会有助于做好估算。

现在我们一起了解一下估算的4个核心概念，以便理解估算，树立正确认识，然后才能更好地解答以上2个问题。估算的4个核心概念所对应解决的问题如下表所示：

问题	估算核心概念
问题一：团队只关心数字。	利用“区分准确与精确”：估算应该准确，但不必过分精确。
问题一：团队只关心数字。	利用“估算相对大小”：人们更擅长对大小进行估算，而不是绝对大小。
问题二：团队过度承诺。	利用“团队一起估算”：在估算活动中，团队成员一起估算，结果更合理。
问题二：团队过度承诺。	利用“估算不是盲目承诺”：估算不是承诺，重要的是我们不能这样认为。

区分准确与精确

估算应该准确，但不必过分精确。比如，我们估算某产品是10888人时（是怎么做到这么精确的？）。其实这是很荒唐的，过于精确的估算纯属浪费。我们需要应该投入刚好够用的工作量，得到一个刚好的、大致正确的估值，如做估算时工作量和准确度的对比图所示：

做估算时工作量和准确度的对比图

在做估算时，有一个收益递减的点，在这个点之外，额外投入任何时间和精力都不会使估算更准确。在这个点之外，就属于浪费时间。

团队成员在做一项工作的同时，难免会遇到各种各样的问题，所以为了做到准确估算，在做估算时，任务的拆分一定要适当细，只有细化后，团队成员才清楚每项工作预计会花多少时间。当然细化也是有个度的，如前面提到的做估算时工作量和准确度的对比。当团队成员反馈超过预计工时时，需要了解是不是遇到了什么困难，需不需要帮助解决。超过16小时的任务建议需要再细化。

在做估算时，我们经常会填写预计工时和实际工时。预计工时是我们估算的结果，实际工时是对估算结果的检验。我们允许预计工时的不准确，但是一定要填写准确的实际工时，这样才有助于我们在估算不准的问题上有充分的证据做分析，然后改进，进行良性循环。随着团队成熟度的提高和对业务的越来越了解，估算准确度经过几个Sprint会有所提高。

估算相对大小

建议使用相对大小而不是绝对大小来估算PBI。比较所有条目，然后确定某个条目和其它条目的相对大小。如下图所示，讨论一个杯子相对于另一个有多大比较容易，但对于杯子中可以盛多少绝对数量的液体，我们可能没有概念。

相对大小对比图

人们更擅长对大小进行估算，而不是绝对大小。让团队成员做估算，建议用大家都擅长的技术。当然，有些较成熟的团队，也可以借鉴历史数据和经验，直接应用工时或理想人天估算也并非不可。更多关于相对大小的内容介绍，可以阅读下一篇《如何估算第三篇：估算故事点》，其中会介绍一个具体实践，即故事点估算。

团队一起估算而不是个别人估算

在估算活动中，团队成员一起估算，而不是仅仅由项目经理、架构师、主要程序员估算。简单说，是负责完成工作的所有人，也就是指实际动手设计、构建并测试PBI的开发团队来估算。产品负责人和Scrum Master这两个角色都在场，但并不实际参与估算。产品负责人负责阐述PBI，并回答团队要求澄清的有关需求的问题。Scrum Master负责帮助指导和引导估算活动。最终的目的是开发团队能够一起确定每个PBI的大小，当然包括开发和测试的所有工作量。团队成员一起估算也是为了确保工作没有遗漏，不管怎么拆分任务，甚至是不拆分任务以story为最小颗粒度，那就按照story可以上线为标准来估算。如果团队非常关注每个人手头上的task，比如测试和开发人员手头上的task，那就没有统一标准，根据具体task内容估算。记录工作项工时，可以参考华为云DevCloud，工作项工时显示如下图所示。

需要客观估算而不是盲目承诺

估算不是承诺，重要的是我们不能这样认为。举一个例子，如果在估算的时候告诉团队成员他们的估算正确性直接影响着他们的奖金和绩效，那么每个人都会给出一个比开始大得多的估值。估算应该是较为实际的估值，应该靠谱，我们不想因为外因而人工放大估算值，变成团队成员往上加和管理层往下减的抛球游戏。

所以，团队成员在没有外因干扰情况下，大胆、放心的估算工作量，也就是估算预计工时。预计工时不仅仅是用于安排任务和估算本Sprint PBI在哪个时间点完成的,它还可以用于持续改进。预计工时就是估算需要多少时间可以完成，在Sprint进行中，会让团队成员根据实际情况去更新实际工时。例如，昨天更新4小时，今天又更新4小时，那就把实际工时更新为8小时。当Sprint结束后复盘时，我们会整体看这些预计工时和实际工时的数据，主要是为了提升团队/个人估算水平。如果估算和实际有明显差距，是需要深入分析的。本身也是期望通过估算促进做简单设计。

应用正确认知处理问题，做好估算

以上是估算的核心内容。现在我们回头看看之前的两个问题。

问题一：团队只关心数字。

面对这个问题，作者主张团队成员不要只是关心数字，还要关心投入产出比（ROI），避免浪费。另外还可以考虑采用更快、更易于理解的方式来进行估算。

从估算的核心概念“准确与精确”中了解到，在做估算时，有一个收益递减的点，在这个点之外，额外投入任何时间和精力都不会使估算更准确。在这个点之外，就属于浪费时间。另外从估算的另一个核心概念“估算相对大小”中了解到，人们更擅长对大小进行估算，而不是绝对大小。让团队成员做估算，建议用大家都擅长的技术。因此，我们在做估算时：首先，要把握一个估算的适度准确原则，不要过度浪费。其次，为了降低难度，团队更好的达成一致意见，可以采用相对大小方式进行估算。

问题二：团队过度承诺。

面对这个问题，作者主张估算由真正完成工作的成员在安全的环境下大胆、放心地估算，避免过度承诺。

从估算的核心概念“团队估算”中了解到，估算活动是负责完成工作的所有人，也就是指实际动手设计、构建并测试PBI的开发团队来完成。也就是说，真正完成工作的人才会对工作需求内容更用心，也更了解团队的速率，他们的承诺更客观。估算另一个核心概念“估算不是承诺”中提到，估算应该是较为实际的估值，应该靠谱，我们不想因为外因而人工放大估算值，变成团队成员往上加和管理层往下减的抛球游戏。团队成员在没有外因干扰情况下（不建议奖金、绩效明显挂钩），大胆、放心的估算工作量。如果能做到以上相信至少在估算的结果上更为客观和靠谱。

有些朋友可能会问，如果得到的估算结果是靠谱的，完成需求就是那么多工作量，产品上市日期也已经确认，那么怎么办？如果真的是因为产品上市日期已定，有上线压力，团队一定要承诺过多的工作内容，那么就确保团队把故事拆分得更细，即使他们交付不出设想中的高档理想的全功能版，至少也能每个典型的功能领域多少交付一些内容。说到这里，还是不建议这样做，尽量采用高价值的事情优先做原则，与客户协商，产品经理对需求排好优先级，优先实现高优先级的PBI。