政府应该引导敏捷实践四个主要特征:

1. 构建程序和流程约小,频繁的能力释放
2. 重视全面的文档的工作软件
3. 应对变化的业务、技术和预算在开发过程中
4. 活跃的用户参与整个开发,以确保高操作价值

敏捷是一种文化的基础小,动态的,授权团队积极合作与利益相关者在产品开发。敏捷开发需要团队成员遵循严格的程序,需要培训,指导,和开放的态度面对改变。尽管敏捷实施严谨,方法不是由简单的后一组规定流程,而是允许动态,定制和快速发展的方法,适合每一个组织的IT环境。各种敏捷方法(例如,Scrum,极限编程(XP),看板,测试驱动开发(TDD),训练有素的敏捷交付)的出现,每个都有独特的过程,计算,和技术。这些方法专注于开发团队和相关的利益相关者。收购敏捷,敏捷开发实践超越了承包商开发团队政府收购者,用户和其他利益相关者。它要求机构和承包商都改变很多收购的角色,流程,和文化,从而培养一家公私伙伴关系密切。反过来,这需要投资时间,培训和持续改进长期股息支付。

在联邦政府,收购复杂以政府为导向的IT系统高的风险与成本和进度超出困扰,和通常不提供能力,以满足用户需求。联邦机构努力交付新的IT能力退休遗留系统老化。鉴于业务变化的速度,技术,威胁,和预算,机构需要一个环境,可以迭代交付能力和响应不断变化的优先事项。国防采办系统例如设计大型武器系统,可以十年或更长时间来定义需求,分析选择,选择一个供应商(s),设计、开发、测试、生产和部署。它通常比硬件系统运营在一个更快速的环境中,根据技术发展水平每18个月翻一番摩尔定律。无数的研究包括领先的研究Standish Group证明小项目成功交付所需的功能在成本/进度以更高的利率比大的项目。较小的项目执行风险要低得多,因为他们更容易范围、评估、设计、开发和测试。他们需要更少的时间在每一个阶段,减少破坏的机会。项目支持更快的学习和小投资允许后续努力取悦用户增量地交付功能。

更快的交货	交付能力经常几个月,而不是10年需要今天的许多大型it项目交付通过一个瀑布方法。
响应变化	敏捷使程序操作的变化作出反应,技术、预算、威胁,通过小频繁的发布和其他因素。
更高的用户满意度	每个版本和sprint关注最高优先级需求作为由用户,为用户提供频繁的和一致的交付能力,解决他们的需求。
提高软件质量	日常和自动化集成测试,小范围的版本,和常规示威活动尽可能早地识别和处理缺陷在开发过程中减少返工。
增加可见性进展	用户、监管当局和其他利益相关者看到定期进展在实际工作软件副理论纸质会计估计。
风险降低	小范围的努力更容易设计、计划、估算,并执行和减震的变化。此外,小范围的项目有一个较低的“沉没成本”如果他们快速失败,失败。
提高了生产率	在敏捷迭代更多的精力专注于发展中功能规划和报告文档。

虽然实践经验和研究结果强烈表明敏捷的价值对于许多它收购程序,这种方法在所有情况下都是不合适的。项目适合采用敏捷包括那些:

软件密集型	能力可以逐步设计和交付 操作环境能吸收频繁的软件部署和升级 项目的寿命或软件有望短期或需要不断升级 利用企业架构的能力或现有的平台
访问的利益相关者	用户、测试人员,和其他关键利益相关者参与收购整个生命周期 用户可以分享见解的操作环境和提供快速反馈过渡发展 用户被授权代表有优先次序的能力需求和用户验收测试期间提供反馈
不确定的解空间	快速变化的威胁、操作和技术 需求是不固定的,动态的,不断理清思绪
后续的增量	通常第一个增量可能交付基础设施能力或建立的基本平台通过传统开发方法(例如,瀑布) 后续功能可以迭代和独立开发和交付升级现有的能力或现有平台上构建一个小型应用程序

另请参阅如何确定项目适合敏捷GSA技术指南

	传统的	敏捷
