敏捷合同

对于敏捷方法，人们常常提出这样的问题：“如果基于敏捷工作方式，应该如何签署合同？”

传统的瀑布式模型，与公司采购的方式完全契合：先整理出需求，一家供应商提供一个报价（基于他们对需求的阐释和对成本的估计），大家都签署一个法律上的捆绑协议。

一旦合同签署之后，接下来就是一段开发时间段，大家争论到底哪些功能在范围之内，哪些在范围之外，以及对于合同来说哪些构成变更请求。但是当工作最终完成后，激烈的讨论结束后，客户最终正式验收软件并且为之付款。客户这时得到繁重无比的软件，供应商得到自己的合同款项，所有人皆大欢喜，也许不是所有人吧。

如果供应商和客户都能从敏捷工作方法中得到最大的收益，就要重新思考传统方式工作合同的合理性。这是一个不断演化的领域，公司们在不断寻找适合敏捷合同的新模型。结果就是：扰乱了现状的创新思考着们得到更多机会。

本文检查了4 种不同的模型，供供应商和客户使用，以建立敏捷相关的合同。将来可能出现新的模型，但是现在大概也就这4 种。

揭穿固定合同

固定价格、固定时间、固定范围的合同继续成为IT 行业合同的标准方式。这种类型的合同基于如下想法：在项目一开始可以定义出工作范围；供应商可以从中判断需要什么——或者说多少人要工作多久——并据此计算出一个价格。一旦完成，合同就等于是用血来签署，执行起来也是如此。

这种模型背后的理念是：将软件看做有实体的东西予以提供，也就是说看成购买一定量的通用软件。然而，购买定制软件可不像从裁缝那里买一套西服，更像是购买财务建议。你所购买的，更像是服务，而不是商品或是货物。

我碰到过很多人和公司都希望以上述方式完成工作招标，然而我还没碰到谁能够在成功完成项目的同时，不放弃对于至少一个“固定”项目参数（范围、成本或日程）的控制。IT 行业阐述类似合同已经很多年了，而未能成功交付的情况也出现了这么多年。

这些失败发生的原因并不难找：项目范围变更、新的需求出现、已有需求忽略，错误解读（同样词汇对不同人的含义不同）引发的问题等等。要说明合同范围变更的各种情况，可以写出一整篇文章。不论原因如何，一旦“固定”合同种需求变化，其他所有东西都要跟着变化。先是时间和人员可能需要变动，接下来价格也必须改变。

退后一步好好想想，继续使用这种类型的合同实际上很令人感动。这么做充分展现了信仰和积极思考的力量，以及对于下一次事情将会有所不同的无望之希望。

也许这些合同存在的原因在于：它们能够在法庭上起到辩护作用。一边说合同没有完全兑现，另一半声称早已彻底完成，让法官去评判吧。但是考虑到固定价格合同模型的本质问题，我们可以说这种合同实际上增加了上法庭的风险。最后，应该指出：签订这样一个合同，需要所有相关参与方暂时认可所有需求已知而且不变，估算很准确，质量也可以接受。想想类似的合同过去的历史，这真是让人有点讶异呢。

不适用所有人

在进一步展示更多内容之前，我想指出：不是所有开发软件或是尝试敏捷的公司都会收到类似问题影响。创建并销售软件产品的公司，有时被称为ISV——独立软件开发商，比如Adobe 或是Intuit，他们只会受到一些边缘影响。他们绝大部分的客户只购买完成多产品，对产品功能没有多少直接决策权。

有些企业的IT 组织也开发软件，但是也能避开这个合同问题。他们直接购买已经完成的软件（比如SQL Server），或者开发供公司自己使用的定制软件。很多企业的IT 部门会把工作外包，然后需要创建合同，并就其达成一致。在这些情况下，IT 部门是第三方软件供应商的客户。

承接企业IT 部门转包合同的服务公司，有时被称为外部服务提供商（External Service Provider，简称ESP），它们最需要敏捷工作合同。

敏捷能够轻而易举地融入到ISV 的工作之中。实际上，很多敏捷实践都在这个领域内兴起。同样地，只要企业的政策和流程允许，敏捷也能够符合企业IT 领域的要求。

但是，ESP 与其客户们接受敏捷就有点困难，因为两者之间需要有一个法律合同。不过这个问题之中也孕育着机会。

因为客户（企业的IT 部门和政府部门）知道IT 项目会遇到问题，因此合同条款就已经变得更加严苛，财务方面的惩罚也更加高企。只有最大型的ESP 公司们才能考虑投标大型合同。小公司承担不起惩罚条款，因此无法与有钱负得起大额罚款的大企业竞争。

改变合同结构，也就可能改变大企业消费者购买定制软件的方式，并且提供公认的“双赢”结果。相对于市场领导者，能够打破固定价格、固定范围和固定时间合同的供应商就能获得更多竞争优势。客户也能够从提供更高产出的创新方法中获得收益。

