收购战略概述了所需的能力,获得方法,项目时间表,裁剪、风险管理、业务/收缩战略,维护策略,成本估算,资金、组织结构和人员配备,以及其他法定和监管要求的信息。

“一个成功的收购战略成为一个故事到人,目标,和途径。像一个好故事,它需要集中在一个共同的主题,它在一起。最好的方法使这一主题一致认识到,虽然需要一个团队编写的收购策略,最后,讲故事的是点;策略讲述了越好,就越容易理解。”——约翰•穆勒

一个核心敏捷原则是价值全面的文档的工作软件。在政策和法律要求大量的信息从国防部收购计划,国防部也有足够的指导调整文档生成方面的项目。大多数法律规定所需的信息在一个较高的水平,而政策、指南和模板需要提供不同级别的细节信息。国防采办管理人员继续与国会和国防部删除低价值的文档尽可能和简化或裁缝文档流程。

在这个阶段,收购策略主要集中于名义程序结构和时间表,需求管理,核心系统工程过程,以及如何构建一个更成熟的技术基线,原型功能,发展初步的和负担得起的设计,以及鼓励竞争。战略整合应该敏捷原则和方法概述在这个模型中,包括功能流程是如何根据支持小,频繁的发布;一个集成的、授权的政府承包商敏捷团队和文化;以及项目计划,定期向用户交付能力和应对变化。

程序可以各种方式结构的文档,应该在过程的早期讨论他们的建议的方法与他们的指挥系统。规模、复杂性、紧迫性的需要,ACAT水平,和MDA将关键因素在塑造的文档结构。下面列出的三种方法。

• 一些主要的文件——大多数信息合并到3 - 5主要文档(例如,获取和维护策略,成本估算/分析、系统工程和测试)。这种方法限制所需的文档协作和可以帮助设置预期数量限制的内容。随着信息量的增加,那么的协调和监督组织。
• 更多,更小的文件通过收购标准文档模板结构信息,建立了评论家。这需要协调多个文档但避免审批延误,这可能导致一个有缺陷的文档可以防止批准重大不相关的文档。这些文件可以在进一步的细节,随后的里程碑。
• 顶石文档附件——制定收购顶点文档,系统工程,测试策略在一个包罗万象的计划或投资组合层面,使小范围释放快速浏览过程。一旦一个项目开始开发,每个版本可能包括一个小的计划和/或附件几个关键文档大纲的细节的限制范围或偏离顶点文档。这个项目应该请求MDA委托审批的小附件版本下属主管/经理。

在敏捷环境中,规划是一个持续的过程在整个项目的生命周期和提高分辨率和信心近期事件详细列出。每个版本的细节和sprint概述了在计划阶段。敏捷团队定期反映了其策略和方法和调整更有效。获取所有项目需求的难度,可能会出现在未来,PMO面临挑战记录所有的收购,在综合系统工程,测试和维护策略文件之前已经开始发展。敏捷文化和环境认识到这一点;他们强调必要的细节来完成的直接下一步规划未来活动和接受较低的分辨率。

在项目早期阶段应该在减少风险活动涉及多个供应商。一些早期的敏捷用户有多个供应商的开发风险减少释放,地址或一个关键特性原型计划功能。这些努力提供宝贵的实践经验,帮助政府人员(收购方和用户)理解关键过程,角色和可交付成果参与各种敏捷实践受雇于供应商。他们帮助识别技术和规划风险,加强成本和进度的估计,提供洞察潜在供应商的专业知识开发完整的系统,并给出了供应商了解项目需求,作战和技术环境。政府可以利用该方法获得的信息在此阶段收购战略如何最好的结构形状和执行程序连同合同激励策略和其他RFP的细节。

成功的敏捷采纳需要调整政府和工业流程和集成的角色和职责。敏捷需要一个真正的伙伴关系,比传统的政府承包商关系更紧密耦合。

程序应该调整收购策略捕捉敏捷实践被采纳。应该加强核心敏捷原则的迭代计划的每一个版本和sprint回顾会议结束时每个识别改进的机会。战略应该让小团队反复开发版本/优先待办事项列表中的待办项,同时积极合作和通知关键的利益相关者的进展和问题。

项目办公室确定人员来填补关键政府角色和凝固的文化需要拥抱一个更动态的方法来开发功能。项目经理应该清楚地了解收购和业务主管的期望,包括决策当局报告、策略、资源和问题解决流程。

而敏捷价值观工作软件计划文档,项目利益相关者必须定期检查和调整自己的策略和方法在整个生命周期。政府和行业利益相关者应该每次发布后进行回顾,讨论了什么,哪些方面需要改进。程序应该更新文档以反映有序的方法来管理需求、变化,技术基线、用户活动,和承包商的激励等。

