敏捷合同入门（上）

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

作者：Tom Arbogast, Craig Larman, Bas Vodde

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

网址为www.agilecontracts.org.

注意：请到网站查看最新版本，分享URL（而不是文件）以保持最新版本

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
审校：申健Jacky(CST/CTC/CLP)

引言：历史会善待我的，因为我正在创造历史。—[英国]温斯顿·丘吉尔

很多公司已经成功地编写和使用“敏捷合同”或“演化式合同”多年。在Valtech（Craig工作的地方），他们将Scrum应用于他们在班加罗尔开发中心和其他地方承担的外包项目，并编写支持此项目的合同。而其他敏捷外包商，如ThoughtWorks，也做过同样的事情。

本介绍的内容面向两类受众：（合同）律师和非律师。我们鼓励与专业律师分享，因为一些材料是为他们编写的（注释1），因为创建支持敏捷价值观和实践的合同的大部分工作不是合同文本，而是教育法律专业人员去掌握这些价值观。这涉及理解和欣赏传统的法律问题，解决这些问题，并帮助律师掌握敏捷性和系统思考的含义。所以前面的建议集中在理解上。后面的主题关注在敏捷合同的具体建议。

注意：对于每个复杂的问题，总会有一个简单、整洁和错误的解决方案。—[美国]亨利•路易斯•门肯

不要认为合同谈判对于掌握敏捷原则含义的专业律师来说就不那么复杂或充满活力。重要的是要认识到合同是一个固有的复杂过程，在软件开发等高复杂性和不确定性的领域更是如此。律师，通过培训和履行职责，必须持续密切关注处理各方之间信任和合作所必需的框架。

注释1：本章总结了敏捷专家读者已经熟悉的核心敏捷概念，并且假设对该主题不熟悉的法律专业人员是重要的受众。

第一部分：合同考量​

尝试…与合同律师分享这些关键见解

 以下的观点是核心；他们需要和法律专家进行明确的探讨:

• 敏捷合同的结构和法律条文与大多数的传统开发类型合同相同。关键区别在于对操作过程和交付的了解方式以及如何在合同中捕获或与合同交互。
• 合同律师对于敏捷、精益原则和系统思考需要有一定了解。为什么？因为运用这些思考工具可以帮助减轻风险和风险暴露，这需要在合同中表述。敏捷方式可以实现快速交付可部署的可交付物和多方的协作决策，从而减轻了责任，担保和类似问题所带来的压力。
• 合同反应了人们的希望，尤其是恐惧。成功的项目最终不是来自于合同，而是通过协作、透明度和信任。“成功的”合同包含了支持协作、透明度和信任的机制。随着客户和供应商信任的建立，商业和合同模式应“松绑”以支持“客户合作高于合同谈判”这一条敏捷宣言。

超越基础的洞察力

每个人的首要任务就是要交付一个成功的项目（换而言之，实现商业机会），组织中的每一个成员，包括专业律师，都必须努力减少局部优化、孤岛心态和浪费2（注释2）。其它法务问题很重要，不过其从属于项目成功的目标。这是一个思维方式的转变，因为很多律师认为他们的独立职能是值得优先考虑的事情，也就是去提供一个“成功的”合同。

尝试…律师也去学习敏捷、迭代和系统思考等概念

为敏捷项目编写合同的律师（最常见的就是使用Scrum开展项目）需要在阐明敏捷合同之前掌握关键思想。我们建议专业律师研究这些科目的入门材料。例如：

• 《敏捷和迭代开发》（Agile & Iterative Development [Larman]），第二章，迭代和进化和第三章，敏捷
•  Scrum精要 (www.scrumprimer.com)
•  在精益精要中的持续改进部分 (www.leanprimer.com)
•  系统思考的文章；www.thinking.net上有很多文章和链接
• 《大规模精益和敏捷开发》（Scaling Lean & Agile Development）第二章，系统思考
• 以及本文

注释2：浪费: 1. 过度开发特性; 2. 等待和延迟; 3. 交接; 4. 重新学习; 5. 半成品的工作; 6. 任务切换; 7. 缺陷 (以及相关的测试，检查和更正); 8. 未充分使用的人员; 9. 知识分散和流失; 10. 一厢情愿.。

