敏捷合同入门（中）

本文源自——《精益和敏捷开发大型应用实战：利用大规模Scrum进行大型、跨地区的离岸产品开发》

作者：Tom Arbogast, Craig Larman, Bas Vodde

请将您对未来版本的评论发送给我们

网址为www.agilecontracts.org.

注意：请到网站查看最新版本

分享URL（而不是文件）以保持最新版本

www.agilecontracts.org

Tom Arbogast是一名结合了敏捷原则、系统思维和精益思想知识的并且在IT项目管理和敏捷合同具有多年经验的律师。他主要从事了以下三方面的工作：1）为外包IT服务的客户担任合同律师；（2）作为IT外包商（“供应商”）的专业律师；和（3）为供应商开展业务（利用销售协议来影响合同内容）。Tom领导ClearEdge Partners公司的专业服务和法律业务团队，专门从事IT、并购、谈判、交付管理和运营。他曾担任英国电信的副总裁以及电信和技术领域的执行和法律职位。他曾在私人执业律师事务所工作过，并在加拿大最高法院提起诉讼。他毕业于科罗拉多大学和不列颠哥伦比亚大学法学院。

Craig Larman和Bas Vodde是（1） 《精益和敏捷开发大型应用实战》 （Practices for Scaling Lean & Agile Development: Large, Multisite, & Offshore Product Development）和（2）《精益和敏捷开发大型应用指南》（Scaling Lean & Agile Development: Thinking & Organizational Tools for Large-Scale Scrum）的作者。

他们作为组织设计顾问，以及作为大型系统产品开发，在离岸和多地开发中采用精益思想和敏捷开发的团队中的管理和工程教练。

译者：何强、Charlie Qian;何强（CSP/CLB)，北京三星研究院敏捷教练，近十年外企研发管理经验，敏捷变革的爱好者和践行者。

Charlie Qian(CSM/CLB)，Scrum Master，目前就职于阿迪达斯数字化中心，敏捷实践者。校审：申健Jacky(CST/CTC/CLP)，自2007年开始在诺基亚西门子通信实践敏捷开发，大规模Scrum(LeSS)亲历者，现任优普丰敏捷学院合伙人。

以下为正文

第二部分：敏捷合同中的常见话题

为什么没有具体的合同语言示例？

在起草本介绍时，我们首先考虑包括在Valtech，ThoughtWorks和其他各方创建的敏捷项目合同中的示例条款。除了诸如DSDM和挪威PS-2000合同模板之类的变体之外，还有许多企业的合同范例。

然而，审阅本入门草案的律师反馈和我们的合著者Tom的意见是一致的：在律师和销售人员中真实存在一个风险，即他们只是简单的拷贝-粘贴那些条款来起草新的合同，而并没有掌握基础领域特定原则（如敏捷或精益）在合同语言中体现。

参与此部分入门引导的专业律师有一个明确的信息：我们要专注于帮助IT人员和律师了解敏捷和精益开发与合同交叉的原则; 样本条款模糊了真正重要的内容，阻碍了合同律师应具备的深层次理解和系统思考。

话题概览

敏捷项目合同（如接受和终止）的主要议题与传统项目合同相同。然而，合同和专业律师背后的这些主题的内容包含支持合作、学习和进化的元素（注释11）。

敏捷性意味着“响应变化高于遵循计划”和“客户协作高于合同谈判”，这对以下合同主题有何影响？

                    – 交付周期                – 项目范围

                    – 变更管理                – 终止

                    – 验收                      – 交付物

                    – 付款时间               – 价格

                    – 担保                      – 责任限制

交付周期

对于敏捷开发新手的专业律师来说，了解新的交付周期势在必行。从头说起，这个循环简单来说如下：

• 在每两周（或延长到四周）的时间盒迭代结束时，交付具备价值的功能且可部署的系统。

           * 它可能没有足够的功能来部署，但每个周期都更接近有价值交付的部署

增量交付并不是合同中的新概念; 许多人确定中间状态里程碑是，要么按日期确定，要么按目标和相关的验收标准或工作说明确定。专业律师在敏捷开发中的交付周期和里程碑方面的值得注意的差异包括：

• 完成性和可部署性——每次迭代交付都按照完成标准做到完成，编码完成、测试完成等，并且在理论上是可部署的
• 持续时间——较短，通常为两周
• 时间盒——固定时间但范围可变

