#NoEstimates作者问答

Duarte ：大约2011-2012年，我正在为 OOP2012准备“故事点是有害的”演讲。作为这项工作的一部分，我开始在 #estwaste标签下发推特，并且同时 Neil Killick和Woody Zuill开始发类似话题的推特。最早记录在案的有关 #NoEstimates的推特是 Woody Zuill发出的，并且之后这个话题在推特上瞬间起飞。我有数个有关这个话题的 Skype讨论，Woody Zuill就此话题通过 Skype采访了超过100人。很明显人们对此话题感兴趣。我在 #EstWaste（用于估算是一种浪费）原标签下发的推特从来没有真正起飞，但是 #NoEstimates这么一个简单的标签却在我们行业启动了一场引领需求的谈话。

从推特上仍然活跃的对话（3年后！）中我们可以看出我们解决了软件行业一个真正的问题。到目前为止，仍然有许多人在标签 #NoEstimates下发推特，并且许多会议仍在讨论此话题。在软件行业有一个社区聚集在这一非常重要的话题周围。

Duarte ：通过使用被我们称为估算的工具解决了很多问题，就是这么简单：一个工具，没有别的。你提的问题非常重要，因为一旦我们确定了问题，或者确定了我们试图解决的问题，如果工具（估算）适合我们，我们就可以做出明智的评估。

到目前为止，我已经设计和举办了多场研讨会：“#NoEstimates：专注真正重要的事情”，并多次询问参与者这个问题。答案从明显的：“为了了解项目什么时候可以交付”到可预测的:“为了计算项目的ROI（投资回报率）”。问题是这些答案没说全，他们忽略了使用估算作为工具来回答这些问题背后的假设。他们假设估算在大规模应用中（在整个 IT行业）是可靠的，但是，这不符合我们看到的实际情况。被大量引用的 CHAOS报告报道了，年复一年项目是如何延期并超出预算的。为了辩解，许多人会说：“项目不应该通过是否准时、是否符合预算进行评分，还应该有其它因素，一些更重要的变量”。我同意。按时、按预算不是项目是否成功的主要因素。在一个案例中，虽然项目被延期了200%，但是当发布时，项目带来的影响完全改变了公司，它帮助公司开拓了新市场，创造了新的商业模式并且现在创造的收入大约占公司收入的50%。计划很重要吗？可能，但是肯定不如公司试图交付的“价值”那么重要。最后，价值胜过准时、按预算的考量（在某点上），而这是我不断在我的 #NoEstimates演讲和研讨会上强调的一个关键因素：专注价值，基于价值做决策而不是估算。估算不是项目是否成功的好的预测工具。

Duarte ：我说不好什么使得估算如此困难。但是大多数人都知道确实如此。每天我们的工作中都会遇到这样的情况。多份调查统计同样支持估算很困难的主张。我们看看这个小例子。

• “被调查的大型系统完成时，大约有66%的经验计划被延误&成本超支”，出自 Capers Jones发表在 Crosstalk, the Journal of Defense Software Engineering上的“ Project Management Tools and Software Failures and Successes ”。
• 2011年，CHAOS报告中被调查项目的平均延误率是63%。这个数字与我2003年在一个软件开发公司做的私人调查一致：被调查的17个项目的平均延误率是62%，并且最大项目的延误率是200%。
• Scott Ambler在软件行业做了一次有关项目成功率的调查。 他的数据表明2013年以来 53%的传统项目都失败了（没有交付解决方案）或者受到挑战（项目成功满足成功标准）。

从不同渠道的其他调查中我们也能发现类似的结果。这些例子证明一件事：作为一个行业我们不善于估算。当然，有些人会声称他们是特级预测师，但是特级已经暗示大部分人都不是特级。我们需要建立一个有道德、负责任的软件开发方法，而估算不是一个好的工具，因为他们未能交付承诺（知道可接受范围内的时间/成本），并且在组织内催生了许多不同的功能障碍。在本书中，我解释了其中一些功能障碍，比如：估算谈判（estimate bargaining），政治游戏等等。

Duarte ：是的也不是的。#NoEstimates是一个原则性的方法，用来解决我们行业里的一个特定问题：为了理解和能够按照项目成本和时间工作，人们应该使用估算的替代方案。当你在特定环境中应用 #NoEstimates原则时，你可能仍然会拿估算作为走向下一阶段 #NoEstimates的踏脚石。我在本书中解释了这一情况，并将其描述成“走向 #NoEstimates的7步旅程”。