尝试…欣赏传统律师的视角

专业律师的知识体系是完全不同的。这种知识体系的的改写是从他们做为学生进入法学院开始的。对于律师的职业责任和辩护已经根植于律师的思维方式之中了。专业律师接受培训，在法律职责许可的前提下，以提高客户的利益及保护他们免受可见或不可见的陷阱行事。那你是如何定义客户利益的呢？客户很有可能简单的说项目的成功交付。专业律师则会说她的成功是基于如何能最大程度下保护她的客户免受风险暴露和风险，同时又能顺利推进合同/项目至最终目标。

人们仅仅看到，作为律师有责任去了解她的角色在法律中是如何定义的：

（5）（而做为）律师应该努力通过所有公平和光荣的方式，为客户获取任何可补偿和辩护的利益。但是律师必须牢记，这种信任是在法律允许的范围内的而不是在法律允许的范围之外的3（注释3）。

所以，律师认为他们的角色是保护客户免于被他们甚至自己都不知道的事情的影响。律师受过不信任的训练，不一定是对于其它人，而是对于（那些）不切实际的期望和结果（浪费的不切实际的想法），特别是在项目开始的时候。

在合同谈判中，认可这种动态是非常重要的。当律师声明他的部分责任是解决合同中的信任恶化问题时，这并不意味着律师不信任另一方。相反，这意味着他没有必要相信希望的结果，而是被授权去处理最为期待结果 — 无论好坏。

注释3：不列颠科伦比亚律师协会；职业行为准则

敏捷宣言中的第三点是客户合作高于合同谈判。自然而然的，当第一次读到这个，合同律师会关注、反应、也许会想，“这很好，不过我来这里的就是为了确保我的客户利益是被恰当保护的。他们可以想任何他们想要的东西。不过我打赌当他们在交付失败且对簿公堂的时候，就不会说什么客户合作高于合同谈判。” 这个是律师的责任在合同关系中考虑这种“不可想象的”情况并提供一个用合同语言表达的框架，以处理这类令人不愉快的结果。且律师具有丰富的经验来处理这类关系恶化和信任破裂的情况。

遵循先例（注释4）

律师是习惯性生物，这源自于法律的发展。

法律的生命不在于逻辑，而在于经验。—[法国]霍姆斯

人们常说法律落后于现实，而非超越它。这时因为法律发展的本质。案件提交法院审理并在现行法律原则背景下进行分析。这一想法适用于所有法律领域，包括公认的缔约原则。

一旦案件被包括法律学术届在内进行了审查和分析，它就会被接受做为常规实践。这个流程可能会需要十年甚至更长时间。

因此律师将目光投向过去的那些经过考验的，真实的先例，为的是扫除旧历并期望公认法律能以此做为引导。任何被认为是新的或具有海量变化的新事物（例如：敏捷方法）都会被视作可疑的或者不可信的。那么这种扫除也适用于合同模式—重用现有先例比创造新先例更容易。

传统项目假设：对于合同的影响

那么律师认为的传统的软件项目的性质是什么呢？首先，相较于那些通常那些高度不确定和可变的研究和开发而言，他们认为这与建筑项目类似，是相对可预测的。其次，在项目中（1）在它交付之前有一段较长时间的延迟 （2）反馈来得晚且弱，（3）长支付周期和(4) 项目可能在任意时间停止，如果这样，客户会遇到大问题。这些假设在敏捷开发中是无效的。

自然而然，这些假设会使用合同语言进行表达出来，同时律师会对涉及风险和责任的概念花时间予以关注，包括合同终止、赔偿、验收测试、支付条件和质保及其它方面的概念。

注释4：遵守先例原则，即一个法院先前的判决对以后法院在处理类似案件时具有约束力；这项原则主要适用于海洋法系国家。

尝试…纠正当律师接触到敏捷价值观第三条时的常见误解