注释11：固定价格，固定范围合同的特殊情况将在稍后介绍。

项目范围

尽管项目范围确定性和变化程度存在从低到高的差异（注释12），但是敏捷合同并未定义精确且不变的项目范围。如下面看到的，这些变化通常与定价方案有关。

一方面是目标-成本合同，其中整体项目范围和细节在开始时尽可能完整地确定（以确定原始目标成本），但其中有变更机制贯穿始终。另一方面是渐进式合同，其中并没有定义多于一次迭代的（必要的）范围。

在合同中总结愿景

现实中的确存在项目或者产品的范围、愿景、商业驱动力都很不明确的合同样例。请避免这种情况，因为这表明合同制定者并不参与项目。相反，他们可能正在展示墨守成规、本地优化的孤岛心态——这就是我们前面讨论过的弱点。此外，没有项目概述的合同也不太容易理解。

因此，邀请专业律师创造性地写出他们自己的理解 – 而不是复制-粘贴——那种摩尔式的愿景声明[Moore91]。为实现这一目标，他们需要参与项目愿景（例如，在研讨会期间）和其他项目活动。此外，还包括总合同、价格和付款方式的摘要。将这两者放在合同序言中。例如：

对于想要合并账单，降低账单成本，并使用账单进行目标营销的——会计部门和营销部门 ——我们的新产品KillBill是一种新的账单系统——它能够提供基于网页的账单展示，支付以及定制化营销。与现有的计费系统不同——我们的新产品基于网页，并且能够使运营成本降低80％。

合同模型：这是一个目标成本模型。基础是$YYY的预期交货价格。供应商将以两周的迭代递增为基础进行产品交付和支付。

注释12：具体的合同模型，包括目标成本合同，将在后面的章节中讨论。

变更管理

由于重排优先级的待办清单和调整迭代计划，变更问题在敏捷方法的整体哲学中基本上得到了内在解决; 不需要特殊（传统）变更管理流程，变更管理委员会或请求机制。因此，法律专业人员从合同中删除旧的变更管理语言至关重要，因为这种语言可能违反了敏捷性的本质。

这并不意味着所有类型的变更管理都以合同形式免除。敏捷项目合同中的一般概念分为两类：

• 改变各方之间的关系
• 例如，当一方被另一实体收购时，公司可能发生根本性的方向上的变化。所以，合同中常用的现有变更管理条款可能仍然适用。但是，请记住，由于敏捷方法中固有的迭代式可交付成果和并发支付的性质，相对期望的压力以及重大变更产生的影响将减少。
• 项目范围变更

• 这是合同中需要最谨慎的领域，以防止颠覆敏捷开发的重点：客户和供应商之间的协作中随意和频繁地进行变更。避免授权给变更管理委员会，变更请求或特殊变更流程。
• 但是，与项目范围一样，变更管理的灵活性也存在一些变体，包括从高灵活性且免于惩罚的弹性范围渐进式合同，到使用目标成本模型时的中等灵活性的损益共享。

同时，看下面终止这一部分…

项目终止

终止的概念与变更控制是有关联的，因为敏捷项目应该适应于改变过程，并且允许在任意一个迭代结束时都可以停止进一步的工作。与传统的项目思维不同的是，法律专业人员需要理解，提前终止应该被视为敏捷项目中的一个积极的、理想的事件，因为提前终止并不意味着失败——它可能意味着快速实现成功。

可以说，敏捷合同中理想的终止模型是允许客户在任何迭代结束时停止，而且没有惩罚。

自然而然的，如果供应商在预期的两年内提供100人的专项服务，若合同意外地提前终止，他们可能会遇到一个高额成本的问题。因此，敏捷终止条款的变化包括随着时间的推移（和迭代）减少对客户的惩罚。

合同终止可能是任何合同中最难谈判的领域之一。敏捷方法的对此部分有所缓解，是因为与传统合同相比，差异在于：（1）客户每次迭代都有一个可工作的系统;（2）双方都将对交付物的状态有清晰和最新的观点。这些是专业律师应该掌握的关键点。

验收

“它完成了吗？”——“如果没有完成该怎么办？”——“我们现在决定改变主意，拒绝前三次迭代完成的交付。你介意吗？”

