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

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

背景

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

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

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

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

 

问题分析

以上两个问题也是敏捷初始团队常常碰见的问题，现简单分析发生缘由以下：

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

团队从瀑布开发方式转为敏捷开发后，学习了敏捷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。

 

了解更多

以上是针对不了解估算核心概念而致使估算活动不理想的解决措施。朋友们看到这里，相信对估算的核心有了基本了解。也许对什么是故事点估算以及具体估算方法感兴趣，欢迎阅读接下来的关于估算的另外两篇文章，即《如何估算第三篇：利用故事点作估算》和《如何估算第四篇：利用2种常见方法作估算》。

 

参考附录

1. Kenneth S. Rubin. Scrum精髓[M].北京：清华大学出版社。
2. Mark C. Layton. 敏捷项目管理[M].北京：人民邮电出版社。
3. Rachel Davies. Liz Sedley.敏捷教练[M].北京：清华大学出版社。