如前所述，专业律师在第一次阅读到敏捷价值观“客户合作高于合同谈判”时作出的反应。对于非律师来说，了解可能的反应并通过交谈来纠正误解是十分有用的。律师可以通过学习以下内容来纠正这些误解：

错误二分法 — 第一个也可能是最常见的是使用错误二分法曲解敏捷价值观；即，“客户合作是好的而合同谈判是坏的”而不是引用敏捷宣言，…在右面的是有价值的，但是我们认为左面的有更高的价值。专业律师需要意识到这个价值并不代表说合同可以代替协作，而是说合作是项目成功交付的主因。

这种合作不仅应该体现在项目开发过程中双方的行为上，更应该被体现在合同语言中和律师的行为上。合同可以定义一个框架用于鼓励合作实践，这样专业律师可以支持其客户的敏捷性目标，更重要的是促进项目成功。

非法律性“合同”– 另一个常见的误解是第三条价值观仅适用于法律合同。不过“合同谈判”并不专指商业或者法律合同。它意味着在项目开发中各方所使用的协议或者规范的更宽泛的概念，重点是这些协议还在持续的促进协作、学习和演进。举例来说，传统方式中包括一个早期的具体需求规范，然后他们被“签署”，随后将这些需求规范传递给开发团队用以实现一个需求“合同”。

在项目执行期间，专业律师也许会通过法律的语言来加剧或者改善对于这些非法律性“合同”的病态关注。例如：如果他们起草了一份合同其中包含一个条款，要求在开始实施之前定义和签署所有或多数需求规范，那么项目就缺乏灵活性，且过分强调了（非法律性）“合同”谈判。

尝试…律师研究因孤岛心态而缺乏系统思考

图1.1（来自国际合同和商业管理协会，简称IACCM）描述了对于公司律师在2002-2007年期间关注的10大（前30中）合同条款问题。很难想象交付人员每天都在为大多数被列出来的问题所困惑。（注释5）令人惊讶的是，没有一个提及到合同目标（项目目标）。最重要的是关于合同如何结束，对于可交付物的期望（例如，加速处理账单的软件），并没有被列在10大问题之中。

考虑这种情况：一家大公司的律师被要求“衡量法律部门签订的合同的成功与否”。律师回答说：“过去一年，我们承担了超过60亿美元的债务，包括400多份不同的合同，我们只被起诉或不得不起诉其中两份合同。这与我们的年度业绩一致，相当于我估计的99％以上的成功率。“

在传统的律师的世界，这是他们对成功的定义，“最好”或者是“最佳的”情况。当然，这仅仅是局部最佳。律师无法解决在项目背后的成功案例是否得以实现，是否新的软件让消费者满意，是否项目被交付，亦或者在任何特殊的合同中是否支付太多。

律师是如何衡量合同谈判成功的？有一个传统的关于合同强硬说法，“你知道你们有一份另双方都不满意的好合同“，因为没有一方得到了他们想要的东西。敏捷思维对于双方都是反过来，那就是一个“双赢”的方方式实际上是相互优化的。

注释5：交付/验收在第9大问题中被提及。然而，这里涉及的是满足特定验收制度的交付概念，但与交付的基础对象无关。

无论一个人如何衡量一个合同的“好”，有件事情始终如一，这也是律师们在起草合同中最担心的事情：如果有任何问题，客户就会查看合同。因此律师需要确保该问题是符合客户期望的。这种担心以及客户的期望，导致律师严格的从客户角度出发对法律问题场景进行局部优化。

随之这个概念被归类为局部优化，或者在复杂系统中的参与者倾向于在他们自己的职责和角色范围内做“最好的”事情，而不去理解他们的选择和行动或者所带来的影响或者忽略更高层级的系统目标。

律师对成功的回答在局部是非常有说服力的，但并没有意识到更大系统的问题。为什么会这样？这是由于

• 交付团队和法务团队间存在着巨大的鸿沟
• 合同律师之间的孤岛心态
• 缺乏系统思维而导致局部优化
• 基于法律问题的激励和衡量措施

最后一点：激励和衡量不仅将功能障碍和局部优化行为注入到项目交付中，而且他们在合同起草中也是如此。如果法务部门的专业律师根据法律结果获得奖励，那么法律问题会更少——但是项目成功率却不会提高。

