今天小编给各位分享的是编写合同，敏捷合同入门（上）的知识，，希望对您有所帮助。如果你还想了解更多这方面的信息，请点击本站其他相关内容，共同学习吧！如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！
本文导读目录：
编写合同，敏捷合同入门（上） ♂
敏捷合同入门（上）
本文源自书籍——《精益和敏捷开发大型应用实战：利用大规模进行大型、跨地区的离岸产品开发》
作者： , ,
请将您对未来版本的评论发送给我们
网址为
注意：请到网站查看最新版本，分享（而不是文件）以保持最新版本
第一部分（上）：对合同的思考
第二部分（中）：敏捷合同的常见话题
第三部分（下）：敏捷合同的模式
作者简介：
是一名结合了敏捷原则、系统思维和精益思想知识的并且在项目管理和敏捷合同具有多年经验的律师。他主要从事了以下三方面的工作：）为外包服务的客户担任合同律师；（）作为外包商（“供应商”）的专业律师；和（）为供应商开展业务（利用销售协议来影响合同内容）。领导 公司的专业服务和法律业务团队，专门从事、并购、谈判、交付管理和运营。 他曾担任英国电信的副总裁以及电信和技术领域的执行和法律职位。他曾在私人执业律师事务所工作过，并在加拿大最高法院提起诉讼。 他毕业于科罗拉多大学和不列颠哥伦比亚大学法学院。
作者简介： &
和 是（） 《精益和敏捷开发大型应用实战》（ & : , , & ）和（）《精益和敏捷开发大型应用指南》（ & : & - ）的作者。他们作为组织设计顾问，以及作为大型系统产品开发，在离岸和多地开发中采用精益思想和敏捷开发的团队中的管理和工程教练。
译者：何强、
审校：申健(//)
以下为正文
引言：历史会善待我的，因为我正在创造历史。
—[英国]温斯顿·丘吉尔
很多公司已经成功地编写和使用“敏捷合同”或“演化式合同”多年。在（工作的地方），他们将应用于他们在班加罗尔开发中心和其他地方承担的外包项目，并编写支持此项目的合同。而其他敏捷外包商，如，也做过同样的事情。
本介绍的内容面向两类受众：（合同）律师和非律师。我们鼓励与专业律师分享，因为一些材料是为他们编写的（注释），因为创建支持敏捷价值观和实践的合同的大部分工作不是合同文本，而是教育法律专业人员去掌握这些价值观。这涉及理解和欣赏传统的法律问题，解决这些问题，并帮助律师掌握敏捷性和系统思考的含义。所以前面的建议集中在理解上。后面的主题关注在敏捷合同的具体建议。
注意：对于每个复杂的问题，总会有一个简单、整洁和错误的解决方案。
—[美国]亨利?路易斯?门肯
不要认为合同谈判对于掌握敏捷原则含义的专业律师来说就不那么复杂或充满活力。重要的是要认识到合同是一个固有的复杂过程，在软件开发等高复杂性和不确定性的领域更是如此。律师，通过培训和履行职责，必须持续密切关注处理各方之间信任和合作所必需的框架。
注释：本章总结了敏捷专家读者已经熟悉的核心敏捷概念，并且假设对该主题不熟悉的法律专业人员是重要的受众。
第一部分：合同考量
尝试…与合同律师分享这些关键见解
以下的观点是核心；他们需要和法律专家进行明确的探讨:
敏捷合同的结构和法律条文与大多数的传统开发类型合同相同。关键区别在于对操作过程和交付的了解方式以及如何在合同中捕获或与合同交互。合同律师对于敏捷、精益原则和系统思考需要有一定了解。为什么？因为运用这些思考工具可以帮助减轻风险和风险暴露，这需要在合同中表述。敏捷方式可以实现快速交付可部署的可交付物和多方的协作决策，从而减轻了责任，担保和类似问题所带来的压力。合同反应了人们的希望，尤其是恐惧。成功的项目最终不是来自于合同，而是通过协作、透明度和信任。“成功的”合同包含了支持协作、透明度和信任的机制。随着客户和供应商信任的建立，商业和合同模式应“松绑”以支持“客户合作高于合同谈判”这一条敏捷宣言。超越基础的洞察力
每个人的首要任务就是要交付一个成功的项目（换而言之，实现商业机会），组织中的每一个成员，包括专业律师，都必须努力减少局部优化、孤岛心态和浪费（注释）。其它法务问题很重要，不过其从属于项目成功的目标。这是一个思维方式的转变，因为很多律师认为他们的独立职能是值得优先考虑的事情，也就是去提供一个“成功的”合同。
尝试…律师也去学习敏捷、迭代和系统思考等概念
为敏捷项目编写合同的律师（最常见的就是使用开展项目）需要在阐明敏捷合同之前掌握关键思想。我们建议专业律师研究这些科目的入门材料。例如：
《敏捷和迭代开发》（ & []），第二章，迭代和进化和第三章，敏捷精要 ()在精益精要中的持续改进部分 ()系统思考的文章；上有很多文章和链接《大规模精益和敏捷开发》（ & ）第二章，系统思考以及本文注释：浪费: . 过度开发特性; . 等待和延迟; . 交接; . 重新学习; . 半成品的工作; . 任务切换; . 缺陷 (以及相关的测试，检查和更正); . 未充分使用的人员; . 知识分散和流失; . 一厢情愿.。
尝试…欣赏传统律师的视角
专业律师的知识体系是完全不同的。这种知识体系的的改写是从他们做为学生进入法学院开始的。对于律师的职业责任和辩护已经根植于律师的思维方式之中了。专业律师接受培训，在法律职责许可的前提下，以提高客户的利益及保护他们免受可见或不可见的陷阱行事。那你是如何定义客户利益的呢？客户很有可能简单的说项目的成功交付。专业律师则会说她的成功是基于如何能最大程度下保护她的客户免受风险暴露和风险，同时又能顺利推进合同/项目至最终目标。
人们仅仅看到，作为律师有责任去了解她的角色在法律中是如何定义的：
（）（而做为）律师应该努力通过所有公平和光荣的方式，为客户获取任何可补偿和辩护的利益。但是律师必须牢记，这种信任是在法律允许的范围内的而不是在法律允许的范围之外的（注释）。
所以，律师认为他们的角色是保护客户免于被他们甚至自己都不知道的事情的影响。律师受过不信任的训练，不一定是对于其它人，而是对于（那些）不切实际的期望和结果（浪费的不切实际的想法），特别是在项目开始的时候。
在合同谈判中，认可这种动态是非常重要的。当律师声明他的部分责任是解决合同中的信任恶化问题时，这并不意味着律师不信任另一方。相反，这意味着他没有必要相信希望的结果，而是被授权去处理最为期待结果 — 无论好坏。
注释：不列颠科伦比亚律师协会；职业行为准则
敏捷宣言中的第三点是客户合作高于合同谈判。自然而然的，当第一次读到这个，合同律师会关注、反应、也许会想，“这很好，不过我来这里的就是为了确保我的客户利益是被恰当保护的。他们可以想任何他们想要的东西。不过我打赌当他们在交付失败且对簿公堂的时候，就不会说什么客户合作高于合同谈判。” 这个是律师的责任在合同关系中考虑这种“不可想象的”情况并提供一个用合同语言表达的框架，以处理这类令人不愉快的结果。且律师具有丰富的经验来处理这类关系恶化和信任破裂的情况。
遵循先例
律师是习惯性生物，这源自于法律的发展。
法律的生命不在于逻辑，而在于经验。—[法国]霍姆斯
人们常说法律落后于现实，而非超越它。这时因为法律发展的本质。案件提交法院审理并在现行法律原则背景下进行分析。这一想法适用于所有法律领域，包括公认的缔约原则。
一旦案件被包括法律学术届在内进行了审查和分析，它就会被接受做为常规实践。这个流程可能会需要十年甚至更长时间。
因此律师将目光投向过去的那些经过考验的，真实的先例，为的是扫除旧历并期望公认法律能以此做为引导。任何被认为是新的或具有海量变化的新事物（例如：敏捷方法）都会被视作可疑的或者不可信的。那么这种扫除也适用于合同模式—重用现有先例比创造新先例更容易。
传统项目假设：对于合同的影响
那么律师认为的传统的软件项目的性质是什么呢？首先，相较于那些通常那些高度不确定和可变的研究和开发而言，他们认为这与建筑项目类似，是相对可预测的。其次，在项目中（）在它交付之前有一段较长时间的延迟 （）反馈来得晚且弱，（）长支付周期和() 项目可能在任意时间停止，如果这样，客户会遇到大问题。这些假设在敏捷开发中是无效的。
自然而然，这些假设会使用合同语言进行表达出来，同时律师会对涉及风险和责任的概念花时间予以关注，包括合同终止、赔偿、验收测试、支付条件和质保及其它方面的概念。
注释：遵守先例原则，即一个法院先前的判决对以后法院在处理类似案件时具有约束力；这项原则主要适用于海洋法系国家。
尝试…纠正当律师接触到敏捷价值观第三条时的常见误解
如前所述，专业律师在第一次阅读到敏捷价值观“客户合作高于合同谈判”时作出的反应。对于非律师来说，了解可能的反应并通过交谈来纠正误解是十分有用的。律师可以通过学习以下内容来纠正这些误解：
错误二分法 — 第一个也可能是最常见的是使用错误二分法曲解敏捷价值观；即，“客户合作是好的而合同谈判是坏的”而不是引用敏捷宣言，…在右面的是有价值的，但是我们认为左面的有更高的价值。专业律师需要意识到这个价值并不代表说合同可以代替协作，而是说合作是项目成功交付的主因。
这种合作不仅应该体现在项目开发过程中双方的行为上，更应该被体现在合同语言中和律师的行为上。合同可以定义一个框架用于鼓励合作实践，这样专业律师可以支持其客户的敏捷性目标，更重要的是促进项目成功。
非法律性“合同”– 另一个常见的误解是第三条价值观仅适用于法律合同。不过“合同谈判”并不专指商业或者法律合同。它意味着在项目开发中各方所使用的协议或者规范的更宽泛的概念，重点是这些协议还在持续的促进协作、学习和演进。举例来说，传统方式中包括一个早期的具体需求规范，然后他们被“签署”，随后将这些需求规范传递给开发团队用以实现一个需求“合同”。
在项目执行期间，专业律师也许会通过法律的语言来加剧或者改善对于这些非法律性“合同”的病态关注。例如：如果他们起草了一份合同其中包含一个条款，要求在开始实施之前定义和签署所有或多数需求规范，那么项目就缺乏灵活性，且过分强调了（非法律性）“合同”谈判。
尝试…律师研究因孤岛心态而缺乏系统思考
图.（来自国际合同和商业管理协会，简称）描述了对于公司律师在-年期间关注的大（前中）合同条款问题。很难想象交付人员每天都在为大多数被列出来的问题所困惑。（注释）令人惊讶的是，没有一个提及到合同目标（项目目标）。最重要的是关于合同如何结束，对于可交付物的期望（例如，加速处理账单的软件），并没有被列在大问题之中。
传统的非敏捷设想类似于购买高端雷克萨斯。最终的交付方案具有所有的优异性能，外观闪亮。那么与汽车的隐喻一致，律师可能设想一种制造方法首先制造底盘，然后放置引擎，然后是车身和电路，然后是内饰和油漆。那么，直到所有组件被组装之后，你是无法最终看到最终产品是如何组合在一起的。
这种保护风险暴露的合同机制设计，其压力是巨大的。对于客户来说，这意味着在最终交付之后必然有延迟的、复杂的最终用户接受制度。同样这也意味着，直到最终交付之前客户根本无法确认汽车的质量。在软件项目中，这意味着用户希望对项目的总体范围有最大程度的保护，通常的做法是项目总成本的责任加倍。这同样意味着供应商无法在项目结束前交出令人满意的最终交付物，也可能无法确认订单总价值。
敏捷项目同时解决了那两个问题。它的目标不是迭代地构建部分的项目组件，而是在两周的迭代中构建一个对客户有价值的、可部署的、可以被接受和使用的工作模型。对于敏捷概念不熟悉的专业律师并非总能抓住关键；他们会误以为敏捷开发增量交付不可部署组件，而不是在每个短迭代之后都可以交付可部署的、逐步增加功能的系统。
第一个迭代之后，可部署的解决方案或者模型可以被描述为 ——一种更简单的入门级车型。当每个迭代交付以后，工作模型级别会在功能和外形上上升。从某种意义上说，这更像每两周就以旧换新一次（注释）。这种方式的含义对于类似责任和风险暴露等概念是非常重要的。用户（每两周都会）获得一些已付款的和可接受的有价值的东西。供应商可以确信他交付了可以确认收入和有价值的东西。即使出现了关系破裂而且项目陷入困境，相对于双方的风险暴露而言，最后的交付都是完整的（注释）。客户不会被迫去支付那些比搁置软件好不了多少的“烂尾项目”，供应商也不可能因为付出没有回报的努力而被留下来。当然，双方的最终期望可能都没有得到满足，系统可能没有足够的功能去做有效地部署（注释），不过从纯粹的业务和风险暴露的角度来看，各方相应的顾虑并不会像传统的“瀑布”项目一样减轻掉。对于律师来说，了解这一点对他们如何考虑，谈判和起草项目合同的影响至关重要！
尝试…律师们学习敏捷性是如何降低风险和暴露
以下三个方面是通常需要在合同起草的时候被考量的：（注释）
风险和暴露（责任）允许改变的灵活性明确义务、可交付物和期望敏捷项目合同可以与传统项目合同一样阐明责任限制（和相关条款），但是敏捷合同将更好地支持避免律师担心的问题。也就是说，采用敏捷方法实际上会降低风险，提高客户的相对利益。不涉及敏捷方法的合同实际上可能会做与预期相反的事情，并增加风险并抑制客户的利益。
注释：这种类比是不完美的：与汽车交易不同，软件和其合同可以在每个迭代周期变成更宏大的东西。
注释：这种简化类比并没有解决预期成本、间接损害、利润损失和其他损害的问题。
注释：这种简化类比并没有解决预期成本、间接损害、利润损失和其他损害的问题。
注释：这里显然有许多不同方面的合同，不过他们可以被简单的分成这三类。
这方面的一个例子是需求收集和测试那些为满足需求而开发出来的软件。在瀑布开发项目中，律师将（通过合同语言）强制客户希望阐明每个可能的案例和随之而来的测试，以满足预期的要求。
敏捷方法考虑到需求将以迭代和渐进的方式阐述，以便在开发软件时不浪费时间和金钱来满足最终不需要的需求。它还认识到，可以更好地将资金用于开始时未被认可的要求。在顺序开发项目中确定和开发的需求可能永远不会被使用，因为它们设计错误或缺乏与真实用户的有效互动。在交付“符合合同”的系统后，仍然需要添加要求以满足真正的需求。从合同的角度来看，这意味着基于顺序方法的合同实际上会增加风险，即客户支付更多费用却比预期得到更少，但如果合同中能够理解并考虑敏捷方法时，就会发生相反的情况。
从法务和财务的角度来看，这一点怎么强调也不过分。在瀑布开发项目中，客户可能会支付远远超过预期成本，以获得她最初期望的东西。附加合同无法防止这种情况，实际上却会促进这种错误的假定，即认为有可能在没有持续反馈和渐进理解的情况下定义和交付大量需求。
推崇或强制瀑布生命周期开发的合同会增加项目风险
对于法律从业者来说，这意味着敏捷原则可以保护客户免受他们可能不知道的事情的影响。这与早先律师对当事人所认为的责任相吻合。因此，一旦律师知道敏捷原则，他就不会继续允许（通过继续写传统合同）客户支付他不需要的东西；转而允许客户额外支付去实现那些他真正所需要的东西。
这才是敏捷方法的含义：
降低风险，因为它限制了交付范围和支付范围允许不可避免的变化将谈判重点放在被忽视的交付领域首先，作为业务一线的实际工作人员（对于新系统）和供应商开发团队必须紧密在整个项目的生命周期中参与和合作。鼓励法务人员在合同谈判和起草过程中寻找这种合作迹象并加以鼓励。
这种类型的持续合作并不意味着由于互动和联合开发的增加，促使律师会有大量的机会来收费（或者如果是内部的，那么现在就需要进行大量的工作）。相反，这意味着必须创建某种契约的结构，以允许客户进行持续的参与、评估和演进。如果创建了正确的模型，律师至少可以减少进一步参与，除非冲突发生，因为基于敏捷方法的正确框架将促进合作。
尝试…通过类比法律工作来提高律师对软件项目复杂度的敏感性
如果你是一名教练或者经理，有兴趣提高专业律师理解软件项目固有的复杂性、可变性、探索性的本质，尝试与他们分享下面的思想实验：
“我想为我的新项目签订一份完整的项目合同：一个新的企业级财务管理系统，可能涉及六个国家的大约名开发人员，涉及四个以前从未使用过的外包服务提供商，需要两到四年才能完成。精确到小时，您需要多长时间与四家供应商谈判并签订合同？精确到字数，合同中会有多少字？具体成本是多少？”
讨论该场景与软件开发之间的相似性，哪些方法是现实的、有效的，哪些是不现实的、无效的，据此去处理那些不确定性、可探索性和多变性。
律师肯定会说，在这种情况下，由于合同起草和谈判的演进性质，在任何程度上都不可能确定最终合同是什么样的。律师可能会给出一个大概的数字，大概是多少时间，一般来说，要谈判一个完整的合同，比如说，小时，但绝不会承诺任何具体的实际总小时数。然而，具有讽刺意味的是，律师和业务领导人（以瀑布式的思维）期望人员通过需求分析和表达在很大程度上来确定一个比“合同项目”要复杂得多、规模更大、可变性更大的软件项目是什么样的、要花多少钱。
避免…奖励和惩罚
对于参与合同的相关人员（法律专业人员，销售人员，采购代理人……）花费大量时间在合同中编造、谈判和编写激励和惩罚条款是很常见的。有一个“毫无疑问的”假设和信念，即激励（与绩效或目标日期相关）或奖金是有益的。然而，这与基于证据的管理研究不一致，并且有充分的证据表明激励导致博弈增加、透明度和质量下降以及其他功能障碍。这些研究在我们的《精益和敏捷开发大型应用指南》一书的组织章节中进行了总结。
惩罚（逆向激励）也带来了同样的问题（注释）
激励和惩罚也促进了客户与供应商之间的对立竞争关系，而不是合作。
可选方案？
简单性——没有基于绩效的奖励或惩罚如果客户对表现非常不满意，请在迭代结束时终止合约共享的损益模型尝试…共享损益
在未来的一些章节中，例如“尝试……目标成本合同”一节中，介绍了分担损失或收益的模型。这可以促进合作并共同改进。例如，在目标成本模型中，如果实际成本低于目标，则客户支付较少且供应商利润率较高。
避免…“质量管理计划”和“交付物清单”
传统的合同外包工作涉及低透明度和信任度，并且在某些软件完成之前会有很长的延迟。对此的一个（许多）经典合同回应是要求一个传统的“质量管理计划”或“交付物清单”，它定义了一份很长的文档检查清单，而不是专注于提供真正的价值：可工作软件。一位谈判代表与我们分享了以下故事：
注释：我们并不是指重大过失的重大处罚，而是涉及与业绩变化相关的处罚。
参与合同谈判的敏捷主义者，需要对额外的文档持怀疑态度，且争论如何衡量生产它的成本——但他当然愿意讨论组织可能需要它们的原因。我的经验中最坏的情况是，我与一家公司进行了一次非常长的谈判，这家公司在喜欢敏捷的业务人员和传统的内部人员之间存在着巨大的内部鸿沟。带头与我们谈判的业务人员向内部团队“扔了一根骨头”，因为部门同意“质量管理计划”。代表试图通过“质量”计划的各种草案重新构建瀑布思维和文档，以及传统的命令和控制。幸运的是，我们终于成功地有效地消除了代表为自己建立的质量计划和专制的无价值产出的“质量经理”角色。
如果有的话，什么可以消除（假设的）对交付物清单的需求？在中，“完成的定义”是供应商团队与客户方业务领域的产品负责人共同定义的，且在每个迭代持续演进，而非经理或法律专业人员制定。合同律师需要理解“完成的定义”，因为它改变了敏捷合同的合同框架和项目的完成方式。简而言之，通过活动和工件，中定义了每个迭代中产品增量的“完成”标准，并且产品在每次迭代后都是潜在可用或可交付的。例如，对于特定迭代和特定产品的“完成”定义包括“编码、集成、功能/性能/可用性测试、文档”。（实际定义将更长、更详细、更明细）。需要重申的是，“完成”在每次迭代开始时由供应商和客户重新定义，且随着双方学习到真正有价值的东西时，它将而自适应地发展。
尝试…与律师更多地更早地合作
合作高于谈判，以及更多和更早的反馈循环不仅适用于外包的敏捷开发项目中的客户和供应商，还适用于与法律专业人员的接触。
图. 合同灵活程度和早期律师合作的系统动态图
图.中的系统动力学模型从广义上说明了增加对合同灵活性和协作支持的可能结果。但与本节特别相关的是，图.还说明了越来越多早期律师在商业风险和项目中的合作所产生的影响。这种更紧密的参与是《精益和敏捷开发大型应用指南：跨职能团队》一书的团队章节中探讨的更大主题的一部分。人们常常错误地认为跨职能团队的边界是研发或部门的人员。（其实并）不是这样。例如：
“最小” 跨职能意味着团队成员资格至少包括项目中涉及的所有关键功能，通常包括工程，市场营销和制造。[]
纳入法务来超越“最小跨职能团队”
以下是我（这里是汤姆）看到推迟律师参与和孤岛思维的影响很大的案例：商业领袖通过创建一个新的基于网络的计费系统来确定营销和节省成本的机会。商业案例依靠廉价开发——他们认为这可以通过离岸外包来实现。最终，在提案和招标过程之后，选出了最终人选，双方开始谈判。这通常是法律专业人员参与制定合同条款和条件的阶段。
在商业领袖不知情的情况下，许多司法管辖区最近收紧了跨越国界的个人数据出口规则。这一点只有在一些律师姗姗来迟的情况下才变得明显。由于这些规则，离岸外包是不可行的。商业案例论文和项目失效了。
幸运的是，错误是在为时已晚之前发现的。但考虑到律师的有限和孤立的参与——完全错过这个问题，导致（如图.所示）增加公司风险，这本来是很容易的。即使它在项目开始之前被捕获，最初的工作也消耗了大量的业务资源。除了浪费这项废弃的工作之外，随后对新业务案例的重新处理以及新的提案和招标周期减少了商务人员探索其他商业机会所需的时间和精力。
除了包括法律专业人员在内的跨职能团队的价值外，本案例还说明了人员不一定理解的一点：合同律师有责任考虑两种风险：
内部项目风险 * 随着敏捷开发的发展，这些都会减少，因此法律专业人员有责任在合同上支持这一点连锁效应的风险 (例如数据出口违规)* 包括法律专业人员在内的跨职能团队以及早期、定期的合作减少了这些风险
编写合同，敏捷合同入门（下） ♂
敏捷合同入门（下）
本文源自——《精益和敏捷开发大型应用实战：利用大规模进行大型、跨地区的离岸产品开发》
作者： , ,
请将您对未来版本的评论发送给我们
网址为
注意：请到网站查看最新版本
分享（而不是文件）以保持最新版本
第一部分（上）：对合同的思考
第二部分（中）：敏捷合同的常见话题
第三部分（下）：敏捷合同的模式
作者简介：
是一名结合了敏捷原则、系统思维和精益思想知识的并且在项目管理和敏捷合同具有多年经验的律师。他主要从事了以下三方面的工作：）为外包服务的客户担任合同律师；（）作为外包商（“供应商”）的专业律师；和（）为供应商开展业务（利用销售协议来影响合同内容）。领导 公司的专业服务和法律业务团队，专门从事、并购、谈判、交付管理和运营。他曾担任英国电信的副总裁以及电信和技术领域的执行和法律职位。他曾在私人执业律师事务所工作过，并在加拿大最高法院提起诉讼。他毕业于科罗拉多大学和不列颠哥伦比亚大学法学院。
作者简介： |
和 是（） 《精益和敏捷开发大型应用实战》 （ & : , , & ）和（）《精益和敏捷开发大型应用指南》（ & : & - ）的作者。
他们作为组织设计顾问，以及作为大型系统产品开发，在离岸和多地开发中采用精益思想和敏捷开发的团队中的管理和工程教练。
译者：何强、 ;何强（/)，北京三星研究院敏捷教练，近十年外企研发管理经验，敏捷变革的爱好者和践行者。
(/)， ，目前就职于阿迪达斯数字化中心，敏捷实践者。校审：申健(//)，自年开始在诺基亚西门子通信实践敏捷开发，大规模()亲历者，现任优普丰敏捷学院合伙人。
以下为正文
第三部分：合同模型
人类自古开始撰写合同，其中囊括着他们的希望和恐惧。合同有无数的模型和变体，你可以参阅推荐的阅读材料来更广泛的了解。本节将聚焦于介绍敏捷项目中的客户和供应商常见模型及变体。
避免……固定价格、固定范围（）合同
固定价格、固定范围——甚至更糟糕的，固定周期的合同和项目会让供应商和客户趋向双输的糟糕情况；客户经常不知道他们真正需要什么，供应商也很容易有亏损。
在带着价格和范围约束条件下去交付东西的时候，供应商经常会降低交付物的质量，包括降低代码质量，减少测试等等。
所有这些都导致客户未来成本的增加，他们最终将不得不为过去的错误付出代价，他们需要后续提起变更请求（注释），以获得他们真正需要的东西，而且低质量的软件和高昂的“技术债务”会增加额外的维护支出。
固定价格出价已经将大的风险意外事件（占预估成本的高达％）添加到总体价格中——此溢价通常隐藏在工作量估算中（注释）。
注释：.美元的价格依据：考虑到人天费率为美元，项目需要,人天和,故事点，.美元就是总价为,,美元的每个故事点的价格。
注释：印度的传统离岸外包商非常享受这种变更请求模式，因为他们从中获得了很高的利润; 他们非常清楚他们的合同无法交付客户真正需要的东西，他们期待他们通过开发客户不满意的系统之后，客户付出需求变更费用来满足他们真正的需求。在印度，他们称此为“租金”。
这将导致项目执行期间双方透明度降低并且双方博弈的增多，因为供应商希望将此溢价作为利润而不是正常的预算消耗。此外，由于签署的早期需求规范几乎无法包括真正的需求，（这主要是由于这个固有的复杂领域中的多种混合因素），供应商在印度能够产生进一步的收入，外包商称之为“租金” ，亦即通过一系列后续变更请求，每个变更请求都是在超出原定价格以外的额外成本。
在各种局部优化的伪装之下，固定价格项目得到推崇（而不是以项目成功为目的）; 我们鼓励专业律师注意这些：
作为客户，最重要的是了解财务报告或预算的成本（注释）作为供应商，最重要的是确定总订单价值。作为销售人员，最重要的是确定总订单价值，从而能够获得全额佣金。作为管理者，最重要的是避免在项目上浪费时间。管理者需要的是订购一些东西，在没有“干扰”的情况下转向其他工作，然后在项目最后能够成功得到那些东西。但有些公司，出于某种原因，仍然在尝试那种方式。在那种情况下，我们得到的最常见的问题是，“你如何使用敏捷方法进行固定价格且固定范围的项目？”首先，它是可能的; 和其他敏捷外包供应商已经这样做了（因为市场需求） ——尽管这是他们最不喜欢的模式。
和敏捷方法问题背后经常存在两个误解：
第一个误解是，当使用敏捷方法时，在第一个迭代开始前无法知道或者估计整体项目发布需求。这是错误的。其实，在中，在第一个迭代开始之前，是可能有初步的发布规划（也叫初步创建产品待办清单），在这个时候所有确定的发布需求就已经被澄清和被估计。第二个误解就是用敏捷方法时，需求就必须改变。这也是错误的。其实，所有的敏捷方法都给学习和改变提供了机会和机制，但是并不是必须要求去改变。也可以被用于一个确定内容的发布规划中，而且仍然可以提供它的优势。这需要感谢工作方式、技术、测试结果以及小规模增量带来的更频繁和更高效的反馈。使用或任何其他方法，有一些关键点可以避免在使用项目时造成破坏：
注释：由于这个原因和其他原因，合同也被称为“最晚日期，最高成本”合同。
注释：参见配套书中“组织”章节的“超越预算”部分，以替代传统的预算程序。
针对大型项目进行详细的前期需求分析，定义完备的验收测试集，所有需求的熟练工作量估算方面，尽可能地进行尽职调查，并且所有这些都需要由经验丰富的人员完成。不允许对要求或范围进行任何更改，或仅在同等工作量条件下允许新需求取代现有需求。增加合同价格的余量，以反映软件开发中固有的重大风险——这个领域充满了发现，可变性和令人讨厌的意外。聘请拥有卓越的技术，经验丰富的领域专家。注意，长期的、亲力亲为的优秀工程师，以及经理作为工作中的老师去辅导团队，这样的精益文化才能提供给人们经验成长的培养环境，从而减少项目风险。
付款时机
的付款时间通常是每次迭代之后，并且在最后一次付清（如果以前没有用完总付款）。每次迭代付款的数量是项目总价的固定百分比，或者是按照预估的总迭代数，或者，如果项目也是固定的那么就按预定义好的迭代数。
使用实现项目的灵活性
在使用执行项目时，有几个低风险区域提高了灵活性; 有能力做到：
使用同等工作量的需求来替代现有需求这个可替换性选项非常重要改变固定需求的实现顺序每次迭代改进“完成的定义”（注释）还建议了另外两项合同条款：
客户可随时要求提供额外的版本发布，并以＆定价如果项目提前获得满意，客户可以提前终止合同，并向供应商支付剩余未开票价值的％。注释： 是敏捷方法的共同创建者。
专业律师需要意识到这种灵活性的存在而且应该在合同的条款中表达。
我们应该采用顺序进行的传统方法进行项目吗？
有一个问题有时候会被问到，“如果我们必须进行项目，我们应该使用敏捷方法还是顺序生命周期（瀑布……）式的传统方法？”
有证据表明，与迭代、增量或敏捷方法相比，顺序生命周期开发往往与更高的成本、更慢的交付、更低的生产率、更多的缺陷或更高的故障率相关。[，，，，，，]。
因此，使用传统的顺序开发方法将是你将项目变得更糟的最后一个事情。
恰恰相反：如果你使用执行项目，你将能够减少浪费，减少排队队列，减少在制品数量，并且你将获得有关项目真实性质的早期现实反馈。根据早期反馈，你可以提前调整而不是项目延期。特别是在项目中，你想要尽可能快地知道坏事; 敏捷方法增强了反馈。
在项目上使用敏捷方法有一个更微妙的优势：它可能演变为面向协作的灵活项目。许多客户利益相关者都明白模型可能无法解决他们的问题，但是被强制施加于他们——可能是法律或财务部门。一旦客户开始直接与敏捷软件供应商就着表面上看起来固定的项目进行交互，并且每两周快速交付一个完善的解决方案，而且能够改变迭代顺序——实现其固定需求的顺序（并替换需求） ，这样客户与供应商建立信任和协作，“固定”可以变得“灵活”。客户慢慢就会放松警惕，看到“客户协作优于合同谈判”的优势，并同意不太关注原始定义而更多关注进化发展以满足他们的实际需求。
最后，在使用完成初始合同之后，客户可能愿意为后续项目使用其中一种备选敏捷合同模型。一些敏捷外包商已经与客户一起体验了这些积极的模式。
尝试……可变价格变量范围渐进式合约
在最纯粹的形式中（注释），渐进式合同意味着完全灵活的范围，后续开发范围都会在后续迭代中自适应地定义。他们是敏捷项目的理想候选。
注释：称为开放式可变范围，开放式增量或不确定交付无限量（）的变体。
[].它们是主服务协议或大框架合同，它们定义了每次迭代的总体关系和定价方案，但没有定义范围。渐进式合同没有定义总固定项目价格——尽管一种变化具有项目上限。
由于每个迭代都会有一个可工作的系统，所以客户风险受到很好的控制，因为客户合同终止可以在任何迭代结束时发生。如果双方都对这种关系感到满意，那么渐进式合同项目可以无限期地继续下去。
通常（但不是必需的）在每次后续迭代之前，客户和供应商定义即将到来的下一个迭代的目标，有时候是通过验收测试的测试用例。有时在是在第-迭代期间澄清第个迭代的目标。
每次迭代的定价运行各种变化：每次迭代的固定价格，每次迭代的＆等等。
变体——在，限价变动范围累进合同十分常见; 它设定了项目总价上限。每个迭代的定价是任何变化，例如＆。同样，频率是一种限价变动范围累进合同，带有无约束的发布待办清单，由各方在合同签署前创建发布目标的待办清单。该待办清单包含在合同的附录中。但是，各方都同意原始待办清单中没有任何内容具有约束力。
（这就是传统）为什么在合同撰写之前就要创建无约束的发布待办清单？它被用来估计大概的发布上限，同时提供一个开始节点的共同愿景。在先前单独的合同接触阶段，去创建这个无约束发布待办清单也是非常常见的现象。
渐进式合同是敏捷外包商和与之建立信任关系的长期客户的常见合同模式。一种经常发生的模式（不是推荐）是
. 早期合约是固定价格，固定范围的变体
. 之后，转向渐进式合约，简单的＆或每次迭代设定上限的的＆
尝试……增加项目灵活性和合同的变量
范围可变、价格可变、日期可变等纯累进式合约都是灵活的。任何变量（范围，价格，日期）的灵活性都各不相同，具体取决于客户和供应商之间的信任和协作水平，或者受到政府监管等其他限制。敏捷外包商创建的合同变更包括以下内容：
上限价格（注释）、范围可变——在上一节已经进行过讨论
上限价格、部分范围确定——只有小部分需求是确定，这样可以给学习和调整留一些空间。
固定价格、范围可变——这种范围可选的合同[]是这种模式的一种变种，并且结束日期固定。
灵活合同中的约束风险：多阶段模型
多阶段模型在第页的“尝试…多阶段变量模型框架”一节中进行了描述。简而言之，它通过一系列较短的合同实现了更长的项目。
如果双方信任度低，客户可以通过使用一系列短期，灵活的合同来约束他们的风险（和恐惧）。例如，长达一年，固定价格、固定日期、可变范围的合同可能会被惶恐地看待。但是，一系列的两个月、固定价格、固定日期、可变范围的并且能够在任何周期结束时终止的合同——看起来更加合胃口。
另外，在几个合同周期之后，双方慢慢建立信任。此时，客户可能会转换为每次迭代的＆定价的简单累进合同。
注释：在本节中，价格是指整体项目价格。
分享或适应性地改变损失/增益或风险的模型
对于双方来说，项目都有潜在的风险和回报，而且这些可能会随着时间而改变。例如，项目似乎将大部分风险转移给了供应商，尽管由于之前确定的原因这是一种错觉。
下一步探讨的一些框架已经明确制定出来，用来分担这些风险和回报，并将风险转移到适当方面从而能够采取措施（注释）。
在最好的情况下，这些框架提高了各方动机的一致性，因为它们都具有“自身的利益在其中”。同时，它们可以改善基本的公平性和关系建设。这种理念是双赢方法核心概念，它将创造信任和关系，促进进一步的合作业务。
但合同本身并不能创造信任和一致性。在最糟糕的情况下，这类合同被滥用，成为了指责游戏的一部分，将损失转移到另一方并且只能一方获益。
这些框架包括
目标成本多阶段变量模型利润共享尝试……目标成本合同
目标成本合同有助于对齐双方的动机。它们被用于丰田的供应商，体现了精益思想中支柱之一——尊重人，丰田试图在信任和相互支持的基础上与供应商建立稳定的长期关系。
该模型假设了一个初始的发布计划步骤，在该步骤中确定了整个项目范围。这是确定目标成本第一阶段的一部分：
. 在客户和供应商之间的协作中，识别、分析和估计所有可能的项目要求。
. 在协作下，估算项目期间的变更或范围增加的成本。这很重要;因为目标成本合同必须尽可能实际地考虑总体工作量和成本。
. 从这两个要素中，确定目标成本。
. 根据目标成本（例如，目标成本的％）计算目标利润。
. 与客户分享所有细节和结果（这很重要）。
注释：这通常意味着将与需求相关的风险（“做什么”）置于客户手中，并将实施和技术相关的风险（“如何做”）置于供应商手中。
在第一阶段，这个模型成功的关键是()通过熟练的尽职调查产生的尽力服务的估算，而不是想当然估算的目标成本，以及()(供应商)公开成本核算，以便客户透明地查看导致计算目标成本的所有细节。
目标成本合同中的第二阶段是项目执行——例如，使用。项目双方很快就会意识到，成功的关键实践是跟踪所有实际成本（例如，开发人员花费的时间，会议时间，硬件成本），并以近乎实时的方式透明地与客户共享所有成本信息。
目标成本合同的关键方面是根据实际成本和目标成本之间的差异而调整的、双方共同承担的损失/收益公式。该公式有几种变体。
一个简单的例子：
调整值=（实际成本-目标成本）*客户分担成本差值的份额
客户支付数目=目标成本+目标利润+调整值
如下所见，调整值有可能为正，也有可能为负。
假设协议是任何成本差异的％份额是给客户的，％份额是给供应商的。那么：
如果成本高于估计，供应商和客户都会分担损失：供应商的利润较低，客户承担部分成本负担。如果节省成本，双方共享收益：供应商的利润更高，客户支付的费用低于原始目标付款。
这意味着双方都会尽可能积极推动减少项目期间浪费的方法，尽管这一点无法保证。
付款模式的变化
合同起草人已经引入了很多付款方式的变化，包括：
有上限（天花板）的客户付款数目如果超出目标成本，降低供应商的单价可调整的目标成本和目标利润
支持敏捷和迭代价值的目标成本合同的另一个基本要素是通过各方之间的持续谈判来调整目标成本（和利润）的能力。成功调整目标成本的关键包括
供应商的高透明度和近乎实时、公开的项目账目，以便客户了解供应商的真实费用状况客户和供应商共同努力的精神，不断改进这是丰田在[]上持续不懈努力的部分合同中双方就目标成本调整准则早日达成协议一个适当的调整周期，以避免对调整过度反应，或在调整时使用过多的开销; 例如，每迭代调整一次可能太过频繁利用测试驱动开发来进行验收，减少歧义这些实践能够减少但不会消除正在进行的重新谈判期间的争论，因为调整的问题通常具有内在的模糊性——类似“这是一个缺陷还是一个需求？”
一个小组报告（注释）说，以下事先商定的调整方案减少了争论：
注释：在[]中描述的是一个关于敏捷项目的目标成本合同的故事。
我们不建议这个或任何其他模式; 因为它会帮助或导致冗长无用的谈判而不是合作。
尝试……多阶段变量模型框架
随着时间的变化，项目的不确定性或风险状况同时也会发生变化，理想情况下合同双方会对此进行改善。多阶段框架合同中可以反映出这些变化。任何一个阶段都可以使用任何合同模型：，渐进式，目标成本等。
在的多阶段变量模型示例反映了常见的模式:()创建初始产品待办清单()自适应迭代开发。这是一个涉及个国家的项目干系人的大型解决方案：
第阶段 – 固定价格，固定期限，可变范围。从本质上讲，这是初始创建产品待办清单。此阶段的输出是产品待办清单,或者更确切来说，是一个产品发布待办清单, 以及包括基于研讨会和团队分析的各种业务分析（市场分析，愿景……）文档。虽然合同中确定了要交付的特定文件清单，但分析范围或内容各不相同。通过产品发布待办清单，成本估算变得可实行，因此……第阶段 – 渐进式合同，包括每次迭代的＆，设定发布上限，非约束性产品发布待办清单，固定期限。第阶段基本上是一个经典的项目：原始待办清单中的任何内容都没有被限定，但它用于估计和约束发布项目成本，提供初始概览，并定义在第一次迭代中启动该做什么。为什么要使用这些多阶段模型而不是简单的渐进式合同呢？通常情况下，这么做的激励因素是()双方缺乏信任,()监管限制,()一方相信他们可以节省更多资金或更好地降低风险,()定义项目愿景的需求，高层次概览性需求，或后期成本考虑（以及此项工作本身的工作量很大），或()“优化”次要目标(在项目成功之外)，例如更好的成本可预测性。
[]中的另一个例子：
. 第阶段 – 固定价格部且分固定范围，用于前三次迭代（固定期限）。“强制”的固定范围较少（例如，占可用工作量的％），于是在不确定性较高时为可变性和探索留有足够的空间对客户和供应商来说，风险都是有限的，并且双方都对第阶段持续性项目的性质有了很多了解。
. 第阶段-，期限可变。由于知识的增加以及在第阶段中某些变化源的减少，供应商在承担阶段的风险降低了。
结 论
“当涉及双方合作合同时，我们怎么可能做敏捷开发？”这是我们经常被问到的一个问题。但关键问题不在于合同，而在于合同编写者和他们所服务的客户——这反映出大家相信成功是更多地围绕合同谈判而不是围绕客户协作，或项目成功并不是合同事务的目标。这里我们重申一个系统思考的警句，“不指责”，这句话暗示系统中人的行为是由系统塑造——在本例中，由于鼓励部门孤岛、局部目标（和奖励）导致本地优化以及传递出来的微妙信息，“律师不需要了解运营细节或研发的新方法，那是别人的工作。”
此外，当被问到这个问题时，“合同”通常被用作“固定价格固定范围”合同的同义词，但这根本不是必然的——在现实中有各种各样的合同模型，包括可变范围渐进合同等。
在制定合同时，法律专业人员有责任考虑双方的信任和合作崩溃的后果以及其他问题。正如合同律师需要更多地了解精益和敏捷原则一样，其他各方需要更多地了解律师必要且有效的关注点。正如跨职能开发团队可以改善产品工作一样，通过将法律专业人员纳入更广泛的跨职能团队，团队效能可以得到进一步改进。
推荐阅读
第一步是阅读第页“尝试…律师也去学习敏捷、迭代和系统思考等概念”一节中列出的建议。
网上有大量资源，涉及敏捷开发和合同; 然而，有些是推测性的而不是基于经验的，请在阅读时牢记这一点。一些读物：
和 是精益软件开发的思想领袖，多年来组织了多个合同研讨会，并在他们的网站上收集并分享了“精益和敏捷合同”论文和演示文稿。遵循类似于本章的主题，自己的敏捷合同材料强调了与合同相关的信任，协作和透明度的基本问题。 和 撰写了关于“进化合同模型”称谓下的敏捷合同的文章; 请访问查看他们的文章。在.上， 撰写了一篇文章，总结了“下一个敏捷软件项目的种合同”( )。 及其同事在“增量承诺模型”（ )主题上撰写了几篇文章（可在网上获得）。一些刚接触该主题的人认为鼓励灵活性\协作和利益一致性的合同（“敏捷”合同）是一个新颖的概念，但实际上多年来在这个领域已经有很多写作和推广，包括在美国政府（例如，参见 ）。有数十种（如果不是数百种）书籍和网站讨论各种合同模型。我们已经审阅了几种明确支持迭代、进化或敏捷开发的“公开”合同模型。但是，和以及我们所知道的其他敏捷外包商 ，选择编写自己的合同而不是使用这些模型。我们不鼓励“复制粘贴”合同写作，但这些都值得深入思考：联盟（是一种敏捷方法论）提供了样本合同，在上提供给成员。请注意，合同不时会被修改。挪威 合同是由行业和政府之间的联盟为迭代和演化发展而创建的，可从获得。我们从合同中引用一段，“当在招标前难以甚至无法制定详细规范时，[合同]将发挥用处，我们的想法是让开发人员找到实现目标和满足客户需求的最佳方式。参考文献
[] , ., . ,
[] , , . “ . ,”
[] , ., , ., . “ ,”
[] , ., , ., , ., , ., . “ - ,” , /
[] , ., , ., , ., . “ : .” - ,
[] , ., , ., , ., . “ : - .”
[] , ., . , -
[] , ., . “ : ?” , /
[] , ., , ., , ., . ’ : ’ , -
[] , ., . ,
[] , ., . : ’ , -
[] , ., , ., . & : - , -
[] , ., . “- ,” - . . , . .
[] , ., . “ ,” , ..//..-//?=
[] ?-?, ., ?, ., . “ — ,” , . , . ,
[] , ., . ,
[] , ., . ’ ,
[] , ., . “ ” ,
[] , ., , ., , ., . “ ,” — - : . ()
[] , ., , ., . , - ,
[] , ., . “ ?” , / .
[] , ., . : , -
全文完
编写合同，敏捷合同入门（上）的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于编写合同，敏捷合同入门（上）的信息别忘了在本站进行查找喔。
还没有评论，来说两句吧...