重要的是要注意,敏捷不是采购的方法,但承包商遵循软件开发时的一种方法或功能。敏捷开发的合同不应混淆快速收缩,流线型的收缩,收缩或敏捷,敏捷开发的不同于承包的形式讨论了这个模型。

创建一个有效的合同是具有挑战性的,但却是重要的,元素在实现敏捷开发实践的好处。长收缩时间和昂贵的变更请求已成为执行敏捷发展的重大障碍,使小,频繁的发布。收缩策略必须旨在支持敏捷项目短开发和交付敏捷开发所需要的时间。今天,一个完整的和开放竞争的合同可以只要12 - 18个月。这样的时间表有许多IT项目驱动的结构项目大,五年的增量,进而推动重大的项目风险。理解真正的安排司机、约束和规定缔约过程是设计一个最优敏捷收购战略的关键。

敏捷开发的合同已被证明非常困难不仅对国防部还对很多其他联邦机构。当前的承包环境往往是不一致的与敏捷开发方法。在许多方面,当前环境下的对立面是需要什么支持敏捷开发合同。2012年7月的报告在应用敏捷方法有效的实践和联邦的挑战引用“采购做法可能不支持敏捷项目”是一个关键的挑战。承包敏捷开发提供了一个独特的挑战,政府不是经常遇到在私营部门因为商业公司通常依赖于内部员工执行敏捷实践,而政府必须通过合同安排获得敏捷开发的支持。下面的表格识别的一些关键承包领域传统承包实践敏捷合同需求不相符。

当前的承包环境和敏捷需求萎缩

当前的承包环境	承包面积	敏捷需求萎缩
长收缩时间常常成为程序执行的司机。	时间线	合同执行支持开发和交付时间表。
功能需求是锁在合同;变化通常需要昂贵的合同修改。	范围	合同允许程序完善敏捷需求在整个开发过程。
在大多数情况下,承包商执行技术解决方案和进度定期向政府报告;政府主要是执行一个监督的作用。	政府承包商的关系	政府和承包商一起工作与日常交互和协作开发;政府和承包商作为合作伙伴。
承包支持通常身体驻留在另一个位置;因此,合同人员不能提供一致的支持和快速周转合同行为。	合同支持	承包支持物理位置的程序使有效执行合同行为和提供日常业务咨询支持。
要约人提出了开发方法和合同授予基于强度的技术解决方案。	技术评估	政府渴望追求敏捷开发过程和合同授予基于强度与敏捷开发团队和供应商的经验。

敏捷合同流程必须深思熟虑的和良好的执行力,使项目满足常规项目交付时间表。收缩策略、流程和文化必须创造一个环境,支持的小生意,频繁的发布和响应变化。小,授权团队核心敏捷要求在项目经理紧密合作,用户和承包商在国防部的环境中。政府承包社区作为一个宝贵的关键在一个协作建立这种关系,灵活的商业环境。专用现场承包支持培养与项目团队密切合作。项目经理应与合同管理人员作为一个商业伙伴紧密合作设计合同策略。合同管理人员或合同管理人员的代表(软木)依次与释放团队工作计划和管理即将到来的合同行为,确保符合合同要求和管理承包商的性能。

政府项目办公室和敏捷承包商开发团队必须有一个强大的关系表现为日常互动,频繁的合作和信任的伙伴关系。除了执行日常开发任务,政府依靠承包商的专业开发团队,帮助优化需求,估计未来的冲刺和版本的覆盖率和时机,并不断评估和改善部署的能力。合同管理人员必须与项目办公室合作,培育这与承包商协作环境。

涉及的合同管理人员和项目办公室在敏捷开发过程必须理解合同要求和功能需求之间的重要区别。在许多情况下,这两种类型的需求存在差异,从而导致危险的合同管理人员和计划人员之间的沟通。合同要求是严格限制的任务和活动,政府要求承包商执行,这在许多情况下只有一个遥远和间接关系的功能需求管理和追踪产品待办事项列表(例如,用户故事)。例如,合同要求可以参考人员所需的开发团队(例如,6 full-time-equivalent软件开发人员)而不是用户故事表达的功能需求(例如,内容搜索功能)。

