下面的图显示了一个潜在的结构六个月发布,由五个冲刺。每个sprint穿过整个开发生命周期来展示每个月月底工作软件。

产品所有者负责确保有效的发布执行。释放的方式必须由软件完成的可能性在增加各种螺旋在一起,形成一个功能,不能仅仅是证明,但释放到操作。

敏捷的类比:

当夏尔巴人指导登山者,夏尔巴人经常收集关于环境的信息,信息能力的登山者,所取得的进展,以及可用的供应。他们使用这些信息来确定最好的攀岩路线和沿途的营地。当这个类比用于讨论发布执行,团队是所有环境平衡的输入来确定最好的前进道路在使用发布会议营地停下来评估他们的目标,进步,能量水平,并承诺总体攀升。

一些传统的规划方法分解工作的组件,而中心发布执行计划的能力。这意味着即使半道上释放,程序可以交付能力而不是部分开发的组件。释放特别有用,因为它们不仅要求软件开发冲刺完成,但生成操作有用的功能。说另一种方式,释放是有用的在测量和确保交付最终用户的操作效用。瀑布式方法下,需求不动态改变在开发过程中,从而增加的风险提供过时的技术或功能,不再为最终用户的需求。版本的另一个好处是,他们还把集成作为一个持续的活动,而不是大爆炸集成工作结束时释放,可以和资源密集型的。

常规项目待办事项列表是主要的机制来评估进展并做出调整,以应对来自客户的反馈,开发人员和用户。这种梳理活动旨在保持发展吞吐量在正确的水平,产生互补的特性,可以为用户的利益走到一起时,发布部署。

定期梳理的发行版计划安排中

• 产品所有者和利益相关者整合反馈从早期冲刺,操作注意事项,技术风险,和其他因素,以确保用户故事是清晰和优先顺序。
• 开发团队验证估计“故事点”或相关措施还需要多少时间来完成每个用户故事。
• 产品所有者与scrum管理者和项目经理确认仍在释放足够的时间来完成项目的发行版计划安排,并相应地调整工作范围。

定期梳理项目的计划安排

• 产品所有者和利益相关者关注高优先级用户故事计划下一个版本(年代)。
• 产品所有者和scrum master确保故事是清晰和优先。
• 产品所有者和股东定期重温优先级。
• 从所有利益相关者群体开发团队整合输入:用户、测试人员、工程师、架构师、网络安全等。

“最终可能证明意味着只要有证明的东西。”- - - - - -利昂·托洛茨基

在开发过程中,团队可以实现决策创建一个解决方案,并满足需要在短期内,但不是最好的长期解决方案。最终,将实现更好的长期解决方案,但直到解决方案是开发团队积累所谓的“技术债务。“例如,旧标准的实现,因为新的一个还不成熟,或者还没有充分理解。技术债务是承认一个老标准实施但需要和重构迁移到新标准在可预见的未来。从软件环境,更少的关键特性的“存根”或释放代码之前被完全记录技术债务的是另一个例子。重要的是团队,包括产品所有者,认识到当一个设计或实现决策带来技术债务。团队必须选择提供一个短期解决方案在额外的费用,多余的发展“偿还债务,实现更好的长期解决方案,如下图中总结。

技术债务应该仔细理解,跟踪和传达到所有利益相关者。同样重要的是确定项目积累了“太多”技术债务和长期解决方案的团队需要优先发展在其他近期的新功能或“创可贴”修复。

额外的参考:技术债务的逃离黑洞,敏捷教练。

技术债务象限(来源:MartinFowler.com)

配置管理活动和相关工具是至关重要的在一个程序中使用敏捷软件方法——他们可以使或打破这个项目的成功。敏捷方法增加了麻烦,更多的版本,更多的冲刺,每一个sprint必须在一个管理工具。测试可能进行了前一个sprint在开发人员检查接下来的冲刺能力。配置管理跟踪用户故事的接受与他们在sprint执行和验证效果提供了可追溯性的工具软件交付到用户需要的产品待办事项列表。持续集成工具的集成套件可以帮助促进与提高自动化的配置管理和测试功能。配置管理还包括相关文档的跟踪和工件。确保这些包括是很重要的。

