软件承包方如何应用#NoEstimates

之前 InfoQ 针对 Vasco Duarte 最近新推出的 _#NoEstimates_ 书对其进行采访 ，本次InfoQ 就如何在契约环境中应用#NoEstimates 技术，如何面对评估项目的典型需求，如何建立协议，如何签约和建立信任等问题对其进行了再一次访谈。

InfoQ：我们怎样才能像合同软件开发人员一样应用 #NoEstimates？

Duarte：与遵循通过任务 + 估算定义的预先确定的计划截然不同，#NoEstimates 是一整套思想，可以应用到任何软件开发工程中，以重新聚焦软件开发的交付价值为目标。

使用用户故事代替传统的工作分解结构这一基本思想已经是向 #NoEstimates 方向跨出的一步。正如微软的 Bill Hanlon 发现的（参见故事视频）通过计算故事点数（假设你尊重定义故事的 INVEST 方法。），你可以轻易地预测项目的发布日期。

Bill 与我分享的试验结果告诉我们一件事：我们不需要提前估算整个项目也可以知道项目的发布日期。因此，回到我们的问题，如果你想知道的是何时可以交付项目，那么答案非常的简单：度量你的团队交付用户故事的速度，随着时间推移做出计划从而找出已知故事能够交付的可能的时间范围。

在软件开发承包中（离岸、近岸或外包），通过一开始专注定义项目必要的故事（例如通过故事图谱）能够更容易实现。

InfoQ：作为合同软件开发者，我是否应该考虑在下一个项目/合同中使用这项技术？

Duarte：通常这个问题与担忧不能在决策过程中给客户提供关键信息有关。通常来讲，合同软件需要承包方知道他们可以投资多少到这个项目（通常是团队数量乘以时间）和为了得到一组特定功能，客户需要付多少。

到目前为止，看上去这些很符合逻辑。但是，当需要对那些问题进行回答的时候，最关键的问题交付价值没有被问道。我举个大家熟悉的具体的例子。

客户要求对项目进行投标（明确了的一定范围），然后承包方对项目进行估算（现在我们有了明确的范围和时间）。该合同最终确定并签署，我们开始开发。让我们回顾一下刚刚发生了什么。

• 在确切知道他们需要什么（他们知道自己要什么，但是知道你需要什么需要基于可运行软件之上的反馈，而这后面才可获得）之前，客户定义了一组功能（范围）。
• 承包方考虑之后明确了投资额，在一个时间范围内，投资额足够支付客户的要求（范围），是可接受的（进度表）并且这个价格是他们愿意支付的（成本）。
• 为了提供标价或者报价给客户，承包方做了一定数量的假设：一个确定的团队或者至少是团队规模，团队成员的技能级别（为了交付 / 开发软件）和客户成员的技能级别（以便能够进行沟通，和回答团队的问题）。
• 重要的是，在大多数情况下，假设中关于各方的时间可用性、技能和团队规模并没有在合同中规定，因此也就没有讨论过。

此时，软件交付过程“启动”了，并且在有些时候总是会出现“惊喜”。可能是最初的开发人员不可用（离职或者被分配到另一个项目中），客户急于实现季度末的一些目标而没有时间回答问题，等等。你可以想象得到的：总之意外发生。

现在我们该怎么办？难道我们要重新做计划？改变原报价的价格？

在我的书籍 #NoEstimates中，我更详细地解释了一个不同的建议。与其试图前期定义所有的参数，我们只定义已知的和 / 或者关键的。当然，项目价格必须有个上限，因此我们定义了一个预算。通常情况下在客户端会有一个或者多个人负责“审批”承包方的交付，最后，对需要交付什么样的软件有了一个总体思路。再此基础上，另外一种交付软件的方法将是：

• 明确项目投资箱（investment-box）（预算）；
• 明确项目时间 / 人的配置箱（allocation box）（预算的另一种形式）；
• 明确截止日期和交付 / 论证价值的节奏（指导团队验证和定期交付价值的约束）。
• 设置一个定期、循环的过程，通过它更新用户故事 Backlog，计划交付率（每周能够完成的用户故事数量？）从而评估所有已明确的用户故事的最终交付日期，并根据预算定期评审交付日期。

这个过程看起来特别像 Scrum（但是没有估算），能够在开发过程中提供持续的透明度，同时确保客户能够得到需要的（不仅仅是想要的），而团队能够管理项目，以适应最初商定的预算。