构建一个IT项目敏捷开发完全不同于结构化程序在传统的开发方法。传统的收购程序通常有离散采集阶段的里程碑事件提供一个大的能力。敏捷是更具活力,需要支持多个程序结构,小版本的能力。考虑到激进的敏捷和传统的发展模式之间的差异,程序通常认为这个活动太复杂,因此没有考虑敏捷开发过程作为一个选项。

创建一个合适的敏捷项目代表一个基本结构的第一步为程序层次采用敏捷开发的策略。这个活动要求项目作出重大调整,传统的多迪5000.02程序结构和收购过程,支持敏捷开发时间表和目标。虽然多迪5000.02收购政策重点强调了裁剪收购模型来满足项目的需要,程序通常不知道如何有效地这样做为了接收过程所有者的批准。需要多年的经验真正理解所涉及的细微差别裁剪收购计划。

在一个核心主题多迪5000.02是程序结构的裁剪和收购过程满足个人的需求计划。政策包括几个收购模型来考虑,比如defense-unique软件模型2,模型3增量部署软件和混合模型从多迪5000.02 B软件主导项目。这个定制的模型提供了额外的细节和支持指导每个活动在每个阶段。最佳实践敏捷收购包括结构化程序:

• 强调这类基于结果的一种方法
• 考虑整个收购收购战略生命周期
• 确保合同支持频繁交付能力,承包商的表现可见性,连续测试,和问责结果

程序必须以这样一种方式设计,满足所有的多迪5000.02法律和监管要求,也可执行和市场收购高管谁可能不熟悉敏捷过程的细节。以下部分描述的推荐方法构建敏捷国防部计划,从流程结构敏捷版本和构建这一概念的基础上,开发出的一个完全定制的国防部敏捷采办计划。

当开发敏捷项目的结构,PMO应该首先决定如何构建它的版本。释放代表程序的核心元素结构,引导程序的频率提供最终用户的能力。每个版本的长度取决于经营,收购,技术因素与利益相关者应该讨论在用户和组织收购。作为一般准则,大多数版本应该少于18个月,6个月的目标(如倡导的我们的首席信息官,高,FITARA)。更短的发布周期有几个好处,最重要的是,程序部署有用的能力最终用户更快。

也更短的发布周期降低或者减少数量的变化可以成为需求压抑或复合管道,早些时候和更频繁的反馈机会,短时间将纠正措施。涉及测试社区早期实际上菲尔丁小版本的功能还允许收购社区更好地理解测试社区的敏感性,有助于减少潜在的冲突和争论下游。然而,项目办公室也应该平衡释放时间和运营社区的能力吸收的频率发布和部署能力。这常常需要处理功能领导重新设计关键收购流程大约6 - 12月版本而不是5 - 10年的增量。一次选择承包商(s),释放时间可以完成。

每一个版本由多个sprint和最后一段释放测试和认证。每个sprint,反过来,包括规划、设计、开发、集成和测试,并在示范的功能给用户和其他利益相关者。开发团队进行这些活动多的工作单元(用户故事)在一个sprint。测试由开发人员和政府严重自动化。开发团队向用户演示功能和测试人员在每个sprint。开发人员可能需要交付临时代码后,政府在每个sprint或多个sprint。政府或集成承包商可以临时代码集成到其软件环境进一步测试和操作评估。下面的图显示了一个潜在的每6个月发行的结构有五个月冲刺。

名义上六个月释放结构

下一个图显示了一个潜在的12个月释放结构和七个六周冲刺。程序必须调整sprint的长度和释放条件保证。关键是要建立一致的,定时发布,最好是小和频繁的迭代开发,以便响应容易变化。在敏捷,计划保持不变,而释放的范围和sprint是动态的。

名义上12个月释放结构

确定发布策略后,每个努力都应该调整其编程和收购过程有效地支持敏捷开发实践。下图演示了一个潜在的顶层结构。在这种方法中,需求、技术和体系结构发展是持续不断的过程,而不是顺序的步骤在早期收购阶段。每个版本涉及一系列冲刺迭代开发和测试能力,最终导致功能向用户交付每6个月批准。而不是边界通过一系列的增量发展里程碑B和C两端,因此发展成为一个持续的过程。每半年回顾与高层领导和其他关键利益相关者确保透明度到程序的进展,计划,和问题。项目提供额外的洞察力通过月度或季度报告和其他高管会议状态。

潜在的专门程序结构和流程

