估计三「不」原则

1

不存在绝对准确的估计方法

目前，公认有效的软件开发规模估计方法就是专家估计法（找一群领域专家来拍脑袋）[1]。你可以想象，这个过程得到的结果是无法绝对准确的，但这已经是最可行、最准确的了。其他所谓科学的方法（功能点、UCP等等）并不会更准确。其实，我见过的科学估算过程大致如此：

• 先偷偷拍脑袋，形成一个心中的估计结果；

• 进行科学估算，得到一个估计结果；

• 调整参数，最后科学估计结果符合拍脑袋结果；

• 科学估计结束！

2

不要将估计变成承诺

尽管估计结果不能绝对准确，但用估计来做初步计划是可以的。可是，如果要求团队根据不精确的估计结果，承诺开发完成时间（上线时间），并且不留下任何调整的余地，长此以往，将对实际工作造成损害。这是因为：

• 可能会让估计者过于保守。当团队认为估计结果将被当成承诺时，人们往往倾向于自我保护，放大估计值。软件开发过程中充满不确定性，这种做法的出发点很容易被理解。我的前任老板，软件工程大师Ivar曾半开玩笑地说，他会把他的初步估计乘以π，然后给出一个承诺。

• 可能会伤害信任。由于估计结果（承诺）较为保守，容易引起一些了解开发的业务人员质疑甚至挑战。遇到这种情况时，开发往往抛出技术原因进行解释，但不信任的种子已经埋下。有些业务部门甚至派生出专门和研发讨价还价的组织，这就是我们常说的「合同游戏」。

• 可能会损害质量。并非所有的研发管理者都遵从保守主义，估计结果有时可能较为乐观。在这种情况下，如果坚持让研发人员遵守承诺，而团队的实际能力并不符合，可能会为了按时交付而放弃质量，甚至最终损害企业商誉。

团队进行自我承诺是个比较复杂的问题，这涉及到心理学领域的内容。鉴于篇幅有限，我不在这里展开讨论。文末注释[2]-[5]是相关的延伸阅读，供感兴趣的同学参考。

3

不要用估计做研发详细计划

软件开发是个复杂的信息发现过程，很多问题在初始阶段无法得到正确答案，比如：用户要的到底是什么？如何实现？实现的质量怎样？……创意实现是个高度动态的过程，不断有新信息被感知、被发现。利用估计信息做详细的研发计划，很容易得到费力不讨好的结果。下图是个用甘特图微观管理每个开发测试任务及依赖关系的例子，这种做法的实践效果往往不尽人意。

我也不建议领导过分关注「计划达成率」等进度控制指标，这与把估计当成承诺有类似之处，也会产生前面谈到的负面作用。

本文中提到估计三「不」原则时，简单列举了一些不适当的做法，这些做法多少违反了估计的根本目的。业界大牛 Martin Folwer 在他《估计的目的》一文中特别指出，估计的价值是支撑管理者做出重大决定，例如帮助分配资源、协调进度、提升沟通效率等等，有兴趣的同学可以参考注释[6]-[7]。

估计一事本身并无好坏之分，关键在于使用的方法是否正确，并在实施过程中把握收获与代价的动态平衡。

下面，我通过两个实际例子，解释何时应该估计，何时无需估计。

场景一：大型重点项目开发

绝大多数大型重点项目在项目初始阶段，便已经有了明确的计划上线时间，规划了需求的初步范围，并对质量有着较高的要求。如果这类项目面临时间紧、资源紧张、交付压力大等情况，推荐的估计排期方式是：

• 初步进行用户故事拆分

• 采用相对估计技术进行估算

• 从用户场景出发，讨论并快速框定项目范围

• 按业务优先级排定迭代交付计划

• 进行风险分析（市场、资源、技术），提出风险规避与应急方案

• 相关各方达成共识，正式进入迭代0

下图是我们在2014年辅导的一个项目快速启动现场，这是个创新性的银行项目。四天里，业务和IT协作拆出350多个粗粒度的用户故事，制定了迭代计划、关联系统计划、看板建模、风险应对方案。之后，团队在三个月里完成6个迭代，项目不但按要求准时上线，产品内容、功能和质量都获得了很高认可，在当年也获得了国内若干重要奖项。

尽管相对估计并不完全准确，但它足以帮助团队根据业务优先级和预估工作量，选择合理的方式排定迭代计划，启动开发。这类项目的时间和质量往往不可挑战，解决问题的关键在于能够让领导接受「确保上线时间，但需求范围可调」，在迭代过程中根据实际情况调整需求细节，以及时应对不确定性，最终达到高质量准时上线的目标。

当然，对预先计划进行调整很容易引起反对或者质疑，业务和IT之间的信任关系也非朝夕可以建立。因此，在项目交付过程中，持续使用看板系统和累积流图，实时透明研发进度和风险非常重要。只有相关方对进展和风险有充分了解，才能更好地应对问题，进行协作。

第二个例子，针对不需要估计的情况。

场景二：已有系统维护

系统维护工作的主要特点是需求到来的不定期性，虽然很多时候没有明确的上线时间要求，但相关方往往希望能够尽快上线。对于这类维护工作，可以采用统计的方式进行管理，即针对一些关键指标进行统计，比如端到端的前置时间分布。可以根据实际数据，比如需求从提出到上线的时间，画出下面的图形。

如上图所示，我们可以计算出「在85%的情况中，团队需要多长时间来完成一个功能」，这个指标叫做「85%需求交付时间」，我们也可以采集中位数、峰值等指标。有了这个统计结果之后，团队对常规需求不用再进行估计，只针对这个指标进行持续优化改善即可。业务部门也可以根据这个指标和需求的紧迫程度，来计划一项工作的最佳启动时间。

国外目前有一个思潮，叫做「抛弃估计」运动（No Estimation）。感兴趣的同学可以阅读注释[8]-[10]进行了解。

最后，回顾一下本文开始部分提出的三“不”原则：

• 不存在绝对准确的估计方法

• 不要将估计变成承诺

• 不要用估计做细粒度的研发计划

估计的价值，是支撑管理者做出重大决定。

从预先估算变成估计（可参考「放弃点数估算」一文对估算和估计的重新定义），这个变化类似于从经典物理学进化到量子物理学、统计物理学。这是从确定性思维向不确定性思维的转变，要求团队成员，尤其是管理者转变熟悉的工作流程和方式，积极拥抱不确定性。这个过程不容易，但对企业成长意义重大，未来我们将继续撰文，进行阐述。

参考文献：

[1]https://en.wikipedia.org/wiki/Software_development_effort_estimation

[2]https://www.mountaingoatsoftware.com/blog/commitment-driven-planning

[3]http://www.agileconnection.com/article/self-abuse-sprint-commitment

[4]https://www.scrum.org/About/All-Articles/articleType/ArticleView/articleId/95/Commitment-vs-Forecast-A-subtle-but-important-change-to-Scrum

[5]http://blog.cutter.com/2011/03/08/committing-to-commitment-in-agile-teams/

[6]http://martinfowler.com/bliki/PurposeOfEstimation.html

[7]http://code.csdn.net/news/2819467

[8]http://ronjeffries.com/xprog/articles/the-noestimates-movement/

[9]http://www.djaa.com/noestimates-beef-and-agiles-trojan-horse

[10]http://neilkillick.com/2013/01/31/noestimates-part-1-doing-scrum-without-estimates/