在我的印象中，估算很少用到，即使需要它们只是指向另一个我们应该解决的功能障碍。在这种情况下，消除估算才是真正的目标。但是就像丰田公司为浪费设计的多层次方法（不必要的浪费和必要的浪费），我们也必须为估算设计一种方法。有时我们必须接受估算，但是我们应该努力设法消除估算的需求。这是有可能实现的，并且我已经帮助过许多团队和组织完全消除这种需求。在本书的后面章节中，我们将跟随 Carmen——#NoEstimates故事中的英雄——因为她发明了一些方法可以消除估算的浪费，同时还能够回答一些客户会问的关键业务问题，比如“我们能否按时发布这一特性？”

Duarte ：这个问题非常重要，也许值得出本书。简单来说，项目列表的优先级预先假设了列表中的所有项目都是必要的。但是事实往往并非如此。正如我们知道的许多我们最终交付的项目功能其实客户很少甚至根本没有使用过。然而，这些不必要的项目也需要时间和精力来开发，并且在某些情况下，大大增加了我们项目的风险。优先级假设 Backlog中的所有项目都是必须的。我不会做这种假设。因此我帮助我的客户了解他们的商业模式，然后谨慎地探索如何利用或者放大成功的商业模式。要做到这一点，你需要专注选择具有重要影响力的试验（特性或者故事），而不是盲目地交付一连串详细的需求列表。这样可以一心一意专注“影响”（或者成果）而不是产量（我们能够交付多少故事），这种专注允许我们发现项目的真正价值。这就是为什么我更喜欢讨论选择影响最大的项目，并快速交付，而不是在一连串的需求列表中讨论#34与#35相比哪个更有优先级。

Duarte ：这个问题非常好，因为它清晰地揭露了 #NoEstimates辩论中最重要的谬论之一。#NoEstimates批评家经常说你不能计划除非先估算。当然，这完全是错误的。估算是“评估”计划大小的工具，在进行估算之前，你需要先构建计划。比如，我们不需要估算故事也可以轻易决定哪些故事应该纳入 Srpint。我工作过的许多团队都会基于目标往 Sprint中添加故事，甚至都不评估故事大小。当他们开始执行这些故事时，他们会与 Sprint目标进行比较，不断地重新评估他们的现状，并会向 Sprint中添加或者删除故事，以便帮助他们完成 Sprint目标。目标可以是：提高X的性能，以实现每秒500次的事务。这种目标没有规定“如何做”，仅仅规定了“为什么”。我们会因为目标而决定是否向 Sprint中添加或者删除故事，而不是因为其它原因。

上面的 Sprint案例说明了在 Sprint阶段你如何将估算和计划分开。在项目阶段同样可以做到。许多我一起合作过的客户他们有着必须继续运行的业务或者必须达到的商业目标。与其致力于交付一组特定的特性或者故事，以实现这些目标，相反他们做持续计划。我们在一开始就定义项目的目标，定义项目的投资（预算，而不是估算），然后在约束条件内（可能是时间，金钱或者两者）持续管理范围，实现交付目标。

这种培养方案专注价值和持续交付价值，这些我会在下文进一步解释。

Duarte ：在本书中，我详细描述了如何跟踪进度并对干系人透明进度。简单来说，我计算已经交付的项目数量，并与 Backlog中的项目数量进行比较。人们常做的一个假设是，你需要知道项目清单的完成情况，从而跟踪进度。然而在实践中，除非到项目后期，我们很少能够知道“所有的项目”。范围蔓延（或者我称之为：价值发现）是任何软件开发项目的自然过程。随着我们开发项目，我们会发现更多的价值，理所当然我们也希望交付新发现的项目。

因此，我从来不认为范围是固定的，或者 Backlog已完成。我计划（预测）未来交付率（已交付项目除以已交付项目花费的时间）并评估在剩余可用时间内我们能够交付的项目数量。不可避免地，在某个时间点 Backlog中剩余的项目数量大于基于我们交付率能够交付的项目数量。这时，我们就要启动项目最关键的对话：我们应该交付哪些项目？我们应该从 Backlog中移除哪些项目？我称这个过程为：持续范围管理，在这本书中我称其是软件项目管理最重要的工具。很多人会认为这是个艰难的对话，充满了艰难的期望管理。我同意，但是这种类型的对话有助于我们专注价值，持续交付价值。简单来说，与一个不可避免的脆弱的计划相比，我用这种方法促进价值交付对话，而不是度量产量。遵循计划（我们估算的结果）是一种脆弱的软件项目管理方法。如果我们希望在软件开发方法中实现敏捷，我们必须建立反脆弱的项目管理方法，而 #NoEstimates是这些方法之一。