没有单一的推荐承包路径或敏捷战略实现,但是与合同建立一个环境的灵活性对成功至关重要。几个因素推动一个特定的选择收缩策略。程序必须了解操作和编程优先级、约束和考虑参与敏捷开发开发一个适当的合同策略。例如,决定谁将负责主系统集成将决定政府是否可以追求一个服务和一个完成或合同产品交付。短开发周期往往有更多的可预测的需求,可以允许一个固定价格合同。很长的开发周期涉及更未知数,可能需要一个更灵活的合同类型。的政治环境可以支持一个特定的合同类型或合同。程序应该与合同管理人员紧密合作开发合同策略时需要考虑以下因素:

• 负责系统集成是谁?
• 需要什么类型的支持超出开发支持(例如,测试)?
• 全面发展的时间表是什么?
• 释放的频率是什么?
• 当前的政治环境驱动的使用一个特定的合同类型或汽车?
• 承包支持水平的要求是什么?
• 专门承包支持可用来支持多个合同的行为?
• 缔约办公室有流程,能够快速执行的合同吗?
• 可以使用政府资源积极管理承包商的支持呢?
• 这个项目被认为是高风险?
• 什么级别的风险是政府愿意接受?
• 需要什么级别的集成是?
• 是什么级别的集成风险如果多个承包商进行平行发展吗?
• 做市场调研确定可用的合格承包商和敏捷和领域经验吗?
• 是一个敏捷的过程定义良好的或已经在政府项目办公室吗?
• 其他类似的项目目前使用或考虑追求敏捷吗?
• 项目主管支持敏捷开发?
• 该程序可以利用现有合同车辆——在投资组合,企业,或外部水平?

如上所述,敏捷开发过程的特点是不断变化和重新安排需求的机会吧。要避免的情况合同范围必须不断变化,敏捷开发项目不应该选择一个承包商使用的合同类型锁在需求completion-basis预先定义了最终产品。传统上,IT开发合同通常是基于产品交付或completion-type合同,承包商负责交付的产品或功能。完成合同,承包商提出了一种开发方法对政府和政府奖励合同基于强度的技术解决方案。任何改变原始需求可能引发潜在的昂贵和耗时的工程变更提案(ECP)。

或者,政府可以考虑使用基于服务的合同或部分/ term-type获得敏捷开发的支持。在这种情况下,政府寻求敏捷软件开发的时间和专业承包商,而不是一个固定的最终产品。政府选择承包商的基础上提出了开发团队的实力和资格而不是强度的技术解决方案。然而,与任何服务类型部分的合同,这将创建一个风险,因为承包商不能负责的最终交付产品或交付完成。政府只能持有承包商负责提供合同中同意时间和专业技能;政府最终负责保证产品交付。政府和承包商之间的日常交流是一个敏捷的基础发展战略应有助于减轻未交付的风险。政府主导开发团队应积极开发周期管理和缩减功能时需要满足定时sprint和发布时间表。另一方面,团队必须仔细平衡需要满足进度要求与积累高技术债务的风险,即倾向于推迟技术要求后续版本和冲刺。

此外,当使用一个基于服务的或水平的努力/ term-type合同,政府应该认真考虑承担作为主要系统集成商的角色。政府的主要系统集成商开发过程中承担更大的责任。敏捷开发承包商可以提供专业知识和集成支持政府,但在政府服务合同是最终负责交付(承包商只能负责交付的时间和支持同意合同中,而不是最终产品交付)。当政府程序决定追求一个敏捷开发方法,它应该使一个完整的承诺,包括增加的责任和风险。作为交换,敏捷开发过程提供了更好的保证交付的功能满足用户的需求,应该成功的最终测量。

“这是要求项目经理和合同管理人员采取更高的工作量和更大的风险来换取更大的利益。”——约翰•曼签订合同人员CIS

下表确定可用的一些合同类型为一个以服务业为基础的合同策略和项目办公室应该权衡利弊。