心态	定义刚性需求、设计、开发、生产	协作文化迭代交付用户优先级功能
规模和范围	5年的增量	< 6个月发布
需求	前期通过定义大型cdd和合同	通过动态积压迭代定义和优先
合同	刚性、产品基础、长时间、有限的变化	SW Development-as-a-Service通过迭代任务订单
成本估算	详尽的前期分析,严格的基线	迭代的、集成的、协作
测试	长时间后系统开发	自动化、日常、集成在发展

尽管成功的敏捷开发取得了在私营部门,商业实施敏捷并不直接转化为敏捷采纳联邦部门。程序结构障碍、需求和收缩往往源于这些关键差异。政府必须遵守一套严格的政策,法律,法规不适用于商业领域相同的学位。遵循这些规则管理联邦收购通常包括一个官僚,费劲的,缓慢的过程,极大地影响联邦机构实施敏捷。商业部门比政府有不同的利益相关者管理过程。私营企业是负责内部和分层管理结构,通常不高于公司董事会;一些可能的外部利益相关者(如工会)很少引起频繁和严重的影响。利益相关者的政府官僚层在层高度的影响,可以创建频繁和严重的干扰。从政治的改变政府预算削减对一个程序可以发挥重要的外部影响。政府的官僚层很难让敏捷团队在私营部门相同的程度。 The commercial sector has considerable latitude to make adjustments throughout the course of the development because companies closely link accountability, authority, and responsibilities to push decision making to the lowest levels. The government’s tiered management chain of command makes it difficult for the Agile team to be empowered to make timely decisions.

	障碍	推动者