额外的引用:

• 配置管理,国防采购指南
• 配置管理收购社区连接

敏捷开发技术资料管理包括获取、更新,并确保任何技术数据的完整性需要支持这个项目。在一个程序中使用敏捷软件方法,这些任务也在待办事项列表中标识用户故事和优先。不断地将任务分解成越来越小的碎片使敏捷困难,如何在完成小任务应该在一个sprint吗?

例如,在一个名义收购程序,需要天气数据,用户描述可能包括从源获取数据,保持数据本地存储,管理更新数据,确定适当的录制数据,备份数据,等。一种启发式对许多开发团队是有任务在一个sprint在一天内可以实现的。许多这些任务正在进行,所以它是具有挑战性的定义工作范围,可以合理地完成在一个sprint。

沟通是敏捷的成功并购的关键。团队应该确保透明度上下链所以用户知道正在期待和问题时,和最资深的领导知道已经做了什么,会做什么,以及如何在地里干活。

额外的参考:技术资料管理,国防采购指南

实现

实现在敏捷环境中使用频繁的每月(或每两周)完成sprint周期,而不是一个漫长的发展时期。这些较小的子集的功能帮助利益相关者看到进步,和分配程序的不同方面的责任较小的团队帮助移动逐步发展的。实现的诸多好处之一短喷意味着如果航向修正是必要的,它可以更快地适应开发过程的一部分。结果,程序少浪费精力在一个错误的方法。取消工作在短跑整个敏捷项目的影响远比传统项目,地方课程修正要复杂得多。日常交流(通过站立会议)提供了一种常规的方式来识别问题很早就和采取纠正措施尽快确定一个问题。这个团队之间的沟通是敏捷方法的关键特性之一。

集成

一些系统存在于真空。一体化必然使得更多的利益相关者参与其中,从而增加复杂性。集成涉及将冲刺释放纳入当前部署软件,在开发相关软件,或者大型企业。政府项目办公室,开发承包商,用户社区,测试人员必须认真管理。

系统工程师增加了责任在敏捷的环境中,是整合成功的关键原因之一。系统工程师需要知道集成状态和sprint的时机与其它系统的集成块。

看到扩展敏捷额外的信息集成。

敏捷带来的差异时,文档测试以及整个项目的策略。敏捷测试文档应该建立在敏捷原则,促进集体责任的感觉,持续改进和专注于最终产品。从和敏捷的观点来看,传统的测试文档可以被认为是非常严厉的,往往难以维护,未使用的。由于敏捷项目迭代和增加在冲刺,需求范围小得多,它允许一个“轻”的方法来测试文档。这个打火机的方法是从一开始用一个包罗万象的计划或战略发布的通用测试方法,列出了解决方案。这种策略通常可以最多一两页。该战略应该由整个团队达成共识的方法将提供最高的产品质量。sprint和版本的测试计划反映了高水平的策略,已经批准的需求计划,专注于特定的sprint /释放。再次,光方法预计计划明确关注记录只需要团队执行计划。大量的文本中包含传统的计划——比如背景——忽略重点测试类型/方法,时间表和可追溯性的sprint /释放用户故事/需求。 Typical planning documents commonly used in agile projects include:

• 测试策略描述产品如何通常是测试
• 每个sprint测试计划
• 包含测试用例测试规格/库存
• 测试思想探索性测试和日志,注意结果
• 清单为常规测试区域

因为敏捷测试自动化程度高,尤其是在部件和单元的层面上,很大一部分传统的测试文档应该在一个工具。

在传统的开发项目,我们致力于一组需求之前开始发展。基本的“承诺”的项目办公室提供满足需求的产品。敏捷开发的一个基本概念包括持续的需求细化的原则与规范在sprint设计期间产生。这要求项目办公室试图将初始需求保持在最高水平的抽象是可以接受的,然后执行一些跟踪验证要求,针对特定的螺旋和释放。这种杂化方法在许多项目是必要的。

也看到数字服务剧本:自动化测试和部署