拓展阅读

敏捷软件开发

迭代增量开发是迭代设计（或迭代方法）和增量构建模型相结合的一种开发方式。

这一术语最早起源于软件开发，长期以来，迭代和增量这两个术语在大型开发项目中被广泛推荐结合使用。

例如，1985年的DOD-STD-2167标准（第4.1.2节）提到：“在软件开发过程中，可能会同时进行多个软件开发周期的迭代。”并且“这一过程可以描述为‘进化式采纳’或‘增量构建’方法。”

在软件开发中，迭代与增量之间的关系由整体的软件开发过程决定。

概述

敏捷项目管理中典型迭代周期的简化版

这种方法的基本理念是通过重复的周期（迭代）和每次开发小部分（增量）来开发系统，使得软件开发人员能够利用在开发系统的早期部分或版本中学到的经验。学习来自于系统的开发和使用，其中过程的关键步骤通常从软件需求子集的简单实现开始，并通过迭代不断增强版本，直到实现完整的系统。在每个迭代中，都会进行设计修改并增加新的功能。

该过程本身包括初始化步骤、迭代步骤和项目控制清单。初始化步骤创建系统的基础版本。初始实现的目标是创建一个用户可以互动的产品。它应该涵盖问题的关键方面，并提供一个足够简单、易于理解和实施的解决方案。为了指导迭代过程，创建一个项目控制清单，其中记录了需要执行的所有任务。它包括需要实现的新功能和现有解决方案的重新设计领域。随着分析阶段的进行，控制清单会不断被修订。

迭代包括重新设计和实现，其目的是简单、直接且模块化，支持在该阶段进行重新设计或作为未来任务添加到项目控制清单中。

设计的详细程度并不是由迭代方法所决定的。在轻量级迭代项目中，代码可能是系统文档的主要来源；然而，在关键的迭代项目中，可能会使用正式的《软件设计文档》。

迭代的分析基于用户反馈和可用的程序分析工具。它涉及对结构、模块化、可用性、可靠性、效率和目标实现的分析。根据分析结果，项目控制清单会进行修改。

阶段

增量开发将系统功能划分为增量（部分）。

在每个增量中，通过跨学科的工作交付一部分功能，从需求到部署。统一过程将增量/迭代分为以下几个阶段：启动、详细设计、构建和过渡。

启动：在高层次上识别项目范围、需求（功能性和非功能性）以及风险，但足够详细以便可以估算工作量。
详细设计：交付一个工作架构，旨在减轻最重要的风险，并满足非功能性需求。
构建：逐步完善架构，生成可投入生产的代码，这些代码来自于对功能需求的分析、设计、实现和测试。
过渡：将系统交付到生产操作环境中。

每个阶段可能会被划分为一个或多个迭代，通常是以时间为单位进行限定，而不是以功能为单位。

架构师和分析师会比开发人员和测试人员提前进行一个迭代的工作，以确保他们的工作产品积压保持充足。

使用和历史

在Craig Larman和Victor Basili的文章《迭代与增量开发：简短的历史》中提供了许多早期使用的例子，其中最早的一个例子是NASA 1960年代的“水星计划”（Project Mercury）。

其中一些“水星计划”的工程师后来在IBM成立了一个新部门，其中“另一个早期且显著的重大IID成功案例是NASA航天飞机软件的核心——主要的航空电子软件系统，该系统由他们在1977到1980年间开发完成。团队在31个月的时间内，分17个迭代进行开发，每个迭代平均持续约8周。

他们避免采用瀑布生命周期的动机是，航天飞机项目的需求在软件开发过程中发生了变化。”

一些组织，如美国国防部（DoD），偏好迭代方法论，最早始于MIL-STD-498，该标准“明确鼓励进化式采纳和迭代增量开发”。

2000年发布的《DoD指令5000.2》明确表示了对IID的偏好：

“有两种方法可实现完全能力：进化式方法和单步（瀑布）方法。优先选择进化式方法……在这种方法中，交付给用户的最终能力被分为两个或更多的模块，每个模块提供逐步增加的能力……软件开发应遵循迭代螺旋开发过程，其中持续扩展的软件版本基于早期开发的经验教训。也可以分阶段进行。”