形式与功能

我们都住在那些从外部看起来既美丽又美观，但是内部却是功能失调和混乱的建筑物里面。这就是形式和功能的区别。所有的专业律师都会告诉你，当合同完成并尘埃落定，在签字盒里的墨水刚刚干透时，一堆一米厚的文件和附录显得如此熠熠生辉。

不过当然，合同的真正考验是在执行阶段，当人们实际在一起工作的时候。在这个阶段，任何需要被提及说是合同需求都可以说是失败的标志——不仅是合作，还有专业律师培养出来的合作和成功的框架的能力。

那就是说，如果真需要参考合同，那就让合同自适应，更像一幢建筑物[1] 。因此，想象合同在日常工作中如何被使用才是至关重要的。这种观点与系统思考方法密切相关。

所有这些引出这个问题：在合同各个方面谈判究竟花费了多少时间？对于在那些必须但次要的问题，专业律师是否在局部优化合同关注点和语言（反应了他们的孤岛心态），而实际结果却增加了项目风险？

许多律师在“拘于法规”方面花费了过多的时间和精力（例如：在不可抗力和责任方面花费了令人毛骨悚然的时间）。这些领域是值得考量的，然而从更大的角度来看，它对确保项目的成功究竟有多重要？

英国的公务员，帕金森（C. Northcote Parkinson），告诉了我们一个关于他的琐碎法则的有趣的故事，那就是在任意议程上花费的时间与项目的成本成反比。他分享了一个关于政府指导委员会的两个议题：1）发电厂的技术选择，2）会议的咖啡选择。被技术复杂性和科学所淹没的政府官员很快通过了咨询工程师的技术建议，但是每个人都对咖啡有意见，并想就此进行详细讨论。

在起草项目合同的律师也出现了类似动态：在谈判条款上所花费的时间与处理日常问题之间也存在着反比关系。

不过对于谈判问题上有一个好消息：敏捷和迭代方法可以通过设计来降低风险。所以，由于尽早和频繁交付系统的敏捷方法，对于“大问题”（例如责任）谈判的压力得以减轻。尽早反馈和每两周交付正常工作的系统，从根本上改变了一些背后的谈判条件，传统“瀑布”项目中令人痛苦的谈判是由于项目交付之前的对于项目延期的假设（和恐惧）所造成的。

从大型的“全有或者全无”的交付模式来看，人们可以理解极端压力如何影响到明确的条款。由于敏捷方法中可交付物的小型化和可迭代性使之能够在任意两周的边界上停止项目（因为每个系统切片增量都已经完成，并且是潜在可部署或者说是“可交付的”），因此可以减少例如：责任加倍和赔偿的压力。在《第五项修炼》中，彼得·圣吉（Peter Senge）阐述了，系统思维和学习型组织的最终目标是建立“某种组织，在那里人们不断扩展他们的能力，创造他们真正渴望的结果，在那里新的广阔的思维模式被建立，在那里集体渴望被释放，人们开始持续学习如何互相学习”。在这种情况下，尽管合同是必要的，但是对于专业律师来说扩展这种能力是主要的，而项目合同是次要的。所以关键是法务部门要承认他们由于缺乏系统思考、孤岛心态、对次要问题的局部优化等，导致了起草的合同会降低项目成功率和组织学习——这一点对于财务和人力及其它部门也是适用的。

尝试…让律师研究每两周的潜在可部署增量对假设和合同的影响

雷克萨斯LES和雷克萨斯IS