这些是外包项目工作中的重要问题，围绕这些问题的模糊性可能是冲突和诉讼的根源。在双方意识中和合同条款中的关于完成、验收和纠正的明晰程度（在实际可行的范围内）应该是法律专业人员的主要关注点。他们可以大大有助于化解这个雷区中的“燃爆点”，并仔细关注鼓励合作的合同接受框架。

验收仍然存在，但由于迭代交付和迭代验收，而且验收是增量的且对于每次迭代能够自适应地达成一致，因此大大简化。此外，敏捷实践通常包括高度自动化的验收测试，因此验证需要很少或不需要手动（人工）工作。

验收是建立在自身基础之上，即最终验收是项目整个生命周期中发生的许多验收的最终结果，理想情况下，大多数验收都是通过自动验收测试不断重复验证的。

那么在合同方面，这意味着验收定义和谈判不一定是一项大规模的综合性工作; 只有接受框架必须在合同中明确。

从广义上讲，对于每次迭代，接受是基于对先前商定的验收测试集的一致性，如果是应用Scrum方法，就意味着要符合“完成的定义”。

敏捷开发验收在合同框架工作中值得考虑的另一个要素，是在验收和验收测试的定义中包括新系统的目标用户。关注一个成功项目的专业律师应该问：“合适的人员，例如实际操作的用户，是否参与了验收，并且每次迭代都与供应商合作？”

样本条款

本概要通常避免介绍样本条款，但是对这种情况下的我们决定用一个例子来帮助澄清上述建议：

a）客户和供应商定义对可交付物的验收如下：

      i.  交付物通过了在最近一次迭代之前定义的所有新的自动和手动验收测试用例。

      ii. 交付物通过了所有之前的自动和手动验收测试，确保没有回归问题。

      iii. 交付物与在迭代开始之前定义的“完成的定义”中条目保持一致。

b)  验收测试是由客户与供应商成员（验收小组）共同定义，并且在每个迭代中累积增加。客户成员需要包括交付物的候选用户。验收小组在每个迭代末尾审阅验收成果，亦即Sprint评审会的时候。

c)  客户在提供最终交付物后，将在一次迭代（“评估期”，“半迭代”）中，花费半个工作日内来验证交付物或者交付物中的一部分是否存在不足。

d)  如果客户在相关评估期到期之前以书面形式通知供应商，告知其可交付物或其中一部分缺乏任何重要部分（“不一致”），供应商将在合理并且实际可行的情况下尽快纠正此类不合规情况，但不得超过一次迭代的长度，客户将在收到更正的交付物或其中一部分后再花费额外的半迭代期（“验证期”），以验证特定的不合格情况是否已得到纠正。

e)  客户应向供应商提供合理要求的协助，以核实是否存在并纠正发现的不一致情况。

责任限定

责任条款的谈判可能是任何合同谈判中最困难的领域，敏捷过程同样不会改变这一点。但是，敏捷可能有所帮助。例如，它可以减轻责任，因为在每次迭代结束时都有可用的可交付成果。

例如，迭代结束后交付物中的缺陷可能对运营的影响较小，因为负面结果被较早发现。这并不意味着不存在任何连锁效应而不必通过责任范式来解决，但它带来的后果可能会更少。

考虑一下我（Tom）遇到的情况：在一个传统顺序型生命周期运作的全新的计费系统的项目中，在“项目完结时的大功能交付”之后发现了错误，这些错误被复制发送到了很多客户手中。这个错误造成后果和额外成本相当可观：公司不得不削减新账单，提供折扣，并修复其与客户的形象，加上支付以纠正潜在的问题。随后与外部供应商争论谁应该支付损害赔偿责任。

在敏捷方法中，可以发送相同的有问题的账单。但也有可能使用早期版本的系统，将这些账单提前发送给更小的客户群，然后得到充足功能来对这一关键功能进行现场测试。

这样可以降低成本，暴露和商誉损失。修复这个问题也会更便宜，因为系统会更小，而且软件组件之间的耦合更少。

因此，敏捷开发有可能减少责任。

维保

与责任类似，关于维保的担忧也是逐步累进式的减弱。由于累进式验收带来的交付本身的信心，与最终维保相关的风险因素会相当量的减少。在引入自动化验收测试之后，风险更被额外的降低。