我在 _#NoEstimates_ 书中和为此书视频采访 Sven Ditz 的记录中更详细地解释了这种方法， Sven Ditz 是德国 Sitegeist 的 CEO。另外，我还采访了 Biko2 的 CEO， Diego Cenzano 和其它 7 名#NoEstimates 实践者，以解释#NoEstimates 思想在全世界范围内不同类型的软件项目中是如何使用的。

InfoQ：很多时候，承包方开始工作前需要的第一件事是制定合同，也就是达成协议。如果使用 #NoEstimates，这份协议的基线应该是什么？

Duarte：协议是任何形式的合同的必需品。估算的或者类似 #NoEstimates 的合同。协议是双方都确信一起协作收获的比失去的更多的另一种说法。估算很难做到这一点，实际上如果估算是合同中最关键的因素，我们将会有少得多的合同，原因很简单：在评估软件项目的真实成本时，估算真的是一个非常糟糕的工具。并且项目越大，估算为项目设置的可接受的成本的上限越糟糕。

• “被调查的大型系统完成时，大约有 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% 的传统项目都失败了（没有交付解决方案）或者受到挑战（项目确实满足成功标准）。
• Accenture 在著名的、拙劣的 NHS 项目中避免了 10 亿英镑的罚款。在这个故事中，估算不是唯一需要指责的事情，但是缺乏支持增量交付导致了这次失败，并且鼓励对估算工具的信赖加重了这次失败。

这些只是我们切身知道的众多案例中的少数。在为软件项目设置成本上限方面，估算是个低效率的工具。

因此，承包方和客户关系之间的基础协议应该明确常规规则和可验证的交付价值。如果我是客户，我希望明确在没有看到具体的价值交付时我能够走多远；另一方面，如果我是承包方，我希望知道我能够多快地从客户那里获得反馈，以确保我们交付了正确的功能。

当客户对交付的价值满意，并且不需要更多交付工作时，应该有一种简单的方法可以结束合同。相反，如果客户的反馈迟迟不来，后期交付被拒绝的风险非常高，供应商应该有暂停合同的机制，直到获得反馈。

构建软件不像盖房子，你不能在前期指定一切（房子建造者也不应该这样做），它应该是灵活的，因此应该基于客户和承包方双赢的基础上进行开发。

InfoQ：根据你的经验，这种方法通常适用哪些合同？它们中是否有一些与该方法互相矛盾？

Duarte：这是个非常重要的问题，以至于我们让 Evan Leybourn 根据 _#NoEstimates_ 书写了一本迷你电子书，解释了合同类型，和它们在建立和管理客户和承包方之间的信任如何重要。我们不需要深入细节，因为 Evan 在迷你电子书中解释过了，重要的是必须认识到一些合同是支持使用双赢方法的（比如#NoEstimates），而其它一些合同存在将风险（和指责）从一方转移给另一方。

举个例子，我们可以参考固定成本，固定范围，固定时间的合同，将其作为低信任环境下使用的合同范本，但是这不能建立信任，反而进一步放大了互相之间的怀疑。承包方将奖励（滥用）使用变更请求合同条款（一切合同中没有规定的都需要额外支付）的行为，而客户将会奖励争辩一切新想法都已经以某种方式纳入原有范围的行为。由此产生的道义力量可能被很多人所熟知，而且正好与第三届敏捷价值相反：客户合作高于合同谈判。

在另一端，我们有不依赖合同工作的组织（在我的 _#NoEstimates_ 书中，我采访的一个 CEO 就是这么做的），每两周交付价值，基于价值继续或者停止关系，双方组织都能从合作的工作中获得驱动力。

需要明确的是，这些都是极端的案例，但是他们阐述了一个不支持使用#NoEstimates 的模型（固定时间、成本、范围的合同），而其相反面我们称为 #NoContracts 的模型支持使用 #NoEstimates，并基于持续专注价值交付。

正如 Sven Ditz 在采访中推荐的，你不应该尝试与每个客户建立#NoContracts。一些客户可能比其他人更愿意接受在没有合同的基础上工作的想法（同样也会合法保障他们权利）。当实施创新思想，比如 #NoEstimates 或者 #NoContracts 时，我们必须找到那些愿意尝试，愿意在这种模式下工作的客户。

InfoQ**：#NoEstimates意味着至少两个组织实体之间要有信任存在。对于如何开始建立信任，你有什么建议？**