传统的非敏捷设想类似于购买高端雷克萨斯LS。最终的交付方案具有所有的优异性能，外观闪亮。那么与汽车的隐喻一致，律师可能设想一种制造方法首先制造底盘，然后放置引擎，然后是车身和电路，然后是内饰和油漆。那么，直到所有组件被组装之后，你是无法最终看到最终产品是如何组合在一起的。
这种保护风险暴露的合同机制设计，其压力是巨大的。对于客户来说，这意味着在最终交付之后必然有延迟的、复杂的最终用户接受制度。同样这也意味着，直到最终交付之前客户根本无法确认汽车的质量。在软件项目中，这意味着用户希望对项目的总体范围有最大程度的保护，通常的做法是项目总成本的责任加倍。这同样意味着供应商无法在项目结束前交出令人满意的最终交付物，也可能无法确认订单总价值。
敏捷项目同时解决了那两个问题。它的目标不是迭代地构建部分的项目组件，而是在两周的迭代中构建一个对客户有价值的、可部署的、可以被接受和使用的工作模型。对于敏捷概念不熟悉的专业律师并非总能抓住关键；他们会误以为敏捷开发增量交付不可部署组件，而不是在每个短迭代之后都可以交付可部署的、逐步增加功能的系统。

第一个迭代之后，可部署的解决方案或者模型可以被描述为Lexus IS——一种更简单的入门级车型。当每个迭代交付以后，工作模型级别会在功能和外形上上升。从某种意义上说，这更像每两周就以旧换新一次（注释6）。这种方式的含义对于类似责任和风险暴露等概念是非常重要的。用户（每两周都会）获得一些已付款的和可接受的有价值的东西。供应商可以确信他交付了可以确认收入和有价值的东西。即使出现了关系破裂而且项目陷入困境，相对于双方的风险暴露而言，最后的交付都是完整的（注释7）。客户不会被迫去支付那些比搁置软件好不了多少的“烂尾项目”，供应商也不可能因为付出没有回报的努力而被留下来。当然，双方的最终期望可能都没有得到满足，系统可能没有足够的功能去做有效地部署（注释8），不过从纯粹的业务和风险暴露的角度来看，各方相应的顾虑并不会像传统的“瀑布”项目一样减轻掉。对于律师来说，了解这一点对他们如何考虑，谈判和起草项目合同的影响至关重要！

尝试…律师们学习敏捷性是如何降低风险和暴露

以下三个方面是通常需要在合同起草的时候被考量的：（注释9）

• 风险和暴露（责任）
• 允许改变的灵活性

明确义务、可交付物和期望敏捷项目合同可以与传统项目合同一样阐明责任限制（和相关条款），但是敏捷合同将更好地支持避免律师担心的问题。也就是说，采用敏捷方法实际上会降低风险，提高客户的相对利益。不涉及敏捷方法的合同实际上可能会做与预期相反的事情，并增加风险并抑制客户的利益。

注释6：这种类比是不完美的：与汽车交易不同，软件和其合同可以在每个迭代周期变成更宏大的东西。

注释7：这种简化类比并没有解决预期成本、间接损害、利润损失和其他损害的问题。

注释8：这种简化类比并没有解决预期成本、间接损害、利润损失和其他损害的问题。

注释9：这里显然有许多不同方面的合同，不过他们可以被简单的分成这三类。

这方面的一个例子是需求收集和测试那些为满足需求而开发出来的软件。在瀑布开发项目中，律师将（通过合同语言）强制客户希望阐明每个可能的案例和随之而来的测试，以满足预期的要求。

敏捷方法考虑到需求将以迭代和渐进的方式阐述，以便在开发软件时不浪费时间和金钱来满足最终不需要的需求。它还认识到，可以更好地将资金用于开始时未被认可的要求。在顺序开发项目中确定和开发的需求可能永远不会被使用，因为它们设计错误或缺乏与真实用户的有效互动。在交付“符合合同”的系统后，仍然需要添加要求以满足真正的需求。从合同的角度来看，这意味着基于顺序方法的合同实际上会增加风险，即客户支付更多费用却比预期得到更少，但如果合同中能够理解并考虑敏捷方法时，就会发生相反的情况。

从法务和财务的角度来看，这一点怎么强调也不过分。在瀑布开发项目中，客户可能会支付远远超过预期成本，以获得她最初期望的东西。附加合同无法防止这种情况，实际上却会促进这种错误的假定，即认为有可能在没有持续反馈和渐进理解的情况下定义和交付大量需求。

推崇或强制瀑布生命周期开发的合同会增加项目风险