合同类型比较服务合同

合同类型	优点	缺点
固定价格服务合同(FFP或固定价格部分)	政府风险最小化;政府通常首选的合同类型 简单的合同类型为政府和承包商管理	付款需要某种类型的可交付成果(如月度进展报告,不一定是能力交付),除非授权支付的研究进展 改变劳动组合和小时承包商困难的政府 使用所需的批准固定价格部分承包商超过150000美元 需要完整的范围完全资助的时候奖(没有增量资金)
费用报销(的努力)合同	提供灵活性改变劳动组合和小时只要不超过合同上限 灵活安排付款和固定价格 合同资金增量的基础上是允许的	确定固定费用和合同上限为合同基于敏捷需求将是困难的 合规和批准承包商的会计系统是必需的 监控合同上限是由政府要求在近水平 消极怠工的激励控制成本低于固定价格
时间和最大的材料(T&M)(劳动小时)服务合同	提供灵活性改变劳动组合和小时只要不超过合同上限 灵活安排付款和固定价格。合同资金增量的基础上是允许的	很难获得监管批准使用T&M;通常被认为是一个不受欢迎的政府合同类型 由承包商只需要尽最大努力;交付只是小时消耗 需要关闭政府监控 消极怠工的激励控制成本低于固定价格或成本类型的合同

商业部门经常使用的T&M敏捷开发合同。尽管T&M是最不喜欢政府,因为承包商的合同类型至少激励控制成本,项目应该考虑这个选项如果政府可以在积极的管理成本和范围,连续和频繁。在项目的开始——有许多未知的阶段——T&M可以提供最大的灵活性。自从敏捷开发策略需要日常政府和承包商人员之间的相互作用,监控承包商性能所需的控制是建立在敏捷开发过程和可能提供适当的监督,以确保有效的交付和有效的成本控制下的T&M安排。构建程序和任务订单分成更小的,频繁的发布(如6个月)限制风险通常与一个相关的T&M合同,因为短的性能和“构建预算”的开发周期。随着项目的持续发展道路,和团队更好地理解需求,建立了一个节奏,合同类型可能转向固定价格或成本加成的安排。

通常的政治环境或给定的合同车辆的可用性力量项目相关的合同类型。如果T&M合同是不可行或不喜欢,程序也可以考虑一个固定价格或成本报销期限合同。程序应该与敏捷估计成本和工程团队紧密合作来评估水平的努力参与建立最高限价(或固定价格)的合同。这cost-plus-fixed-fee合同尤其重要,固定费用是基于合同的比例上限的奖。此外,根据固定价格合同,政府应该建立可交付成果(如月度报告)提供的

利用服务合同时,重要的是,政府确定劳动范畴,需要支持敏捷开发工作。18 f标识以下敏捷软件开发劳动范畴,为政府提供一个很好的起点软件开发合同计划的目的。

• 敏捷教练
• 后端Web开发人员
• 业务分析师
• 交付经理
• DevOps工程师
• 数字性能分析
• 前端Web开发人员
• 交互设计/用户研究人员/可用性测试
• 产品负责人
• 安全工程师
• 技术架构师
• 视觉设计师
• 作家/内容设计师/内容战略家

合同激励

在一个敏捷开发,团队应该集中了100%的交付和快速和有效的收缩过程支持交付周期短。因此,使用复杂的合同激励机制(例如,奖励费,奖励费用)不推荐使用敏捷开发的服务类型的合同。不仅是这些类型的激励耗时和资源密集型的管理,但在服务合同政府驱动过程,时间表,和要求。因此,创造一个激励“早产”或“节约成本”可能无法实现,因为承包商不能够控制这些结果。在这种情况下,政府计划是建立承包商“快钱”或为自己设定了一个有争议的与承包商“推卸责任”。合同激励可以破坏政府和承包商之间的密切的工作关系。合同快速转变和政府和承包商之间的合作绝对是至关重要的在一个敏捷开发;合同激励机制可以成为这个项目的干扰,阻碍交付周期。

