网址是
注：请前往网站查看最新版本
共享 URL（而非文件）以保持最新状态
作者简介：汤姆·阿博加斯特
Tom Arbogast 是一位律师，他将敏捷原则、系统思维和精益思维的知识与 IT 项目管理和敏捷合同方面的多年经验相结合。 他主要从事以下三个领域的工作：1）担任客户外包IT服务的合同顾问； (2) 作为 IT 外包商（“供应商”）的专家顾问； (3) 为供应商开展业务（利用销售协议影响合同内容）。 Tom 领导 ClearEdge Partners 的专业服务和法律实践团队，专门从事 IT、并购、谈判、交付管理和运营。 他曾担任英国电信 (BT) 副总裁，并在电信和技术领域担任行政和法律职务。 他曾在私人诊所工作，并在加拿大最高法院提起诉讼。 他毕业于科罗拉多大学和不列颠哥伦比亚大学法学院。
作者简介：克雷格·拉曼 | 巴斯沃德
Craig Larman 和 Bas Vodde 是 (1) 《扩展精益和敏捷开发实践：大型、多站点和离岸产品开发》和 (2) 《扩展精益和敏捷开发指南：大型、多站点和离岸》的作者产品开发”（《扩展精益和敏捷开发：大规模 Scrum 的思考和组织工具》的作者。
他们担任组织设计顾问，并在团队中担任管理和工程教练，在大型系统产品开发、离岸和多站点开发中采用精益思维和敏捷开发。
译者：何强、钱查理；
何强（CSP/CLB）是北京三星研究院的敏捷教练。 拥有近十年外企研发管理经验，是敏捷变革的爱好者和实践者。
Charlie Chan (CSM/CLB)，Scrum Master，目前就职于阿迪达斯数字中心，是一名敏捷实践者。
审稿人：Jacky Shenjian（CST/CTC/CLP），自2007年起在诺基亚西门子通信公司实践敏捷开发，经历过大规模Scrum（LeSS）。 目前是UPF敏捷学院合伙人。
以下为正文
第 2 部分：敏捷合约中的常见主题
为什么没有具体的合同语言示例？
在起草本简介时，我们首先考虑了 Valtech、ThoughtWorks 和其他方创建的敏捷项目合同中包含的示例条款。 除了 DSDM 和挪威 PS-2000 合同模板等变体之外，还有许多适用于企业的合同示例。
然而，审阅本入门草案的律师的反馈与我们的合著者汤姆的反馈相呼应：律师和销售人员确实存在风险，他们会简单地复制粘贴这些条款来起草新合同，而不是掌握这些条款。合同语言中反映的底层特定领域原则（例如敏捷或精益）。
参与这部分入职培训的专业律师有一个明确的信息：我们希望专注于帮助IT人员和律师理解敏捷和精益开发和合同的原则； 样本条款模糊了真正重要的内容，妨碍了合同律师应有的职责。 深刻的理解和系统的思考。
主题概述
敏捷项目合同中的主要主题（例如接受和终止）与传统项目合同中的相同。 然而，合同和专业律师背后的这些主题内容包含支持协作、学习和进化的元素（注11）。
敏捷性意味着“响应变化而不是遵循计划”和“客户协作而不是合同谈判”。 这对以下合同主题有何影响？
- 交付时间 - 项目范围
- 变更管理 - 终止
- 交付成果的验收
- 付款时间 - 价格
- 保修 - 责任限制
交货时间
对于刚刚接触敏捷开发的专业律师来说，了解新的交付周期势在必行。 从头开始，循环如下：
* 它可能没有足够的功能来部署，但每个周期都更接近于有价值交付的部署
增量交付在合约中并不是一个新概念； 许多人将中间状态里程碑确定为由日期或目标以及相关的验收标准或工作说明定义的。 敏捷开发中交付时间和里程碑的显着差异包括：
注11：
稍后将描述固定价格、固定范围合同的特殊情况。
项目范围
尽管项目范围的确定性和变化程度有低有高，但敏捷合同并未定义精确且不变的项目范围（注12）。 如下所示，这些变化通常与定价计划有关。
一方面是目标成本合同，其中总体项目范围和细节在一开始就尽可能完整地确定（以确定原始目标成本），但自始至终都有变更机制。 另一方面是渐进式合同，其中未定义多次迭代的（必要）范围。
总结合同中的愿景
确实有一些合同的例子，其中项目或产品的范围、愿景和业务驱动因素不清楚。 避免这种情况，因为这表明创建合同的人没有参与该项目。 相反，他们可能表现出一种墨守成规、局部优化的孤岛心态——这是我们之前讨论过的弱点。 此外，没有项目概述的合同不太容易理解。
因此，专业律师被邀请创造性地撰写自己对摩尔愿景声明的解释，而不是复制粘贴[Moore91]。 为了实现这一目标，他们需要参与项目愿景（例如，在研讨会期间）和其他项目活动。 还包括总合同、价格和付款条件的摘要。 将这两者放在合同的序言中。 例如：
对于会计部门和营销部门想要整合计费、降低计费成本、利用计费进行定向营销——我们的新产品KillBill是一个新的计费系统——它可以提供基于网络的账单显示、支付和定制营销。 与现有的计费系统不同 - 我们的新产品基于网络，可以降低 80% 的运营成本。
合同模型：这是目标成本模型。 基础是 $YYY 的预期交货价格。 供应商将根据产品交付和付款以两周迭代增量为基础。
注12：
具体的合同模型，包括目标成本合同，将在后面的章节中讨论。
更换管理层
由于重新确定了待办事项的优先级和调整了迭代计划，变更问题本质上是在敏捷方法的整体哲学中得到解决的； 不需要特殊的（传统）变更管理流程、变更管理委员会或请求机制。 因此，法律专业人士从合同中删除旧的变更管理语言至关重要，因为这种语言可能违反敏捷性的本质。
这并不意味着所有类型的变更管理都可以根据合同豁免。 敏捷项目合同中的一般概念分为两类：
与此同时，请查看下面的终止部分......
项目终止
终止的概念与变更控制相关，因为敏捷项目应该适应变更过程，并允许在任何迭代结束时停止进一步的工作。 与传统的项目思维不同，法律专业人士需要明白，提前终止应该被视为敏捷项目中积极的、理想的事件，因为提前终止并不意味着失败，而是意味着快速取得成功。 。
可以说，敏捷合同中的理想终止模型是允许客户在任何迭代结束时停止而不会受到惩罚。
当然，如果供应商预计在两年内为 100 人提供专门服务，如果合同意外提前终止，他们可能会遇到代价高昂的问题。 因此，敏捷终止条款的变化包括随着时间的推移（和迭代）减少对客户的处罚。
终止可能是任何合同中最难谈判的领域之一。 敏捷方法可以部分缓解这一问题，因为与传统合同相比，差异在于：（1）客户每次迭代都有一个工作系统； (2) 双方将对可交付成果的状况有清晰和了解的最新观点。 这些都是职业律师应该掌握的要点。
验收
“好了吗？” - “如果没完成怎么办？” - “我们现在决定改变主意并拒绝前三个迭代中完成的可交付成果。您介意吗？”
这些是外包项目工作中的重要问题，围绕这些问题的模糊性可能是冲突和诉讼的根源。 当事人和合同条款中有关完成、验收和整改的清晰程度（在可行的范围内）应该是法律专业人士关注的主要焦点。 通过仔细关注鼓励合作的合同接受框架，他们可以在消除这个雷区的热点方面大有帮助。
验收仍然存在，但由于迭代交付和迭代验收而大大简化，并且验收是增量的并且针对每次迭代自适应地达成一致。 此外，敏捷实践通常包括高度自动化的验收测试，因此验证需要很少或不需要手动（人力）工作。
验收建立在其自身之上，即最终验收是项目整个生命周期中多次验收的结果，理想情况下，大多数验收都通过自动验收测试反复验证。
那么，在合同方面，这意味着验收定义和谈判不必是大规模、全面的工作； 只有验收框架必须在合同中明确。
从广义上讲，对于每次迭代，验收都是基于对先前商定的验收测试集的一致性，在应用 Scrum 方法的情况下意味着满足“完成的定义”。
敏捷开发验收合同框架工作中另一个值得考虑的要素是在验收和验收测试的定义中包括新系统的目标用户。 专注于成功项目的专业律师应该问：“是否有合适的人员（例如实践用户）参与验收并在每次迭代中与供应商合作？”
样本条款
此摘要通常会避免引入示例条款，但在这种情况下，我们决定使用一个示例来帮助阐明上述建议：
a) 客户和供应商对交付成果的接受定义如下：
我。 可交付成果通过了最近迭代之前定义的所有新的自动和手动验收测试用例。
二. 可交付成果通过了之前所有的自动和手动验收测试，以确保不存在回归问题。
三. 可交付成果与迭代开始之前定义的已完成项目的定义一致。
b) 验收测试由客户和供应商成员（验收团队）共同定义，并在每次迭代中累积增加。 客户成员需要包括可交付成果的候选用户。 验收团队在每次迭代结束时（即 Sprint 评审会议期间）对验收结果进行评审。
c) 提供最终交付成果后，客户将在一次迭代（“评估期”、“半迭代”）中花费半个工作日的时间来验证交付成果或部分交付成果是否存在缺陷。
d) 如果客户在相关评估期到期之前以书面形式通知供应商，交付物或其一部分缺少任何材料成分（“不一致”），则供应商将在合理且切实可行的情况下尽快纠正这一情况。 类不合格项，但不超过迭代的长度，客户将在收到更正的可交付成果或其部分后花费额外的半迭代期（“验证期”）来验证特定的不合格项是否已得到纠正。
e) 客户应向供应商提供合理要求的协助，以验证是否存在并纠正发现的任何不一致之处。
责任限制
谈判责任条款可能是任何合同谈判中最困难的领域，敏捷流程并不能改变这一点。 然而，敏捷性可以提供帮助。 例如，它可以减少责任，因为每次迭代结束时都有可用的可交付成果。
例如，迭代后可交付成果中的缺陷可能对运营的影响较小，因为负面结果是较早发现的。 这并不意味着不存在任何不必通过责任范式解决的连锁反应，但其后果可能不那么严重。
考虑一下我（Tom）遇到的情况：在一个以传统顺序生命周期运行的新计费系统项目中，在“项目结束时交付大功能”后发现了错误，这些错误被复制并发送给在很多顾客的手中。 这个错误的后果和额外成本是相当大的：公司不得不削减新的账单、提供折扣、修复其在客户中的形象，并支付费用来纠正潜在的问题。 随后与外部供应商就谁应该承担损害赔偿责任产生了争论。
在敏捷方法中，可以发送相同的有问题的账单。 但也可以使用系统的早期版本将这些账单提前发送给较小的客户群，然后拥有足够的功能来现场测试这一关键功能。
这减少了成本、曝光度和商誉损失。 解决问题的成本也会更低，因为系统会更小，软件组件之间的耦合也会更少。
因此，敏捷开发有减少责任的潜力。
维护
谈判责任条款可能是任何合同谈判中最困难的领域，敏捷流程并不能改变这一点。 然而，敏捷性可以提供帮助。 例如，它可以减少责任，因为每次迭代结束时都有可用的可交付成果。
例如，迭代后可交付成果中的缺陷可能对运营的影响较小，因为负面结果是较早发现的。 这并不意味着不存在任何不必通过责任范式解决的连锁反应，但其后果可能不那么严重。
考虑一下我（Tom）遇到的情况：在一个以传统顺序生命周期运行的新计费系统项目中，在“项目结束时交付大功能”后发现了错误，这些错误被复制并发送给在很多顾客的手中。 这个错误的后果和额外成本是相当大的：公司不得不削减新的账单、提供折扣、修复其在客户中的形象软件定制开发类项目付款条款，并支付费用来纠正潜在的问题。 随后与外部供应商就谁应该承担损害赔偿责任产生了争论。
在敏捷方法中，可以发送相同的有问题的账单。 但也可以使用系统的早期版本将这些账单提前发送给较小的客户群，然后拥有足够的功能来现场测试这一关键功能。
这减少了成本、曝光度和商誉损失。 解决问题的成本也会更低，因为系统会更小，软件组件之间的耦合也会更少。
因此软件定制开发类项目付款条款，敏捷开发有减少责任的潜力。
可交付成果
传统的项目合同通常包括需要交付的内容（很多很多文档）以及如何完成这些工件的验收的详细说明性列表。 这些细节有时会反映在工作说明书或质量计划的附录中。 避免具体和僵化，并避免在合同中包含详细的可交付成果清单。 为什么？
- 它强化了一种（不真实的）信念，即完全定义的系统可以提前排序和交付，就好像它是在餐厅用餐而不是创造性的发现工作。
总而言之，我们见过供应商从未提供源代码的定制软件 - 只是因为有人忘记了。 因此，在某些情况下，客户最初并不了解什么是关键的。 但在这种情况下，更容易发现有价值的可交付成果，而不是通过合同可交付成果列表，而是通过频繁的增量交付和部署。
有时，帮助维护的技术文档（通常在传统项目合同中指定）可能很有价值，通常可以作为系统新手的学习帮助。 然而，最近部署的系统的维护通常外包给创建该系统的同一个人，因此对此类文档的需求较少。 因此，要求维护文档作为早期可交付成果可能会造成浪费。 如果在未来的某个时间客户已经证明需要文档（例如，如果客户接管维护），则可以由供应商创建文档，或者在系统交付后与客户在联合敏捷文档研讨会中创建文档。
付款时间
也许最流行的系统是在最终接受迭代的可交付成果后为每次迭代付费。 在简单的情况下，例如基本的累进合同，支付商定的迭代价格的 100%。 更复杂的付款计划通常与更复杂的整体项目定价计划相关。 例如，在各种“共享损/益”系统（如目标成本合同）中，除了迭代付款之外，还有项目结束时的最终延期付款。 或者，在每次迭代中，可能会有累积的 X% 保留，可以在各个中间里程碑处支付。
价钱
时间和材料
时间和材料变化 (T&M) 使敏捷项目定价模型更简单、更直接。 请注意，T&M 适用于固定范围合同和灵活范围合同。
在顺序开发项目中常见的 T&M 传统问题是，客户在看到有用的结果之前就陷入了看似无穷无尽的付款周期。 另一个经典问题是客户是否物有所值。 这些问题在敏捷方法中得到了改善，其中每次迭代都有一个系统来衡量可用软件功能的进度，具有高透明度，并且可以在任何迭代结束时终止。
T&M 需要双方之间的信任和透明度。 这需要真诚的努力和时间来发展。 在几个项目中，Valtech India 开始使用各种固定价格合同，在与客户建立信任后，已能够转向各种 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），则
观察：
每个项目的固定价格和目标成本定价
下一节将介绍这两种定价选项。 它们的影响超出了定价范围，并延伸到整个合同或项目模型。
待续
近期公开课程安排▼