对于法律从业者来说，这意味着敏捷原则可以保护客户免受他们可能不知道的事情的影响。这与早先律师对当事人所认为的责任相吻合。因此，一旦律师知道敏捷原则，他就不会继续允许（通过继续写传统合同）客户支付他不需要的东西；转而允许客户额外支付去实现那些他真正所需要的东西。

这才是敏捷方法的含义：

• 降低风险，因为它限制了交付范围和支付范围
• 允许不可避免的变化
• 将谈判重点放在被忽视的交付领域

首先，作为业务一线的实际工作人员（对于新系统）和供应商开发团队必须紧密在整个项目的生命周期中参与和合作。鼓励法务人员在合同谈判和起草过程中寻找这种合作迹象并加以鼓励。

这种类型的持续合作并不意味着由于互动和联合开发的增加，促使律师会有大量的机会来收费（或者如果是内部的，那么现在就需要进行大量的工作）。相反，这意味着必须创建某种契约的结构，以允许客户进行持续的参与、评估和演进。如果创建了正确的模型，律师至少可以减少进一步参与，除非冲突发生，因为基于敏捷方法的正确框架将促进合作。

尝试…通过类比法律工作来提高律师对软件项目复杂度的敏感性

如果你是一名教练或者经理，有兴趣提高专业律师理解软件项目固有的复杂性、可变性、探索性的本质，尝试与他们分享下面的思想实验：

“我想为我的新项目签订一份完整的项目合同：一个新的企业级财务管理系统，可能涉及六个国家的大约200名开发人员，涉及四个以前从未使用过的外包服务提供商，需要两到四年才能完成。精确到小时，您需要多长时间与四家供应商谈判并签订合同？精确到字数，合同中会有多少字？具体成本是多少？”

讨论该场景与软件开发之间的相似性，哪些方法fan是现实的、有效的，哪些是不现实的、无效的，据此去处理那些不确定性、可探索性和多变性。

律师肯定会说，在这种情况下，由于合同起草和谈判的演进性质，在任何程度上都不可能确定最终合同是什么样的。律师可能会给出一个大概的数字，大概是多少时间，一般来说，要谈判一个完整的合同，比如说，200小时，但绝不会承诺任何具体的实际总小时数。然而，具有讽刺意味的是，律师和业务领导人（以瀑布式的思维）期望IT人员通过需求分析和表达在很大程度上来确定一个比“合同项目”要复杂得多、规模更大、可变性更大的软件项目是什么样的、要花多少钱。

避免…奖励和惩罚

对于参与合同的相关人员（法律专业人员，销售人员，采购代理人……）花费大量时间在合同中编造、谈判和编写激励和惩罚条款是很常见的。有一个“毫无疑问的”假设和信念，即激励（与绩效或目标日期相关）或奖金是有益的。然而，这与基于证据的管理研究不一致，并且有充分的证据表明激励导致博弈增加、透明度和质量下降以及其他功能障碍。这些研究在我们的《精益和敏捷开发大型应用指南》一书的组织章节中进行了总结。

惩罚（逆向激励）也带来了同样的问题（注释10）

激励和惩罚也促进了客户与供应商之间的对立竞争关系，而不是合作。

可选方案？

• 简单性——没有基于绩效的奖励或惩罚
• 如果客户对表现非常不满意，请在迭代结束时终止合约
• 共享的损益模型

尝试…共享损益

在未来的一些章节中，例如“尝试……目标成本合同”一节中，介绍了分担损失或收益的模型。这可以促进合作并共同改进。例如，在目标成本模型中，如果实际成本低于目标，则客户支付较少且供应商利润率较高。

避免…“质量管理计划”和“交付物清单”

传统的合同外包工作涉及低透明度和信任度，并且在某些软件完成之前会有很长的延迟。对此的一个（许多）经典合同回应是要求一个传统的“质量管理计划”或“交付物清单”，它定义了一份很长的文档检查清单，而不是专注于提供真正的价值：可工作软件。一位谈判代表与我们分享了以下故事：

注释10：我们并不是指重大过失的重大处罚，而是涉及与业绩变化相关的处罚。