收购过程	长时间的要求,承包、测试评价 丰富的文档和评论 前期充分定义的需求 更改合同是昂贵和费时	使用顶石资源(例如,PEO或组合层次)合同、策略、和人员对小型,快速释放 通过不断理清思绪积压管理需求 获得开发者的服务和产品
文化	程序监督是重要的 不宽容的文化风险 抗裁剪流程、文档和各级评审	实现小,授权团队 拥抱变化——失败早期和快速失败;持续改进 “总是航运”——交付软件是# 1优先级和性能指标
用户参与	活动有直接用户是有限的或不一致 终端用户不可用在整个开发生命周期 需求是构建和执行以串行的方式从操作技术	活跃用户参与和用户演示整个开发过程 高带宽通信;最好是与共处一地的团队 需求排序基于连续操作和技术讨论
程序结构	预先固定范围锁定需求 过度详细的和不切实际的要求预付一笔成本估算 管理与建立基线;挣值管理(维生素)变化是气馁	小,频繁的发布基于连续多么重要需求积压 收购过程主动调整和监管批准高管 作为一个投资组合管理能力与独立的项目
协调	相互竞争的利益相关者优先级 缺乏一个明确的企业架构 协调在个体进行程序层次,增加评论的时间	调整策略、流程和评论在收购一个集成模型和策略 利用对业务和技术集成的企业架构 进行协调的组合或利用过程能力等级/审核效率
经验和培训	有限政府和行业经验与敏捷 缺乏领导理解和支持敏捷 缺乏明确过程使敏捷效率	投资于培训和价值的政府和行业经验 使用教练来指导项目经理和重新定义关键过程 从利益相关者获得审批流程级((副个人程序层次),使评审过程的效率

这些推动者结合GAO报告中推荐的原则在应用敏捷方法有效的实践和联邦的挑战。他们中心敏捷宣言小的主题,频繁的能力释放,一个动态的需求过程,允许连续优先级的需求,从用户社区积极参与整个开发过程,并对基于定时安排交付可工作的软件。一些努力只能成功地实施这些主题和提供有效的软件解决方案的一个子集;然而,有人会说,这不会构成纯粹的敏捷开发。

机构可能受益于定义和标准化基于敏捷实践,以确保环保总署共同构成一个基于敏捷的项目或项目的理解。

今天,许多努力不准确贴上敏捷,导致误解和歪曲的敏捷原则。定义原则后,机构需要提供详细的指导收购社区,描述如何执行敏捷收购流程在其收购的法律法规。

敏捷实践、流程和文化往往背道而驰的历史悠久的国防采购企业。敏捷模型代表一个机构经营方式的变化。程序必须重新思考他们如何配备、组织和管理,以及业务流程,是否治理评论,支持收购的融资模式结构来支持敏捷。成功,敏捷模式取决于各级强有力的承诺收购的过程。敏捷需要专门的政府参与整个过程,为了和集成多个发布版本计划,监督开发周期,管理不断发展的需求、促进合作、获得承诺,活跃,和一致的用户参与。政府必须建立一个强大的团队来管理和补充的敏捷开发承包商。最优结构来培养一个协作环境特性的物理主机代管收购支持团队,由项目的员工,承包商,并支持功能区域。在关闭的情况下的物理距离团队是不切实际或可行,项目可以使用协作工具日常会议,结对编程与利益相关者,和频繁的讨论。

空军的一个主要项目计划办公室,承包商和最终用户都位于7-mile半径。这接近物理距离使得程序的一个集成的敏捷方法的采用。

相信跨越文化权威的决定,开发人员,测试组织,收购方,项目管理,用户对敏捷交付至关重要。近,专用敏捷收购团队促进这个模型,但是它必须进一步增强。领导可以通过授权信号,信任团队成员与决策权显然基于高层沟通策略,需求和愿景收购。类比的军事术语“指挥官的意图”可以澄清这个概念。指挥官的意图是一个简洁的表达一个操作的目的——理想的最终状态的描述和目标的方式促进过渡到未来的业务。它允许改编,一个任务可以继续即使操作没有按计划进行。对于敏捷,整个计划代表了意图。如果这个计划并不像预期的那样工作,团队改变了计划,同时继续关注的目的。这需要团队建立关系,促进信任、协作、透明度和共同责任。GAO的报告在应用敏捷方法有效的实践和联邦的挑战建议四个组织承诺和协作实践敏捷实现:

• 致力于确保所有组件参与项目组织的敏捷方法
• 在高级管理层识别一个敏捷的冠军
• 确保所有团队包括与敏捷教练或员工的经验
• 让小、跨职能的团队

实施这些做法将有助于促进必要的文化变化做出敏捷有效。正如GAO报告中提到的,一些挑战与显著差异在敏捷环境中如何管理项目。前政府尝试敏捷生产混合结果变差,因为政府试图实现敏捷的部分不改变一些潜在的开发环境,工具,流程,和文化,保持面向传统发展战略。而不是简单地遵循敏捷方法的配方和步骤,程序应该尽量采用敏捷的哲学和思想灌输程序灵活性。建立一个组织变革纪律和清晰的愿景可以帮助交流的组织策略采用敏捷的哲学。功能社区支持收购今天经常在筒仓只有弱关系项目办公室。敏捷实践要求补充的商业环境提供的结构、纪律,对敏捷开发实践的支持。对于敏捷成功,环境必须促进跨多个学科的密切合作,支持快速开发周期。一个成功的敏捷框架取决于积极支持从多个利益相关者的社区,包括用户、开发人员、系统工程师、测试和认证人员,以及国防部的领导和监督。项目经理必须参与这些关键利益相关者获得他们的支持和反馈,构建敏捷文化能贯穿整个生命周期的国防部项目。

看到敏捷文化小组(视频)在道OSD专家论坛热门话题,道,SEI, CACI和rca。

敏捷开发要求承包商开发团队和政府项目办公室采用一套新的角色和职责。下面的图显示了一个潜在的敏捷团队建设。敏捷开发的核心是释放团队负责执行。发布团队包括一个核心团队由项目经理,产品所有者,测试人员和系统工程师,开发团队由scrum master (scrum管理员和产品所有者角色特定于scrum方法,团队角色可能会有所不同,如果使用其他敏捷方法)。更广泛的扩展团队包括主要的利益相关者和功能支持活动的代表,包括收购的领导下,收缩,测试,认证和认证(C&A),用户社区,外部系统和组织提供财政支持。

潜在的敏捷团队构建

虽然角色可能基于不同的敏捷方法和水平集成,四个角色发生在几乎所有的敏捷活动。

• 的产品负责人是权威的用户社区代表管理待办事项列表(s)和需求优先级排序,通信运营概念开发团队,并提供持续的反馈对他们的产品开发团队。看到这个角色分析要求额外的细节。产品所有者通常是一个政府雇员从用户组织拥有需求,但是一些程序有一个承包商填补这个角色与政府用户,然后工作。
• 的scrum master促进流程,执行团队的规则,消除障碍,并保持团队专注于任务。scrum管理者通常是一个承包商是开发团队的一员。
• 的发布团队由< 10政府和承包商发布成员紧密合作。
• 的开发团队通常由承包商人员:软件开发人员,包括软件和安全工程师,数据专家、测试人员、质量保证和配置管理器。

在理想情况下,这些参与者都在相同的物理空间中共存。当主机代管不可以实现的,他们应该经常通过电话或亲自见面,并最大化利用协作工具。

而敏捷实践取决于高技能和训练有素的团队成员,一个跨职能团队的导师和专家软件一起工作的团队成员也能成功。项目办公室实现最好的结果当团队至少有一个员工与敏捷或相关专业为其他员工提供在职培训,致力于领先团队通过成功的敏捷实践的采用。

有效的项目团队成员了解他们的角色和职责在敏捷项目和在他们的执行能力有信心。适用的敏捷原则获取必要的人才包括:

• 招聘人员和敏捷、精益和相关专业知识加入这个项目的团队。项目经理应该在项目一级组织(例如,PEO级别),应该提倡分享这些关键技能的资产。
• 引进专家在敏捷、精益和相关的方法作为敏捷教练和项目办公室员工进行在职培训。这些专家可以通过指导项目办公室做出宝贵的贡献来确定和提高角色、流程和技术,采用同时解决任何问题。敏捷教练帮助所有项目参与者一起下一组通用的实践和指导方针。

管理敏捷开发的需要转变传统模式的指导项目从上到下一个信任和授权团队决策和协作解决方案。程序必须运行在政府信任和合作的方式,承包商和开发团队。这可能需要政府完善或重新定义现有的角色和考虑新的角色特定的敏捷。下表确定推荐敏捷团队成员的角色和职责。

推荐的角色和职责

角色	责任
项目经理	管理需求、资金和收购过程,同时监督每个版本的规划和高级项目增量。
产品负责人	管理需求、权衡和协作之间的收购和用户社区。
Scrum Master	便于开发人员,因为他们执行他们的流程,屏蔽干扰的团队。执行开发团队规则和保持团队专注于任务。通常管理sprint backlog。
开发人员	开发软件,包括软件开发人员、数据库管理员和架构师、测试人员,和其他技术专家。
最终用户	传达作战概念和要求/需求,参与连续测试活动,并提供反馈开发能力。
企业架构师	创建架构和设计以迭代的方式,以确保设计以控制方式演进的版本。
独立测试人员(s)	验证的功能产生了对终端用户的优先考虑的需要,设计规范和标准。
系统工程师	管理发布,监督系统实现、运营管理和过渡,并集成了所有工程子学科和专业组织成一个团队努力创建一个结构化的开发过程。
合同管理人员	管理征集、奖项和敏捷开发合同的执行,并促进政府和承包商人员之间的沟通。
合同管理人员的代表(心脏)	作为一个代表签订合同人员。心脏没有权限更改合同或授权新工作;然而,软木是确保供应商执行的关键技术工作符合合同。
成本估计	跟踪和管理整个项目预算;提供低保真成本估算程序层次的高层增量,紧随其后的是详细的成本估算之前每个版本的发展。

关键问题来验证敏捷团队/角色:

• 主要利益相关者明确定义的角色和职责吗?
• 有一个明确的所有者的需求积压?
• 有一个明确的政府积分器(例如,项目经理和/或系统工程师)坐标和集概要(如计划、指标)和可交付成果(例如,代码)?
• 有一个清晰的程序的所有者(或更广泛的企业)架构?
• 有一个清晰的、早期的承诺用户代表和更广泛的用户群?
• 用户共存,或者在靠近项目办公室和/或承包商吗?
• 做用户的频率(面对面、电话、职业训练局)会见PMO和开发人员吗?
• 是产品所有者授权用户社区的代表吗?
• 并努力积极参与协作、跨职能的社区的利益相关者?
• 团队规模小到足以有效地采用敏捷原则?
• 是团队的数量每大小可控,风险、复杂性,需要和集成?
• 有体系、scrum-of-scrums或相关的跨团队的整合作用?
• 批准机关已经委托给足够低的水平,使快速决策?
• 团队包括政府代表和开发人员吗?
• 敏捷团队成员有足够的经验,训练,和/或教练?
• 外部利益相关者理解和支持他们的角色在敏捷环境?

参见:

• 角色在敏捷交付团队纪律由Scott Ambler
• 在敏捷团队角色,Ambysoft
• 敏捷回顾:让优秀团队卓越Esther Derby,戴安娜拉森
• 42 Scrum Master的任务,敏捷
• 扩展敏捷

敏捷开发通常涉及多个团队致力于单个程序。例如,一个团队可以被分配一个版本与一个或多个其他团队并行开发开发其他版本。这需要积极协调整个团队的努力,以确保他们正在朝着一个共同的解决方案。添加开发团队可以更快地交付更多的软件,但有风险增加协调、整合和管理这些发展和团队。有各种各样的方法结构维环境。

下一个图显示多个开发团队(所有承包商)每个致力于自己的版本。每个团队将定期会面的scrum master(如每周)与政府人员。这种方法可能会限制政府,特别是产品负责人,参与开发团队,但使开发团队能够专注于其任务以最小的干扰。

多个开发团队的例子

下图强调多个释放团队的政府和承包商人员,与政府和承包商代表每个团队定期通过scrum-of-scrums合作。这些代表可以PM和scrum master。单个产品所有者可以支持所有发布团队和scrum-of-scrums努力。团队成员可以定期与合作类似的角色在其他球队在进步,设计,依赖,问题,和资源。这种方法集中在一个集成的政府承包商发布团队,但可能是更多的资源密集型。

多个发布团队的例子

参见:

• 扩展敏捷

GAO的报告在应用敏捷方法有效的实践和联邦的挑战概述:

10采用敏捷开发的最佳实践

1. 从敏捷指导和敏捷采纳的策略
2. 提高迁移到敏捷概念使用敏捷术语,如用户故事(用于传达需求),和敏捷的例子,比如演示如何编写用户故事
3. 不断提高在项目层面和组织层面采用敏捷开发
4. 识别、解决企业和项目层面的障碍
5. 经常获得利益相关者/客户反馈
6. 让小、跨职能的团队
7. 包括需求相关的安全与进度监控您的队列的未完成工作(待定)
8. 获得信任通过展示在每个迭代结束时的值
9. 使用工具和指标跟踪进度
10. 每天跟踪进度并明显

14采用敏捷的挑战

1. 团队合作有困难
2. 采购做法可能不支持敏捷项目
3. 团队很难过渡到自主工作
4. 客户不相信迭代解决方案
5. 员工很难承诺更及时、频繁的输入
6. 团队管理迭代需求有困难
7. 机构提交员工困难
8. 合规审查很难在一个迭代的时间框架内执行
9. 及时采用新工具是困难的
10. 联邦报告实践与敏捷不相符
11. 技术环境是很难建立和维护
12. 传统的工件评论与敏捷不相符
13. 敏捷指导还不清楚
14. 传统的状态跟踪不结合敏捷

来源:GAO报告12 - 681在应用敏捷方法有效的实践和联邦的挑战

873秒。。试点项目使用敏捷和迭代开发方法裁缝主要软件密集型作战系统和国防业务系统。

(一)试点Program. -

(1)一般。日期后30天——晚于本条例的颁布,国防部长,会商的秘书军事部门和军队的首领,应建立一个试点计划调整和简化软件开发主要软件密集型作战系统的要求及方法和国防业务系统。

(2)试点项目的实施计划。——后来颁布的日期后120天内,国防部长,会商的秘书军事部门和军队的首领,应当制定计划来实现所需的试点项目在本节,包括指导实现程序和选择系统参与这个项目。

(3)选择系统试点PROGRAM. -

(一)实施计划要求系统应选择如下:

(i)为主要软件密集型作战系统,一个系统每武装部队和一个国防充分系统,包括至少一个主要国防采办程序或主要自动化信息系统。

(2)国防业务系统,不少于两个系统和不大于8系统。

(B)在选择系统参与,秘书应当优先考虑系统如下:

(我)主要软件密集型作战系统,系统-

(我)已经确定了软件开发是一个高风险;

(2)经历了成本增长和进度延误;和

(3)没有提供任何在之前历年作战能力。

(2)国防业务系统,系统-

(我)经历了成本增长和进度延误;

(2)没有提供任何在之前历年作战能力;和

(3)表现不佳的其他系统在国防业务系统组合相似的用户需求。

和别人约好(b)调整-

(1)一般。——后60天内选择一个系统试点项目下分段(a)(3),秘书应当制定重整计划系统通过分解成更小的增量使用敏捷和迭代开发方法。调整计划应包括修订成本估计低于成本估计为系统当前日期本条例的实施。

(2)调整执行。每盘重新系统的增量-

(一)旨在提供一个真正有用的功能后在第一个180天内调整;

(B)是旨在提供后续有意义有用功能的时间少于180天;

(C)将多学科团队专注于软件生产,优先考虑用户需求和总体拥有成本的控制;

(D)是配备高素质的技术训练有素的工作人员和人员管理和业务流程在领导职位专业知识支持需求修改,收购策略,和项目决策;

(E)的收购战略确保重新系统广泛足以允许服务的建议,系统,修改业务实践中,人员的配置,或实现的策略组合;

(F)包括定期参与用户社区,以及表示用户社区的项目管理和软件生产活动;

(G)的收购战略确保重新系统支持基于需求定义和功能作为服务,包括技术评估标准的建立,结果被用来与供应商的服务水平协议谈判;和

(H)考虑选择终止与任何供应商的关系不能或不愿提供满足本部分的要求的条款。

(c)的系统。——部长可能会删除系统选择试点项目下分段(a)(3)只有在秘书提交委员会的军事参议院和众议院书面测定表明所选系统已经成功降低成本或进度增长,或不满足整体需求的试点项目。

(d)教育和培训在敏捷和迭代开发Methods. -

(1)培训需求。——秘书应确保任何人员的有关组织的军事部门和国防机构参与试点项目,包括组织负责工程、预算、承包、测试和评估、需求验证、认证认可、接受有针对性的培训在敏捷和迭代开发方法中,包括临时课程所需的891条款的行为。

(2)支持。——实施试点项目分段(a)下,秘书人员应确保参与项目提供反馈通知的发展教育和培训课程根据第891节。

(e)日落。——试点项目要求分段(a)终止于9月30日,2023年。任何系统选择下分段(a)(3)的试点计划后应继续通过其重组计划的执行。

定义(f)敏捷和迭代开发。在本节中,“敏捷和迭代开发”这个词,对软件-

(1)意味着收购根据提供多种方法,快速、增量功能用户操作使用,评估和反馈不仅仅与任何单一、专有的方法或过程;和

(2)涉及-

(A)的增量开发和部署能力,通常被称为“螺旋”,“旋转”,或“冲刺”,在几个星期或几个月可以测量;和

(B)持续参与和协作用户,测试员,要求当局。

(一)一般。日期后30天——晚于本条例的颁布,国防部长应当确定不少于4和8软件开发活动在国防部或军事部门在收购一个试点项目使用敏捷开发方法。

(b)的过程。软件开发活动下确定分段(a)应选择试点和发达没有合并下列合同或交易的要求:

(1)挣值管理(维生素)或EVM-like报告。

(2)集成的总体计划的发展。

(3)综合总体规划的发展。

(4)开发的技术需求文档。

(5)开发的系统需求文档。

(6)使用的信息技术基础设施库协议。

(7)使用软件开发生命周期(方法)。

(c)角色和Responsibilities. -

(1)一般。二十三活动应当包括下列角色和职责:

(A)的项目经理授权的所有决策方案在总体活动目标,包括资源,资金,人员,并终止合同或交易建议。

(B)的产品负责人,直接向项目经理报告,负责产品的整体设计,路线图元素的优先级和解释他们的验收标准,以及优先级列表的所有功能所需的产品。

(C)一个工程主管,直接向项目经理报告,负责软件的实现和操作。

(D)设计领导,直接向项目经理报告,负责识别、沟通,可视化用户需要通过一个以人为中心的设计过程。

(2)资格。——秘书应当建立资格人员填充段落中描述的位置(1)之前,他们的选择。资格可能不包括积极的教育需求,必须根据专业技术或交付软件产品的经验,包括敏捷概念。

(3)协调计划,测试和认证机构。——项目经理应确保资源的可用性测试和认证的组织支持迭代开发流程。

(d)的计划。——国防部长应当制定计划为每个选定试点项目下活动。该计划应当包括下列要素:

(1)产品愿景的定义,识别一个简洁、明确需要软件将地址。

(2)定义的产品路线图,列出一个noncontractual计划,确定短期和长期的产品目标和具体的技术解决方案,以帮助满足这些目标和适应任务和用户需求产品所有者的自由裁量权。

(3)使用一个公告,其他事务管理局或其他快速以业绩为基础的征集过程。

(4)识别和持续参与,最终用户。

(5)频繁和迭代最终用户验证的功能和可用性原则一致的数字服务剧本中概述美国数字服务。

(6)商业最佳实践的使用先进的计算机系统,包括在适用情况下-

(一)自动化测试、集成和部署;

(B)遵守适用的商业可访问性标准;

(C)功能支持现代版本的多个普通web浏览器;

(D)能力跨最终用户常用的设备,包括移动设备;和

(E)内置应用程序监视。

(e)计划时间表。——秘书应确保每个选定的活动包括

(1)奖之后不超过三个月的过程进行需求确认;

(2)计划频繁和迭代最终用户验证实现的功能和可用性;

(3)交付功能原型或最小可行产品在3个月内从奖或更少;和

(4)后续交付迭代的开发周期不超过4周,包括安全测试和配置管理是适用的。

(f)监管指标。————秘书应确保所选择的活动

(1)使用现代追踪工具来执行需求积压跟踪;和

(2)使用敏捷开发指标,至少,跟踪-

(一)工作成就的步伐;

(B)的完整性测试活动的范围(如代码覆盖率、容错和边界测试);

(C)产品质量属性(主要和次要的缺陷和措施等关键性能和质量属性);

(D)交付进度相对于当前产品路线图;和

为每一次迭代(E)目标。

(g) Restrictions. -

(1)资金的使用。-不基金供选择的活动可能花费的评估或评估使用源代码行代码的方法。

(2)合同类型。——国防部长可能不会使用承包方法可接受最低价格或成本加成合同执行特定的活动在这一节中,并鼓励使用现有的简化和灵活的合同安排。

汇报(h) -

(1)软件开发活动COMMENCEMENT. -

(一)一般。——晚于30天前开始试点项目下的软件开发活动下分段(a),应当向国会提交国防部长委员会报告的活动(在本节称为“试点活动”)。

(B)的元素。——报告试点活动下这段应当载明的描述试点活动,包括以下信息:

(我)试点的目的的活动。

(2)试点活动的持续时间。

(3)效率和收益预期获得政府试点项目。

(2)软件开发活动COMPLETION. -

(一)一般。——后的60天内完成后一个试点活动,应当向国会提交国防部长委员会飞行员报告活动。

(B)的元素。——报告试点活动在这一段应包括以下要素:

(我)的试点活动结果的描述。

(2)等立法或行政行为的建议部长认为适当的试验活动。

(我)定义。——这部分:

(1)敏捷的收购。——收购“敏捷”一词意味着收购使用敏捷和迭代开发。

(2)敏捷和迭代开发。——“敏捷和迭代开发”一词,对软件-

(一)意味着收购根据提供多种方法,快速、增量功能用户操作使用,评估和反馈不仅仅与任何单一、专有的方法或过程;和

(B)包括-

(我)的增量开发和部署能力,通常被称为“螺旋”,“旋转”,或“冲刺”,在几个星期或几个月可以测量;和

(2)连续参与和协作用户,测试员,要求当局。