合同激励时通常使用政府没有能力或控制积极监控承包商性能。然而,在敏捷开发中,政府与承包商的日常交互。管理承包商所需的控制性能固有的敏捷开发过程。频繁的沟通和协作精神,敏捷过程的组成部分可以让繁重的激励合同,不必要的、对抗性的。

程序仍应考虑使用绩效合同承包服务。程序性能问题工作报告和使用过去的表现作为一个激励/抑制,或使用管理承包商的性能指标。

服务合同说明

如果一个程序正试图获得一个开发人员的技能和专业知识参与政府主导的敏捷开发战略,政府应该使用一个服务类型合同。这一点尤其重要,如果程序寻求一致的水平的支持从一个供应商在一系列的sprint /版本。程序可以追求一个单独的独立敏捷合同支持服务(可以花大量的时间到位),也可以考虑利用现有合同如GWACS或GSA时间表任务订单基础上获得敏捷支持服务或双酚a。如下文所述,一个服务合同授予单个供应商保证一致支持的项目整个开发几个发布周期。

政府传统上使用完成合同收购(指定一个最终产品交付),但这些并不一定是最合适的或者容易使用敏捷开发。完成合同需要预先定义需求,以便承包商可以充分估计所涉及的工作,然后准备和提交技术和成本的工作建议。敏捷的性质使得它很难详细描述需求的必要的提议创建一个成本估算(链接到成本部分)。此外,completion-type合同,政府不应该直接承包商使用敏捷开发方法。政府应该使用声明的目标(秀)来描述程序的总体目标(例如,能力交付每6周),让承包商提出一种开发方法最能满足政府的目标。很难追究承包商交付如果政府指导承包商使用一个特定的开发方法。

如果程序不能使用一个服务类型的合同,一个可能的选择是建立或使用现有的单笔IDIQ合同和为每个定义良好的释放或sprint发布命令。然而,冲刺通常有很短的时间,让它不切实际的问题每一个sprint的新秩序。版本封面更长的时间,但通常没有定义的范围和要求;更改合同后释放的需求可能会触发一个工程更改建议的必要性。如果考虑使用一种被批准的合同,政府可能包括一项条款在合同中称为“免费变化”,政府和承包商同意,要求可以切换在一对一的基础上如果改变不会导致整个合同价格。这种类型的合同修改应该不需要广泛或耗时的合同谈判;它就像政府对待免费扩展的方式)。这减少了合同管理的负担,以及提供一些灵活性要求保持敏捷开发过程的性质。

有效使用这种类型的车辆要求与缔约重要协调办公室,以及精简流程快速问题订单跟上敏捷交付周期。这个策略还需要更多的时间和资源授予初始伞合同和管理合同和订单。

项目可以考虑CPFF完成、FFP或固定价格激励费用(冈)合同在这种情况下。国防部推广使用冈合同下更好的购买力。冈鼓励开发承包商提供下面的释放或sprint目标成本获得更高的费用每协商利润调整公式。冈合同还需要政府有更深入的了解需求,开发工作需要,和估计成本有效的固定价格进行谈判。然而,这样的合同管理更困难,因为政府必须谈判目标成本,目标利润,价格上限,与每个订单和项目调整公式。此外,与任何一样完成合同类型,频繁变化和重新安排需求可能大大改变了最终产品的机会吧,开车需要一个工程变更和合同修改建议。

如果使用completion-type合同需要一个特定的产品交付,建立产品愿景,将它纳入或PWS -秀是非常重要的。的产品愿景是一个高级定义项目的范围。建立产品愿景,政府应该问以下问题:

• 谁将使用/购买产品?谁是目标客户?
• 客户需要将产品的地址吗?
• 产品属性是至关重要的,以满足需求确认吗?
• 产品如何对现有产品进行比较。独特的需求是什么?
• 什么是目标时间表和预算制定和启动产品?

建立产品的格式根据愿景TECHFAR如下:

• (目标客户)
• (声明需要或机会)
• (产品名称)是一个(产品类别)
• (关键好处,令人信服的理由去买)
• 不像(主要竞争替代)
• 我们的产品(主要分化的声明)