参与合同谈判的敏捷主义者，需要对额外的文档持怀疑态度，且争论如何衡量生产它的成本——但他当然愿意讨论组织可能需要它们的原因。我的经验中最坏的情况是，我与一家公司进行了一次非常长的谈判，这家公司在喜欢敏捷的业务人员和传统的内部IT人员之间存在着巨大的内部鸿沟。带头与我们谈判的业务人员向内部IT团队“扔了一根骨头”，因为IT部门同意“质量管理计划”。IT代表试图通过“质量”计划的各种草案重新构建瀑布思维和文档，以及传统的命令和控制。幸运的是，我们终于成功地有效地消除了IT代表为自己建立的质量计划和专制的无价值产出的“质量经理”角色。

如果有的话，什么可以消除（假设的）对交付物清单的需求？在Scrum中，“完成的定义”是供应商团队与客户方业务领域的产品负责人共同定义的，且在每个迭代持续演进，而非IT经理或法律专业人员制定。合同律师需要理解“完成的定义”，因为它改变了敏捷合同的合同框架和项目的完成方式。简而言之，通过活动和工件，Scrum中定义了每个迭代中产品增量的“完成”标准，并且产品在每次迭代后都是潜在可用或可交付的。例如，对于特定迭代和特定产品的“完成”定义包括“编码、集成、功能/性能/可用性测试、文档”。（实际定义将更长、更详细、更明细）。需要重申的是，“完成”在每次迭代开始时由供应商和客户重新定义，且随着双方学习到真正有价值的东西时，它将而自适应地发展。

尝试…与律师更多地更早地合作

合作高于谈判，以及更多和更早的反馈循环不仅适用于外包的敏捷开发项目中的客户和供应商，还适用于与法律专业人员的接触。

图1.2中的系统动力学模型从广义上说明了增加对合同灵活性和协作支持的可能结果。但与本节特别相关的是，图1.2还说明了越来越多早期律师在商业风险和项目中的合作所产生的影响。这种更紧密的参与是《精益和敏捷开发大型应用指南：跨职能团队》一书的团队章节中探讨的更大主题的一部分。人们常常错误地认为跨职能团队的边界是研发或IT部门的人员。（其实并）不是这样。例如：

“最小” 跨职能意味着团队成员资格至少包括项目中涉及的所有关键功能，通常包括工程，市场营销和制造。[Smith07]

纳入法务来超越“最小跨职能团队”

以下是我（这里是汤姆）看到推迟律师参与和孤岛思维的影响很大的案例：商业领袖通过创建一个新的基于网络的计费系统来确定营销和节省成本的机会。商业案例依靠廉价开发——他们认为这可以通过离岸外包来实现。最终，在提案和招标过程之后，选出了最终人选，双方开始谈判。这通常是法律专业人员参与制定合同条款和条件的阶段。

在商业领袖不知情的情况下，许多司法管辖区最近收紧了跨越国界的个人数据出口规则。这一点只有在一些律师姗姗来迟的情况下才变得明显。由于这些规则，离岸外包是不可行的。商业案例论文和项目失效了。

幸运的是，错误是在为时已晚之前发现的。但考虑到律师的有限和孤立的参与——完全错过这个问题，导致（如图1.2所示）增加公司风险，这本来是很容易的。即使它在项目开始之前被捕获，最初的工作也消耗了大量的业务资源。除了浪费这项废弃的工作之外，随后对新业务案例的重新处理以及新的提案和招标周期减少了商务人员探索其他商业机会所需的时间和精力。

除了包括法律专业人员在内的跨职能团队的价值外，本案例还说明了IT人员不一定理解的一点：合同律师有责任考虑两种风险：

• 内部项目风险   * 随着敏捷开发的发展，这些都会减少，因此法律专业人员有责任在合同上支持这一点
• 连锁效应的风险 (例如数据出口违规)

           * 包括法律专业人员在内的跨职能团队以及早期、定期的合作减少了这些风险

继续阅读：

敏捷合同入门（上）

敏捷合同入门（中）

敏捷合同入门（下）

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