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

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

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

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

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

创建一个合适的敏捷项目代表一个基本结构的第一步为程序层次采用敏捷开发的策略。这个活动要求项目作出重大调整,传统的多迪5000.02程序结构和收购过程,支持敏捷开发时间表和目标。的多迪5000.02收购政策重点强调了裁剪收购模型来满足项目的需要。弗兰克•肯德尔国防副部长负责收购,技术,物流(l)中概述2012年国防l文章“最优程序结构”:

“…每个程序是结构化的方式优化程序的成功的机会。没有一个解决方案。我寻找根本的证据是程序的领导人已经仔细考虑所有的因素(技术、风险、集成、其他)。”

尽管这个指导,程序通常不知道如何有效地调整程序接收过程所有者的批准。需要多年的经验真正理解所涉及的细微差别裁剪收购计划。

在一个核心主题多迪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两端,因此发展成为一个持续的过程。每半年回顾与高层领导和其他关键利益相关者确保透明度到程序的进展,计划,和问题。项目提供额外的洞察力通过月度或季度报告和其他高管会议状态。

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

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

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

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

规划

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

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

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

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

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

敏捷项目规划的大型企业

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

测试环境规划

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

自动化计划

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

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

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

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

敏捷测试象限

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

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

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

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

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

额外的测试和评估参考

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

  视频

  • 敏捷测试,谷歌智能
  • 敏捷测试的最佳实践Excella咨询
  • 测试驱动开发概述,ScrumStudy