Duarte：这个问题很好。正如我们讨论的，当我们讨论合同时，信任是我们随着时间并借助工具建立起来的，合同就是其中一个工具。但是，对于软件团队而言，有一些非常强大的工具可以用于建立信任：及早并经常向干系人交付价值。这一敏捷原则是我们建立信任的关键工具之一。其它信任建立的工具是透明性，并且是我描述 #NoEstimates 时极力关注的。前段时间我跟一个规划经理（在一个规划中管理多个项目）交流过，我们试图得出团队（多个项目）能否按时交付规划的结论。对进度担忧的规划经理认为不同的项目团队将按时交付，他的理由是：他已经问过团队。团队答复他，他们已经花时间估算过他们的项目，并且认为（团队中的每个人）他们有能力按时交付。

他心想“太好了！”每个团队都能够按时交付。原来他靠估算每个单独的团队，他从来没有考虑过整个规划的交付速率（我们正在为移动设备交付单一源代码库，包含很多应用）。我确实考虑过整体交付速率，我使用 #NoEstimates 对 **完整系统** 的生产能力进行了估算，即所有团队一起交付一个可交付的系统。我的观点与他不一样，我知道（不是估算）所有项目一起的交付率或者生产能力还不足以按时交付规划。我有数据，并向规划经理提出。他有礼貌地聆听了，但是可能认为我疯了。毕竟，在规划（不是项目）管理学院我们被告知项目计划加上估算的结果就是“事实”。如果每个团队都单独估算过他们能够按时交付，那么整个规划当然能够按时交付。一年后（6 个月的规划实施了 18 个月）规划被迫取消，而公司最终倒闭了（许多原因，不仅仅是那一个规划）。这个案例中我对我的正确感到遗憾。但是在现实中我是错误的，我仅仅是个信使。系统是正确的。系统的生产能力告诉了规划经理，他和公司将会失败，但是规划经理从来未被教导考虑系统度量指标，更别说相信。跟我们许多人一样，他只被教导相信人类设计的对未来事件的估算方法，尽管我们行业的估算都是非常糟糕的追踪记录（见上文）。

因此，要建立信任：专注度量系统。估算只会延迟反馈（你发现时已经晚了，太晚了），而使用系统度量指标比如生产能力、周期时间给了你想要的透明，从而在项目生命周期及早做出决策，并且有额外的好处，你甚至不需要长时间坐下来，抽时间开估算会议。

套用丘吉尔名言：最终，不管我们使用多么完美的技术（估算），我们必须偶尔看看结果。何况估算确实拥有如此糟糕的追踪记录。

InfoQ**：Vasco，我敢肯定你已经听说过最小可行性产品。对最小可行性产品你有定义吗？**

Duarte：这个问题很好。在定义之前，让我们看看我们希望在合同中列出的特征。

• 从客户角度来看，最小的合同应该：

• 降低诉讼费，但；

• 提供对不法承包方的法律保护；

• 制定明确规则，用于评估可交付成果是否成功；

• 如果可交付成果不达标准，允许客户获得赔偿；

• 万一双方关系不可持续，允许客户更改承包方。

• 从承包方角度来看：

• 消除承包方和客户之间的中间人（比如律师），以便创造一个透明的关系；

• 提供对不法客户的法律保护；

• 制定明确规则，用于评估可交付成果；

• 缩短交付和审批之间的反馈环，从而降低拥有大量可交付产品却要等待审批（和支付）的风险；

• 允许承包方为他们的贡献（时间、材料和 IP）获得相应的补偿；

• 如果双方关系不可持续，允许承包方解雇客户。

大多数要求都可以通过承包方和客户之间一个简单的协议满足：

• 承包方将会基于商定的总体目标工作一个周期也就是 2 周（或者更少），特征或者用户故事将在一个类似真实的环境中收集和验证，并且承包方能够在 2 周结束的时候完成特征或者用户故事。
• 2 周内迭代的投资是由双方预先规定的。例如：3 名开发 / 测试人员，1 名产品负责人，1 名 Scrum Master。
• 2 周结束时客户有权拒绝交付的东西并不支付。
• 同样，承包方有权在任何迭代边界（本例中是 2 周）停止项目的工作。

许多团队在实现 Scrum 并将其作为软件开发方法时，所使用的规则跟上面的很相似。这种方法不需要估算，只有及早和定期交付价值才能满足客户的业务需求。

上述规则的另一个优点是，风险非常低（也就是 2 周的投资），承包方和客户都可以放弃合同的必要性，仅仅基于这些规则开始工作。这个方法跟 Sven Ditz 在为 _#NoEstimates_ 接受的视频采访中解释的方法特别相似。

查看英文原文：#NoEstimates applied to software contractors