1 敏捷的应用
本文件旨在应用于使用敏捷方式和方法的组织和软件项目，以及使用其他正式工程方法的组织和软件项目。敏捷开发是软件开发（包括软件维护）最广泛使用的方法之一，因为人们认为它更经济实惠，并能更快地交付可用的产品。在大型软件开发工作以及较小的项目中，许多敏捷方法可与各种生命周期模型一起使用，并且可以在生命周期的不同点使用不同的方法。本附件指出了对本文件中适用于常用敏捷技术的流程要求的解释。
正如 5.4.2 中讨论的，敏捷项目中使用的生命周期模型通常具有高度增量和演进性。但是，使用敏捷方法的组织会应用本文档中确定的生命周期流程， 包括组织、 技术管理和技术流程（并且可能按照协议流程 1运作）。 如 5.4.1 中所述，本文档未规定生命周期模型内任何特定的流程顺序。 流程顺序由项目目标和生命周期模型的选择决定。 由于敏捷项目在创建或改进工作软件的同时会转换或组合活动， 因此它可能会发现声称完全符合结果（4.2.1）比完全符合活动和任务（4.2.2）更为合适。
敏捷开发的成功部分归功于软件的本质，即在软件构建时适应设计的灵活性。在敏捷实践中，软件设计、实施（构建）和持续集成经常同时执行。这种实践与一种正式的自上而下的可追溯性 2方法形成对比，在这种方法中，构建只有在设计得到批准后才能开始，因此构建的软件可以追溯到之前批准的详细设计。因此，敏捷项目充分利用了本文档中的方法，其中过程同时发生，与按顺序分阶段（理想化的瀑布）项目形成对比。
在敏捷项目中，概念探索、开发、构建、测试、过渡和退役先前的软件可以在连续的迭代中同时进行。敏捷项目通常与上面提到的活动同时执行重新规划。在这样的方法中，使用内部快速阶段作为管理检查点或控制并不是很有用。其他敏捷方法在指定的迭代（例如，冲刺或预定义的时间盒节奏）之间的点执行重新规划， 以便每个迭代都可以被视为一个阶段。
敏捷项目可以将开发和软件发布周期紧密结合起来（例如，按每日、每周、每月安排发布），或者可以将开发迭代的完成与软件发布计划的管理分开，以根据组织战略 3方便客户。
除了应用高度迭代和演进的生命周期模型外，敏捷组织还针对项目规划和项目评估与控制流程制定了具体实践。敏捷项目通常在时间限制周期结束时设立非正式检查点或回顾性评审，以商定下一周期的改进措施，而不是在阶段或流程之间的过渡期设立主要控制点。每次迭代都包括设计、开发和测试操作。迭代（测试驱动开发）。经过大约一到四周或更长时间的一个迭代后，新的可运行软件元素被接受为“完成” 已完全开发、检验（测试）和确认。确定了经验教训 4和流程改进，并开始下一个迭代的工作。通过启动每次迭代的计划会议和每次迭代结束时举行的回顾会议，可以促进持续学习、风险管理和流程改进。
敏捷方法强调利益相关者需求和要求定义过程 5，通过持续的高程度利益相关者参与来促进变革。在敏捷项目中，关键利益相关者（如收购方或用户代表）不仅仅是信息、测量和评估报告的批准者。持续的利益相关者参与与本文档一致，该文件确定了利益相关者的参与他们参与每个技术过程以及定制过程（附件 A）。他们密切参与需求管理（6.4.3.3.d）的迭代，通过引入新的需求和优先级变化，并参与从未开发的故事或功能中选择优先需求并进一步细化以进行开发。迭代方法鼓励灵活地添加、重新确定优先级或推迟 127
被认可为属于项目一般范围的需求。另外，利益相关者 6参与迭代中已测试软件的批准意味着验证在整个项目中是持续进行的。
随着不断发展的需求的增量定义，敏捷项目中的项目范围概念与通过预定的指定需求基线 7来定义范围的项目有所不同。当敏捷项目需要定义的产品时，其范围最初与高级或基本需求相关。随着在整个构建过程中获得的额外知识，预计会出现更详细的产品定义级别。没有预定义产品（例如，工作量维护级别）的敏捷工作可以通过时间限制的时间表或资源有限的团队来控制范围。这种方法尤其适用于软件维护工作，其中最初并未完全指定纠正或自适应工作的范围或内容。
与更传统的开发工作相比，敏捷开发项目的基线规范在程度和时间上也有所不同。需求基线最初可能包括高级用户故事 8（“史诗”）和关键绩效测量，包括可用性标准。敏捷项目充分利用“在生命周期中定义基线”（6.3.5.3.b）4）的任务。在开发过程中，至少每天根据 c 商定和构建新的基线。软件元素通常可追溯到高级功能需求，并可紧密追溯到它所实现的用例和用于验证其功能和性能的测试用例。新的软件元素不能追溯到以前批准的、有基线的设计文档，而只能简单地追溯到事实上在软件构建过程中创建并仅置于配置控制之下的设计元素或对象。
在敏捷项目期间，规范、设计工件和信息项或文档的准备通常受到限制，而软件开发人员则利用他们的时间和技能将场景或功能叙述（“用户故事”）转化为可工作、可测试的软件元素。团队不是准备详细的评审 9包以进行不频繁的主要里程碑评审，而是频繁与利益相关者会面，以呈现完成一组功能的非正式证据并就下一次迭代的内容达成一致。
记录的信息项重点关注过渡、操作和维护所需的内容，例如操作员和最终用户文档以及带有测试计划和测试用例的已测试和发布软件版本的基线。项目重复使用组织程序进行配置和发布管理、验证以及事件和问题管理。在可能的情况下，通过集成的自动化系统和程序进行需求管理、架构和设计、配置管理、测量和信息管理，可以启用和执行双向可追溯性。
敏捷开发的增量和迭代特性可促进高效的技术和管理流程，并实践存储以降低与变更相关的成本。相比之下，在连续体瀑布末端管理的项目寻求通过最小化变更次数、限制控制点数量以及确定在整个项目中进行审查和跟踪的详细规范基准来降低总返工成本。
针对复杂系统的敏捷项目试图通过优先考虑最重要的功能以便尽早实现来管理成本。如果一个组织将其整个软件系统组合的开发和维护作为单一系统进行管理，通过支出率而不是总支出进行管理，那么该组织原则上可以将此系统组合作为持续的敏捷开发进行管理，类似于管理高度迭代的“看板”维护工作。