Duarte ：在前面的问题中，我提到过唯一一个工具：持续范围管理，有助于我们按时交付软件项目。但是探讨为什么持续范围管理是必要的非常重要。其中一个重要原因是当我们开始开发软件时，我们能够更好地了解为了交付我们需要什么。在我们进行开发、论证和获取反馈的时候，有关正确功能的新思路出现了，比如有价值的功能。我们称这种发现的价值为“范围蔓延”，随着范围不断的攀升，当最终我们注意到的时候，我们已经遇到太多需要交付的项目。我不喜欢“范围蔓延”这个术语，因为它隐藏了现象的真正本质：在我们交付原计划的价值的过程中，我们发现了其它价值。遵循原计划（在一组明确定义的功能的基础上进行的估算），那么我们就会将价值发现看成是范围蔓延，并忽略这一价值。而且还会有一个很好的理由：接受所有的变化将会使得项目错过截止日期。在估算驱动的软件开发中，计划和时间表优于新发现的价值，而这会在估算驱动的软件开发中导致一个功能障碍。

我采取了不同的方法，我帮助团队在限定的时间和投资箱内工作，但是同时不断调整范围，以提供更多的价值。为此我们使用我在 #NoEstimates 书中描述的预测方法，这样我们可以放心地改变项目范围，以实现增量交付更多价值，而不是试图遵循原计划。预测方法的副作用是它在项目初期阶段引入持续范围管理，多亏了预测技术，我们从一开始就能管理范围。另一种方法将会不断地重新评估我们发现的一切，和计划中的每个变化。这显然是一种浪费，尤其是当我在演讲中提出了另外一种方法（基于数据的预测），可以给我们接近100%的准确度等级的时候（这些演讲你可以在 YouTube上找到）。

Duarte ：如果你想开始了解更多的 #NoEstimate，这里有很多资源，Woody Zuill在 他的网站 上收集了多位作者的博客列表。我也从多位作者那里收集了 “入门指南” 的文章集合。对于那些有兴趣深入研究如何应用 #NoEstimate思想的人，我写了这本 #NoEstimate 书籍，已经在 OikosofySeries网站 推出数字版本，不久也将在亚马逊上推出。想更多了解这本书，包括免费获得第一章，你可以进入 NoEstimatesBook.com并注册。注册完后你将获得一个链接，用于下载本书第一章节与目录。

写这本书的时候，我意识到我不可能写一本集娱乐和资讯于一体的书籍，同时涵盖我想涵盖的 #NoEstimates各个方面，因此我与Tomas Rybing和 Evan Leybourn合作，他们写了两本有关无估算的迷你电子书指南。Tomas写的是 capacity planning with #NoEstimates ，Evan写的是 contracts and how they define our relationship with clients in ways that either support or make difficult the use of practices like #NoEstimates 。

除此之外我还做了更多的工作，我针对 #NoEstimates视频采访了9个人。本书包含了对其中4名无估算实践者的采访。我想重点强调一下 Clinton Keith的采访，他给我们讲述了一个非常令人兴奋的故事：他是如何将以前需要18个月的项目变成不超过2周的工作量！我彻底被这个故事震惊了，并认为这个故事的一些关键见解能够帮助那些有兴趣应用 #NoEstimates的人。

在这9个视频采访中，还有2个是对 CEO的采访，关于在他们自己公司应用 #NoEstimates思想。

—— Seitgeist 的 Sven Ditz：在他自己的公司中应用无估算。在他的视频中，他讲述了一个令人兴奋的故事，他是如何彻底废除投标过程的需求，甚至在没有提供投标的情况下赢得交易。

—— Biko2 的 Diego Cenzano，一位资深的 IT创业者，讲述了一个美丽的故事：他如何使用自己的方法（不需要估算）帮助客户专注价值（预期之外的价值）。

#NoEstimates 这本书旨在希望在我们行业启动一场期待已久、引领需求的讨论：我们如何持续提高工作方式，在软件领域立足方法和工具中的决策实现更好地工作。不要忘了估算不是为软件项目开发的技术。我们认识和接受这一工具可能不会应用在我们软件开发领域只是时间的问题。