选择1：隐藏起来（Hide it）

在交付合同中使用敏捷，将其隐藏起来是最简单、最没有破坏性的方式。不要告诉客户你的做法与通常做法的区别。以正常方法估算、规划工作，签署一个完全正常的合同，然后用敏捷技术来改进交付结果。

测试驱动开发、持续集成、定期重构和重新规划，这些敏捷实践都能帮你更好交付。想办法尽可能忽略最初的计划，因为它是“错误的”。如果可能，把它抛在一边。

问题在于，某些客户希望看到“按计划的进度”。你可以做一个假的出来。我听说某些团队会定期更新计划，就好像他们真得遵循了这个计划一样。不过这种方式不足以取信于人，如果客户相信我们虚构的进度，我们又怎么能指望建立与他们之间的信任呢？毫无疑问，我们不想对客户撒谎，我们希望建立信任，如果我们假装遵循某个计划，他们又怎么能相信我们？

当然，你可以说：相对于真正的交付，客户希望按照计划看到工作进展状况，这样的客户也没有表现出信任。可不管怎么说，我们作为承包商，让他们信任我们，这是我们的职责。

因此，要想让“隐藏起来”这个方法起效，必须要有类似于“你不问，我不说“这样的策略。如果你的客户愿意服从该“策略”，并且愿意根据真正的工作交付来衡量进度，而不是去看原来的计划，隐藏敏捷的方式也许可以生效。但是如果你的客户这么通情理，也许你就没有必要在一开始把敏捷藏起来了。

选择2：不起作用不收钱（No cure, No pay）

采取“不起作用不收钱”的方式需要一定的自信。这个方法很简单：如果客户不喜欢你交付的东西，那就不收费。不过，如果他们为你开发出来的东西付费，他们也不能保留下来。

虽然这个方法看起来很恐怖，但是却能增加收费的机会。使用这种方法，客户能够降低承包商带来的风险。这种重新平衡风险的方法收费也要更高。

这个方法使用起来，也许能让人们在智力层面（也许还有道德层面）站到比较高的位置，但是也引入了新的风险。因为客户的风险降低了，他们让项目成功的动力也就降低了。当决策难以制定时，就需要做出妥协；时间很宝贵，或是需要客户主动参与时，客户就没有多少动力去做必须要做的事情了。

客户没有切身利益牵涉其中，任何失败都将是承包方的失败，客户什么也不会失去。

如果供应商只选择与能够信守承诺的客户做生意，风险就可以缓解。前提是承包方能够拒绝他们认为有风险的工作，而且可以正确评估客户的承诺达成水平。

到今天为止，我只听说个人和小型承包商能够提供这种模式。有钱的公司要么很注意风险，要么觉得没有必要提供这种选择。

选择3：滚动合同（Rolling contracts）

如果我们希望保持客户的参与度，那么就需要一种机制，让他们参与进来，并不断让他们承诺相关的工作。滚动合同在此时就可以起到作用。客户与供应商之间不会去做“孤注一掷（all-or-nothing）”的工作，而是达成一个框架协议，完成一系列只需短期开发的小项目，根据个人喜好不同，可以把它们称作“情节（episode）”或迭代。

合同也许有某些整体目标，但是不包括所谓的“购物列表”，不需要列出特定的功能特性。发现需求是工作的一部分。我知道一个ESP 把所有需求文档都放在法律合同之外。每个迭代中都会交付一些东西，同样重要的是，对于需求的理解会不断增加。

伴随着每次交付，客户会付款给供应商，同时面临一个选择：继续下一个迭代，还是就此停止。重点在于供应商首先交付了有价值的工作，而且让人知道还有更多可以增加价值的工作可作。如果客户认为产生的价值还不如耗费的成本多，他们就可以在已完成工作的基础上就此停手。与之类似，如果供应商发现客户合作程度不苟，供应商也可以就此罢手。

某种程度上，这与传统的实践有类似之处，都是要在每个独特的阶段后停下来付款，双方重新承诺，这些阶段包括：需求收集、设计、开发、测试和部署。区别在于：传统模式中，在结束前离开，不会交付任何收益；在这种模式中，总是可以交付一些东西。

从供应商的角度来看：使用已完成功能的纵向切片来展示价值，这能起到明确的激励作用。这是一个常见的敏捷实践。

因为客户能够看到正在完成的工作、正在产生的价值和逐步显现出来的解决方案，他们应该对工作的继续推进充满热情；他们也知道：如果没能达成自己的承诺，他们可以选择离开；这也让他们有信心继续。

这种方式将法律框架从提供东西转移到了提供服务上。客户签订的是服务合同，而且可以思考他们购买的服务的数量。是4 个人月，还是200 个工作点数？

虽然这种方式听起来很激进，很多IT 部门和供应商已经在相关领域使用服务合同了。举个例子，IT 支持部门和软件维护合同一般都是采取服务合同的形式编写。

选择4：不劳而获，变更免费（Money for Nothing, Change for Free）