DoDI 5000.02的最近修订版本不再提及“螺旋开发”，但确实倡导这种总体方法作为软件密集型开发/采购项目的基准。

此外，美国国际开发署（USAID）也采用迭代和增量开发方法，来设计、监控、评估、学习和调整国际发展项目，其项目管理方法聚焦于协作、学习和调整策略，以便迭代和调整编程。

与瀑布开发的对比

主条目：瀑布开发

软件开发项目失败的主要原因之一是模型的选择，因此选择时需要非常小心。[模糊][7]

例如，瀑布开发范式要求在进入下一个阶段之前，完成每个学科的项目工作成果。

业务价值通常是在项目结束时一次性交付的，而在迭代方法中则可以进行回溯。对比这两种方法后，出现了一些模式差异：

用户参与：在瀑布模型中，用户只参与模型的两个阶段，即需求阶段和验收测试阶段，可能还包括用户教育材料的创建。而在增量模型中，客户会参与每个阶段。
可变性：软件只有在生命周期的构建阶段完成后才交付给用户进行验收测试。而在增量模型中，每个增量都会交付给用户，并且在用户批准后，开发者才能进入下一个模块。
人力资源：与瀑布模型相比，增量模型所需的人员通常较少。
时间限制：在瀑布模型中，操作产品需要几个月才能交付，而在增量模型中，产品通常在几周内交付给用户。
项目规模：瀑布模型不适用于小型项目，而增量模型适用于小型和大型项目。

实施指南

驱动软件实施和分析的指南包括：[需要引用]

设计、编码和测试修改的任何困难 应该提示需要重新设计或重新编码。
修改应易于融入到独立且易于查找的模块中。如果不能，则可能需要进行某些重新设计。
对表格的修改应特别容易。如果任何表格修改不能快速且轻松完成，则表示需要重新设计。
随着迭代的进行，修改应变得更容易。如果没有，这表明存在基本问题，如设计缺陷或修补程序的泛滥。
修补程序通常只应存在一个或两个迭代周期。修补程序可能在实施阶段避免重新设计时是必要的。
应经常分析现有实现，以评估其与项目目标的符合程度。
应在有条件时使用程序分析工具，帮助分析部分实现。
应征求并分析用户反馈，寻找当前实现中存在的缺陷迹象。

在硬件和嵌入式系统中的应用

虽然“迭代与增量开发”这一术语最初起源于软件行业，但许多硬件和嵌入式软件开发也正在采用迭代和增量技术。

这一转变可以在多个行业中看到。最近受到这一思想转变显著影响的一个领域是航天发射行业，尤其是由私人公司参与航天发射带来的更快速和更广泛的技术创新，带来了显著的竞争压力。

像SpaceX[8]和Rocket Lab[9]这样的公司，已经在过去十年里提供商业轨道发射服务，而在十年前，只有六个国家能够做到这一点[10]。

新的技术创新方法、定价和服务提供方式，包括自2016年以来能够使用曾经飞行过的（可重复使用）火箭级别飞向太空的能力，进一步降低了进入太空的成本[11][8]。

SpaceX明确表示其努力将迭代设计实践引入航天行业，并在航天器、发射车辆、电子和航空电子设备及运营飞行硬件操作中应用这一技术[12]。

随着行业的变化，其他航天发射竞争者也开始与政府机构一起改变其长期开发实践。

例如，美国大型发射服务提供商联合发射联盟（ULA）自2015年起开始了一项为期十年的项目，旨在重组其发射业务——通过采用迭代增量的方法，将两种发射载具减少为一种，并计划在接下来的十年里构建一个部分可重复使用且成本更低的发射系统[13]。

参考资料

https://zh.wikipedia.org/wiki/%E6%95%8F%E6%8D%B7%E8%BD%AF%E4%BB%B6%E5%BC%80%E5%8F%91

拓展阅读
敏捷软件开发
概述
在硬件和嵌入式系统中的应用
参考资料

Devops-wiki-开发模型-03-迭代增量开发（Iterative and incremental development）