测试在敏捷项目中不同于测试在传统的收购。而不是构成离散产品生命周期的最后阶段,它是连续的和不可或缺的敏捷方法。关键差异是成功的关键包括:

• 敏捷团队连续测试。在迭代、增量开发环境,连续测试是唯一的方式,以确保新功能集成和完整。
• 测试员是嵌入到开发团队,开发团队定期周期编码和测试。测试成为开发过程的基础。
• 自动化是敏捷开发团队的一个关键特性。由于短周期/ sprint,自动化测试执行的能力成为关键。成功的敏捷开发是没有自动化测试不可行。
• 要求代码测试自动化开发功能影响代码的设计和架构,这样更容易测试。
• 测试文档以及项目文档控制到最少。这样就避免了时间和精力参与创建大量的可交付文档不需要或相关。
• 敏捷的迭代和增量自然需要快速反馈测试。还有其他各种各样的测试和反馈目前自动化技术包括单位,验收,安全,质量,性能,和负载。它是至关重要的,以确保团队的技能装备在不同自动化测试/反馈机制。
• 敏捷测试是累积的。新代码测试,之前它还必须通过所有的测试。这减少了返修。
• 开发人员和产品所有者之间的协作是成功的敏捷测试的关键因素。测试团队必须对开发人员和执行自动化测试与产品所有者定义和工作质量的期望。

测试生命周期和敏捷测试周期涉及相同的活动或阶段,虽然有显著差异的阶段计划,执行和交付。迭代开发包括骑自行车通过一组步骤或活动如启动、计划、设计、开发、测试和发布。的一个最基本的差异在敏捷项目中测试是广泛使用的自动化和测试的软件单元和组件的水平。

敏捷测试矩阵,敏捷扩展框架

产品质量对于创建一个敏捷团队,不是测试,负责整个团队在测试驱动开发(TDD)和验收测试驱动开发(ATTD)。理解测试的差异和期望在敏捷项目实现预期的项目和产品质量是至关重要的。

规划

政府/承包商敏捷团队应该为发布和sprint进行详细的测试计划。该计划提供了一个整体的系统级/跨功能测试,确保测试环境,工具,和其他资源需要每个团队的sprint规划的范围之外。正常sprint计划只覆盖一个或两个冲刺前为大型企业系统是不够用敏捷技术建造的。当规划系统测试环境,包括原型硬件(这可能需要长时间才能交付)或其他设备,安装和配置的硬件是至关重要的。

Sprint /版本测试计划必须确定:

• 应该测试什么,为什么?(根据冲刺的目标/释放,将测试和其他一些地区除外)。
• 项目将在哪里测试?哪些测试环境将用于哪些类型的测试?
• 负责测试的不同部分的产品?
• 什么时候可以不同的测试活动以及产品的不同部分被测试吗?
• 该产品将如何测试?需要什么样的测试方法,方法,技术,工具和测试数据是必要的吗?
• 依赖和其他组件之间的关系、第三方产品、技术、等,项目有哪些?
• 哪些方面最和最少的风险吗?战略反映了产品的风险吗?
• 多少时间是可用的,以及需要执行策略?
• 什么是“完成”的定义”sprint /释放吗?

由于自动化敏捷测试的一个关键方面,规划自动化是至关重要的。敏捷技术如TDD和持续集成依赖于强大的自动化测试的计划。在单元/组件广泛的自动化发展水平以及自动化测试与构建和集成支持敏捷项目的快速交付高质量的代码。如下图所示,敏捷测试金字塔,由麦克科恩在他的书中成功和敏捷,展示了角色在敏捷测试的自动化,反映了单位/组件级别测试的广泛使用敏捷项目。

敏捷测试框架(来源:Mike Cohn)

敏捷项目规划的大型企业

政府必须考虑到额外的考虑在规划大型企业项目。通常情况下,大型项目要求更多的测试协调集成活动,甚至测试协调员等额外角色,这取决于项目的范围。以适应企业大规模系统和联邦政府系统测试需求,敏捷模型必须被修改,以适应大规模集成在系统层面上,专门的安全测试和系统级的性能测试。此外,标准和法规测试,scrum的scrum,硬化,必须定义稳定冲刺。看到大规模的扩展部分测试项目在特定测试考虑的额外信息。

测试环境规划

环境规划为企业敏捷项目涉及许多相同的问题,传统的环境规划:需要构建预期所有类型的测试环境和测试数据,必须创建的必要性,从生产、或模拟。如果环境中有多个用户,协调的努力也是一个考虑因素。最后的敏捷项目测试环境必须支持自动化的单元测试和组件测试的必要性,并可能为测试驱动的开发和持续集成。理想情况下,测试环境配置生产尽可能匹配。如果使用DevOps基础设施管理自动化,同一infrastructure-as-code脚本应该用于测试环境管理。