尽管最终产品仍有全面维保，但是与责任一样，维保应与每个增量工作可交付成果相关联（在每次迭代结束时）。

交付物

传统的项目合同经常包含一份详细的、规定性的清单来列出哪些需要交付（很多很多文档），以及如何完成这些工件的验收。这些细节有时候体现在工作说明书中，或者“质量计划”的附录中。请避免这种特定的而且生硬的规定，而且避免在合同中包含详细的交付物列表。为什么？

• 它导致浪费活动的增加，而不是专注于工作软件，并且其中有一种可能是错误的假设——我们知道哪些工件是有价值的。      -关注在谈判和遵守“质量计划”，而不是合作创建有用的软件。

• 它强化了（幻觉的）命令与控制、预测性规划思维，而不是学习和应对变化。

               -它强化了（不真实的）信念，即完全定义的系统可以被提前排序和交付，就好像它是在餐馆用餐而不是创造性的发现工作。

总而言之，我们曾经看到供应商从未提供源代码的定制软件——仅仅是因为某人忘了。因此，在某些情况下，客户最初并不了解什么是关键的。但在这种情况下，不是通过合同可交付成果列表，而是通过频繁的增量交付和部署，可以更容易地发现有价值的可交付成果。

有时，通常在传统的项目合同中规定的帮助维护的技术文档很有价值，通常作为系统新手的学习辅助工具。不过，近期部署的系统的维护经常外包给创建系统的同一批人，因此对这种文档的需求较少。因此，要求将维护文档作为早期可交付成果可能是浪费。如果在将来的某个时间，客户已经证明需要文档（例如，如果客户接管维护工作），则可以由供应商创建，也可以在系统交付后与客户一起参与的联合敏捷文档工作坊中创建。

付款时机

最流行的系统也许是在最终验收该迭代的可交付成果后为每次迭代支付。在简单的情况下，例如基本的累进合同，100％支付商定的迭代价格。更复杂的支付方案通常与更复杂的整体项目定价方案相关联。例如，在各种“共享损失/收益”系统（如目标成本合同）中，除迭代付款外，项目结束时还会有最终的延期付款。或者，在每次迭代时，可能存在累积的X％保留并且可以在各种中间里程碑处支付。

定价

时间和材料

时间和材料的变化（T＆M）使得敏捷项目定价模型更加简单与直接。请注意，T＆M适用于固定范围和弹性范围的合同。

T＆M的一个在顺序开发项目中很常见的传统问题，是客户在看到有用的结果之前就陷入了看似无休止的付款周期。另一个经典问题是客户是否为他们付的钱得到了很高的价值。这些顾虑在敏捷方法中得到了改善，每个迭代都有一个可用的系统——根据可用的软件功能度量进度、高透明度、在任何迭代结束时都可以终止。

T＆M需要双方之间的信任和透明度。这需要真诚的努力和时间来发展。在几个项目中，Valtech India一开始使用各种固定价格合同，在建立信任之后，已经能够与客户一起转向各种T＆M模型。

T＆M的几种变化减少了客户的风险暴露，并且平衡了损失/收益。例如：

• 每次迭代的T＆M上限（“不超过”）
• 每个项目或法币的T＆M上限
• 每次迭代带调整的T＆M上限。对于下一次迭代，价格是有封顶的，但如果所有原始迭代目标都已交付并被接受，则在T＆M成本低于上限时，则会向供应商支付调整过的款项，例如节省下来的一半。在项目级目标成本模型中使用类似的共享损失/收益定价方案。

每个迭代固定价格（每单元时间）

该模型具有简单性和可预测性的优点，在敏捷外包中并不少见。有两个关键场景：

• 在迭代开始之前，需求就确定并且双方达成一致
• 高度灵活性或者无法预先定义的需求

在第一个场景中，这类问题和固定总价的大型项目是一样的。供应商必须澄清工作并对估算有足够的信心，以免损失金钱。迭代的有限范围使得这比大型项目更有实现的可能。客户的关键问题（或成本）是需要为供应商的费率增加项目应急费用，因为研发工作的可变性存在风险。

在第二种场景下，核心问题是客户对供应商的信任。透明、频繁交付和容易终止，这些都有帮助。

每单位工作的固定价格