产品愿景分解成可管理的块工作交付增量功能。例如,如果产品愿景是开发一个在线获取知识的工具,产品愿景可以分为增量构建平台等基础设施,使协作功能,构建图书馆资源,等等,每个增量可以爆发sprint-level,版本,或任何其他级别的能力,政府可以使用它来定义一个面向产品的合同;然而,较小的或低水平的定义功能(例如,sprint),需要更多的合同行为,合同的每个增量功能。

外包测试对于敏捷需要特殊考虑因为敏捷测试可以比传统测试明显不同。外包的收购战略必须反映这些差异敏捷测试团队成功。

当涉及到外包测试合同,有几个不同的地区,支持可以感染:

• 传统咨询服务为个人项目级服务
  • 员工增加
  • 功能测试
  • 集成测试
  • 性能测试
  • 可测试性评估
• 质量保证服务,专注于完整的生命周期和跨应用的依赖关系
  • 测试管理
  • 测试卓越中心
  • 基于风险的测试
  • 测试自动化
  • 敏捷测试
  • 测试数据管理
• 质量管理服务,补充质量保证战略规划,针对业务成果基于投资组合的方式
  • 质量管理服务
  • 质量卓越中心
  • 现场咨询/评估
  • 共享结果
  • 质量保证

程序应考虑其全面的测试需求,以及需求的管理投资组合或组织外包测试合同时。是非常重要的涉及到测试机构的设计和规划一个测试合同,以及主要的开发合同。测试组织本身就是服务实体和需要提供的信息产品,在测试和准备释放将如何测量和确定。

政府有许多已存在的合同车辆,它可以用于敏捷的努力。例如:

• 一揽子采购协议(BPAs)现有总务管理局(GSA)安排合同(例如,70年计划)
• 政府采购合同(GWACs)(例如,GSA的联合,NITAAC)
• 代理水平授予合同(例如,安可二世)

政府已经授予合同,这使得它们可以直接使用。然而,这些合同有缺点比如有限选择的供应商和敏捷经验,中非专用合同限制合同类型和支持人员。

预先建立一个合同在PEO,投资组合,或企业水平将使许多程序利用合同,其简化流程的好处,让他们他们的策略和精力关注任务订单。竞争的过程导致初始奖IDIQ车辆可以长时间;IDIQ合同有好处,项目属于敏捷开发的一个企业范围的IDIQ可以加快收缩过程个别任务的订单而不是复制完整的收缩过程对于每个程序层次的合同。

在基本层面上,有单笔IDIQ合同(一个厂商奖)和合同IDIQ合同。授予合同,一些合格供应商收到IDIQ合同和合同获奖者争夺每个任务秩序——即所谓的公平机会。政府可以发行订单快下比在单笔IDIQ合同;然而,一个奖失去持续竞争的好处和承包商之间轻松切换的能力在不满意的情况下的性能。

合同车辆适合敏捷开发已预先设定的合同价格、条款和条件,预审核合格的供应商(s)。这允许将任务订单发行的几周和几个月的问题。组合层次合同车辆可以有针对性的范围应该吸引正确的供应商池和敏捷专家在技术领域。程序还可以设定不同的组合合同来满足其他需求在一个敏捷开发,例如获得承包商支持敏捷领域的专业技能,独立测试和持续的原型。然而,这些类型的合同要求项目预先投入时间和资源竞争和雨伞合同。

程序还应该考虑使用GSA安排70当进行市场调查对于敏捷开发。最近,18 f咨询,与GSA的综合技术服务,创造了一个敏捷BPA根据GSA安排70辆。功能供应商,专门从事敏捷交付服务(例如,以用户为中心的设计,敏捷软件开发,和DevOps)。迄今为止,池三个完整的堆栈设计和开发支持,合同被授予16供应商代表的大型和小型企业。目前,BPA是只有18 f(尽管18 f是一个收费服务组织,可以处理任何联邦机构)。GSA已经表示,该公司正在进行一项BPA会直接提供给联邦政府,允许任何联邦机构考虑创建自己的敏捷BPA使用GSA计划70。