自动化计划

敏捷测试自动化是至关重要的。迭代开发意味着承包商构建能力有点,这意味着当构建可以打破东西,进而需要一个检查来确定其他功能仍然有效。这意味着自动化测试成为中心,不断开发和发布的代码。多层自动化程序单元,组件,中间层,前端——对敏捷项目至关重要。在测试驱动开发,这是一个常见的敏捷方法,开发团队预先定义了测试标准,生产测试脚本开发任何代码之前满足这些标准。

一个自动化框架能够支持多层测试方法是至关重要的。这个框架,从单位级别的自动化测试和通过其他开发活动前进,应该促进重用和测试使用一个共同的平台和工具,以确保一个有效的测试策略。

测试驱动的开发和持续集成都是技术大量使用敏捷项目促进广泛使用的单元和组件级别的自动化测试脚本。根据敏捷测试金字塔大部分应该写自动化测试在单元/组件测试级别,最好是使用测试驱动开发。这些测试,用相同的语言编写的脚本源代码,成为与每个入住执行回归测试的基础,构建持续集成和部署。测试在金字塔的第二层是那些评估业务逻辑,同时还不需要一个图形用户界面(GUI)。因为GUI测试需要更多的维护他们应该保持到最低限度,主要是用于验证用户界面,而不是测试业务逻辑。

开发一个完整的敏捷软件测试策略需要考虑的所有类型的测试系统的可行性以及具体的测试必须是自动的。敏捷的象限图(资料来源:Lisa Crispin)展示了一个好方法对测试团队使用他们在考虑测试和自动化测试策略。图表显示了光谱的测试,可以/应该做在迭代交付高质量的软件环境。呼唤自动化与人工自然的活动有助于团队清楚地看到在每个象限自动化应该扮演的角色。测试团队必须知道何时使用象限和如何实现它们。

敏捷测试象限

象限是指南使用期间释放和迭代计划,这样整个团队开始考虑测试:如何计划和所需的资源执行它。相关的数字象限没有具体意义或秩序;他们只是指定每个象限的一种方式。在考虑他们的测试策略,尤其是在自动化、项目有几个选择。

• 许多项目从第二季度开始测试,因为这是你得到的例子变成规范和测试驱动代码,以及原型等。
• 其他人可能从高风险区域,比如性能测试建模(第四季度)因为这是最重要的标准特性。
• 如果需求是不确定的,第三季度探索性测试将是一个可行的选择。
• 第三和第四季度测试需要编写一些代码和部署,但大多数团队快速遍历象限,在增量工作。

设计/开发,测试技术,方法,注意事项

需要提供可见性和快速敏捷项目状态更新对产品质量提示利用一系列更广泛的测试技术和方法比传统的瀑布式项目。研究表明,从许多不同的角度测试和技术有更高的概率暴露的缺陷和问题。当敏捷项目的设计和开发测试,程序应考虑从列表中选择一个广泛的技术集合下面增加尽快找到缺陷的机会。

• 成对测试:对测试人员与企业主/开发人员,一个控制按键,另提供建议输入或场景,记笔记等。
• 探索性测试:包括同步学习、测试设计、测试执行。
• 增量测试:开始以最小的细节和构建可用的更多信息。
• 检查表驱动测试:提供快速开发/设计标准的测试活动。
• 基于场景的测试:基地用户业务场景的测试设计。
• 自动生成测试数据:使用自动创建测试数据生成生产资料(如数据没有相关的许多问题。
• 频繁的回归测试内置的自动构建和检查序列代码:每个改变组件上执行自动化回归测试作为构建过程的一部分。

额外的测试和评估参考

• 敏捷测试和评估史蒂夫·哈钦森博士
• 左移位由史蒂夫•哈钦森博士国防l杂志
• 敏捷测试策略Scott Ambler和同事
• 采访Lisa Crispin:完整团队质量,A1QA
• 敏捷测试:测试人员与敏捷团队的实践指南Lisa Crispin和珍妮特·格雷戈里
• 更敏捷测试:整个团队学习旅程Lisa Crispin和珍妮特·格雷戈里
• 十大每个敏捷测试人员都应该读的书
• 敏捷测试下载Bob盖伦

视频

• 敏捷测试,谷歌智能
• 自动化测试和部署、数字服务剧本
• 敏捷测试的最佳实践Excella咨询
• 测试驱动开发概述,ScrumStudy