一些敏捷外包商提供每单位工作量（UoW）固定价格的模型。与传统开发相比，UoW可能意味着是一份文档或其他不完整的解决方案，不过敏捷的UoW反映了第七个敏捷原则：可工作软件是项目进展的主要衡量标准。也就是说，UoW与在运行的、经过测试的软件功能有关。

这些模型通过各种名称和各种系统来估算UoW：“每个故事点的价格”，“每个功能点的价格”，“每个特征点的价格”等等。

大小的点数对比价值的点数——在我们看到的方案中，“点数”经常和一个估计的大小或者工作量有关，自然而然的它也和花费有关。尽管供应商可能会使用现代敏捷的术语声称价格模型与价值相关，例如“每故事点价格”，但是说“故事点”或“特征点”是一种价值衡量标准并不准确，就像俗话说“价廉物美”，一个故事点反映在价廉，而不是物美。然而，理论上存在根据业务价值影响定义点数的能力——这是使用诸如Tom Gilb的影响预估表之类的系统来衡量的（并且他已经提出了这样的价值影响价格模型[Gilb05]）——但我们不知道这种方法的任何应用。

我们已经看到敏捷外包商使用两种方案之一来确定每点的固定价格：

（1）基于先前几个项目的平均值，以及（2）定制数量。在后一种情况下，客户支付供应商平均点数几次（或支付T＆M，或者其他），在此期间跟踪详细成本。然后供应商和客户同意每点的自定义固定价格，基于此成本再加上一些利润率。

这种模式与交付和价值导向的敏捷和精益主题是一致的：假设敏捷的UoW与客户的价值松散相关（并非总是如此），它们的收益与收到的价值成比例。然而，由于在方案中我们已经看到，一个故事点与规模或工作量相关而非客户的真实价值影响，从这一点看来，故事点实质上是一种损失。

对于这种模型的一个需要在合同中考虑的关键点是，需要一个清晰而且通用的（对于客户和供应商双方）框架来定义一个故事点。例如，只有功能故事点是可以相对清晰地定义出来，并且可以通过认证的功能点分析来进行识别与验证。与此相对的是，独立的故事点（也就是常说的相对工作量点数）是没有含义的。

按用量付费模型

XPLabs（意大利的一家敏捷开发公司）推广与用户的使用量为基础的合同付费。XPLabs会自动跟踪为客户端部署的定制或预构建系统的每次“使用”（通常是一个事务）。根据使用频率来定期给客户发送账单，这也是一种简单的付款模式。该方法倾向于调整客户和供应商的利益，如果系统越来越多地使用，双方都会获胜。

如果它是预先构建的解决方案，该模型对客户尤其具有吸引力：它们没有维护或更新成本，只需为自定义增强功能支付额外费用。每个新客户部署都基于相同的简单合同模型。

如果它是仅针对一个客户的定制解决方案，则开发工作的合同模型可以是讨论过的任何其他方法，例如T＆M，可能以低于平均水平的费率，以备未来调整为预期的按用量付费收入模式。

混合的损失/收益共享模型

在现实中有许多众所周知的混合定价方案，所以此处不再重复（参见推荐读物）。Bob Martin [Martin04]提出了一种适用于敏捷开发的混合的损失/增益共享模型：

每单位工作量的折扣固定价格，加上折扣后的T＆M——例如，假设以下项目方案：

在这个模型中，它提供了带有补充每工作单元费率的一个较低的人天费率。例如，假设一个标准人天费率为500美元。供应商提供了一个150美元的折后人天费用，以及122.50美元（注释13）的折后的每故事点费用，那么

观察：

• 如果实际工作量与原始估计数（35,000人天，100,000个故事点）相等，则客户付款等于简单的T＆M计划，即每人每天500美元。
• 如果实际工作量不同，客户付款发生轻微变化。
• 与目标成本和一些其他调整方案一样，如果项目比原始估计花费更多或更少的工作量，则客户和供应商分担损失或收益。

每个项目的固定价格和目标成本定价

这两种定价方案都将在下一节中介绍。它们的影响超出了定价范围，并且扩展到了整体合同或项目模型。

继续阅读：

敏捷合同入门（上）

敏捷合同入门（中）

敏捷合同入门（下）

敏捷风水——外包合同暴露了甲乙方八字不合–签署敏捷合同