当开发敏捷开发的IDIQ合同或双酚a,一个程序可以考虑几个步骤简化和改进一旦建立了车辆订购流程。订单下的多个奖项合同下公平的机会16.505部分。遥远的具体状态:

合同管理人员可能运动发展中适当的下单程序广泛的自由裁量权。合同管理人员应该提交需求降到最低。承包人员可能使用的过程,包括口头报告。

给出了合同管理人员广泛的自由裁量权来开发程序来简化发行承包车辆下订单;只要他们“负担所有承包商应对注意提交报价和一个公平的机会,提供公平的考虑。“任务或交付订单超过550万美元,需要政府提供所有获奖者被认为是一个公平的机会,并至少以下:

• 通知的任务或交付订单,包括一个明确的声明,该机构的要求;
• 一个合理的响应时间;
• 信息披露的重要因素和次级因素,包括成本或价格,该机构预计将考虑在评估建议,及其相对重要性;
• 奖是最有价值的基础上,一份书面声明中记录奖的基础,质量和价格或成本因素的相对重要性;和
• 一次机会postaward汇报

最特别地接着说,“正常的评估计划或得分的报价或提供不需要。”

政府应该充分利用在它提供的灵活性与发行订单在规定公平机会。敏捷开发的合同要求能够有效地执行订单,有效和公平。下面的列表识别策略,可以用来简化这个过程将订单合同车辆:

• 用口头建议代替纸提议减少时间和报价和方案成本。进一步简化使用口头建议,政府可以要求供应商提交口头提案提交安全的YouTube视频。政府评估者可以查看视频的时间和减少政府评估调度冲突
• 进行组的每个要约人团队的采访
• 使用视频resume-only书面评估人力资源计划的建议
• 进行基于实例评估,如提交例子工件从以前的用户故事和积压,和/或示范先前项目的成功的产品
• 开发模板和标准业务流程简化订购程序,确保订单的快速执行。
• 伪造的法律和政策办公室汇款模板、格式和流程,使有效的审查周期。
• 与承包办公室合作,制定标准性能工作报告(PWS)语言和建议的评估标准。
• 国家的基础契约IDIQ获奖者必须证明积极的过去的表现评级在其他任务订单执行的IDIQ未来有资格获得奖项。
• 用户和测试人员参与开发合同范围、评估标准,激励,条款和条件,以确保合同完全满足所有的需求和注意事项。
• 了解专门承包过程和相关的时间表执行任务订单。项目经理应该熟悉合同文件和批准要求。

下目前部分16.505还指出,任务订单发行合同车辆不受抗议,除了

• 抗议,因为订单增加了范围,期间,或合同的最大价值;或
• 抗议的订单价值超过1000万美元。抗议的订单超过1000万美元可能只是向政府问责局(Government Accountability Office),按照程序33.104。
  • 权力抗议下订单的位置(a) (10) (i) (B)本节的到期2016年9月30日,机构除了国防部、美国宇航局和美国海岸警卫队(41事项4103 (d)和41事项4106 (f))。权力抗议下订单的位置(a) (10) (i) (B)国防部的这部分不到期,美国国家航空航天局(NASA)和美国海岸警卫队。

• 做合同策略和时间支持频繁的能力释放?
• 是政府的主要系统集成商?
• 什么级别的风险是政府愿意承担吗?
• 需求相对稳定的释放水平?短跑水平?
• 政府想把开发过程还是政府希望承包商建议开发过程吗?
• 如果追求产品合同,政府必须决定使用敏捷吗?
• 缔约环境是否支持敏捷开发流程?
• 现有合同车辆支持敏捷交付吗?
• 什么是合同管理人员之间的接触和敏捷团队吗?
• 什么是政府积极地监控承包商的可用性的表现频繁(例如,日报)的基础上吗?
• 开发周期中有自然断点位置改变承包商破坏最小可行?
• 很重要保持持续竞争这个项目吗?