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

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

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

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

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

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

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

尽管成功的敏捷开发取得了在私营部门,商业实施敏捷并不直接转化为敏捷采纳联邦部门。程序结构障碍、需求和收缩往往源于这些关键差异。政府必须遵守一套严格的政策,法律,法规不适用于商业领域相同的学位。遵循这些规则管理联邦收购通常包括一个官僚,费劲的,缓慢的过程,极大地影响联邦机构实施敏捷。商业部门比政府有不同的利益相关者管理过程。私营企业是负责内部和分层管理结构,通常不高于公司董事会;一些可能的外部利益相关者(如工会)很少引起频繁和严重的影响。利益相关者的政府官僚层在层高度的影响,可以创建频繁和严重的干扰。从政治的改变政府预算削减对一个程序可以发挥重要的外部影响。政府的官僚层很难让敏捷团队在私营部门相同的程度。 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的报告,几个挑战与显著差异在敏捷环境中如何管理项目。前政府尝试敏捷生产混合结果变差,因为政府试图实现敏捷的部分不改变一些潜在的开发环境,工具,流程,和文化,保持面向传统发展战略。而不是简单地遵循敏捷方法的配方和步骤,程序应该尽量采用敏捷的哲学和思想灌输程序灵活性。建立一个组织变革纪律和清晰的愿景可以帮助交流的组织策略采用敏捷的哲学。功能社区支持收购今天经常在筒仓只有弱关系项目办公室。敏捷实践要求补充的商业环境提供的结构、纪律,对敏捷开发实践的支持。对于敏捷成功,环境必须促进跨多个学科的密切合作,支持快速开发周期。一个成功的敏捷框架取决于积极支持从多个利益相关者的社区,包括用户、开发人员、系统工程师、测试和认证人员,以及国防部的领导和监督。项目经理必须参与这些关键利益相关者获得他们的支持和反馈,构建敏捷文化能贯穿整个生命周期的国防部项目。

敏捷开发要求承包商开发团队和政府项目办公室采用一套新的角色和职责。下面的图显示了一个潜在的敏捷团队建设。敏捷开发的核心是释放团队负责执行。发布团队包括一个核心团队由项目经理,产品所有者,测试人员和系统工程师,开发团队由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努力。团队成员可以定期与合作类似的角色在其他球队在进步,设计,依赖,问题,和资源。这种方法集中在一个集成的政府承包商发布团队,但可能是更多的资源密集型。

多个发布团队的例子

参见:

• 扩展敏捷