Scrum 的创始人 Jeff Sutherland 对“不劳而获，变更免费”有详细记述。这种合同没有采取迷你项目框架的形式，而是维护一个大合同，也就是说要完成一些概括的前期需求分析。但是，合同中加入了两个额外条款。

合同中第一个变化是：要确保总是在开发优先级最高的工作，而且允许加入新工作。客户同意定期与供应商碰面，调整剩余工作的优先级。这时，他们可以向 Backlog 中加入更多工作，同时要明白：这么做的话，有些工作就得丢掉，再也不会完成了。这有助于增加工作激励，对供应商有帮助，还能保证客户的参与。

与滚动合同类似，客户定期付款，可以按月支付，付款的增量对应交付出来的可工作的软件。这么做保证客户的参与，同时为将来的再次承诺奠定基础，并给后续的改变铺平道路。

“不劳而获”条款让客户在任何阶段都可以取消剩余的工作，并保留目前已经完成的工作。在这种情况下，客户要为未完成的工作支付 20% 款项。

假如有一个 1200 万美元、为期 12 个月的合同已经完成了一半，这时客户希望取消剩余的工作，除了必须要付的 600 万美元之外，他们还要多付出 120 万美元。这样相对于整个合同金额，客户还能省下 480 万美元。

初看上去，供应商可能不会喜欢这种方式，因为这样会让他们少收原来可能赚到的 480 万美元。然而，他们收到的 120 万美元却可算是无偿得到的，这应该足以缓解他们的顾虑。假定他们能够马上把人员分配到其他工作上，那么这 120 万美元就可以算是纯利润了。

因此，这种机制和激励措施能够让客户提高参与度，同时更早完成工作，节省资金。同样的是，供应商也有激励能够接受变化，把工作做好，得到免费的报酬。

目前，这种类型的合同在业界出现得还不多。

组合

基于上述四种选择，可以看到：以不同方式组合能够得到更多变更方案。比如：“变更免费”可以跟其他任何 3 种方式组合在一起，产生更有效的解决方案。类似，“不起作用不收钱”也可以应用到选择 3“滚动合同”的单次交付中。

从财务角度看，选择 3 和选择 4 大概没有很大区别。也许主要的区别在于：选择 3 打破了传统的模式，因为它假定人们在项目刚开始时知之甚少，而且让客户以积极方式反复交付。

与之相反，选择 4 契合现有模式，认可前期需求分析的必要性。“变更免费”条款提供的框架类似于滚动合同：初始需求作为估算工具，辅助判断所需时间和预算。一旦工作开始，前期需求就可以抛开了。“不劳而获”条款与滚动合同有共通之处：允许工作在任何时点停止，不过是以比较昂贵的方式。

无论敏捷团队采取哪种形式的合同，有两个必要因素需要考虑。首先，合同本身应该体现敏捷的迭代本质：完成一点，展示一点，再多完成一点。这在敏捷中反复出现：时间盒迭代、回顾、测试驱动开发，等等等等。这是现实版的 PDCA 循环。

其次，合同应该可以激励客户及其代表参与到项目的整个过程中。反复研究发现：客户的持续参与是确保 IT 项目成功的关键因素之一。不管你是否采用敏捷，你都需要客户持续参与。

最后，还有重要的一点……

没有接触过传统 IT 行业工作方式的客户可能觉得这些选择非常合理。过去曾与 IT 供应商一起工作的人员会觉得这些合同形式有些出人意料。我们的行业给客户造成伤害，就是因为我们总在宣扬：“只要你能写下来，我就能以预先确定的成本和时间完成。”

不可避免的是，有些客户会继续固守传统的合同模式。有些供应商会发现：可以在这样的客户身上赚到很多钱；而另外一些供应商则会发现这么做得不偿失。不管是哪种结果，人们都不会喜欢。

我有个客户，现在总是给他的客户两种选择：传统的“固定”合同，还有滚动式的敏捷合同。如果客户认为一切都可以在工作开始前固定下来，他们就可以使用传统方式。如果他们不确定，就可以试试看迭代式的、滚动敏捷合同。

随着时间推移，客户会更深入理解这些 IT 合同的新形式，还有可能采取的多种选择，大家都可以从中受益。现在，对于能够尽快在早期转向新合同模式的人，他们是有机会的。是，是有一些风险，但是同样也会有奖励。

关于作者

Alan Kelly 几乎从事过软件开发领域中的所有工作：系统管理员、测试人员、开发人员、架构师、产品经理和开发经理。他住在伦敦，擅长以培训、咨询和指导等形式，帮助软件公司采纳敏捷和精益实践，并加深对其理解。

除了给杂志撰写大量文章、做会议演讲之外，他还是《Changing Software Development: Learning to become Agile》一书的作者。

查看英文原文： Agile Contracts

给 InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家加入到 InfoQ 中文站用户讨论组中与我们的编辑和其他读者朋友交流。