历史上，敏捷软件工程流程在2001年随着《敏捷宣言》的发布而引起人们的关注（Beck等人，2001年），这引发了许多方法论，如Scrum和极限编程。但是，这些方法论的采用以及如何将其应用于非软件工程（Carson，2013）往往侧重于与软件相关的具体实践，而不是基本框架。相比之下，1991年的一项跨行业研究（Nagel，1992）观察 [^guancha]到，技术和其部署环境正在以越来越快的速度共同进化，超过了大多数有组织的人类努力的适应能力。因此，敏捷性作为一种系统特征被识别出来，并随后进行了研究，以确定领域无关的度量标准、架构和设计原则（Dove，2001）。

敏捷性是系统和流程所展现的一种能力，使它们能够在不可预测、不确定和变化的条件下保持有效运行。敏捷SE过程的价值主张是风险管理 [^ruanjianxuqiuyufengxianguanli]，当开发速度和客户满意度可能受到系统开发过程中不断演变的需求理解的影响时，这种管理是适当的。

需求演变的常见原因包括初始理解不足、开发过程中揭示的新理解以及部署环境知识的演变。如果忽视，需求演变会降低或消除客户满意度。如果不加以缓解，需求演变会导致返工和废弃工作，这是时间和成本超支的主要来源。

一个敏捷的系统架构在基础设施和模块化设计上会产生费用，这应该与需求演化的概率成本进行权衡。这是风险管理。敏捷SE过程的目的是降低与适应有益需求演化相关的技术、成本和进度风险。

敏捷性是指有效应对意外事件的能力——无论是好的还是坏的。实践和技术的选择应与项目的性质（Carson，2013；Sillitto，2013）以及它们将被应用的文化环境相兼容并产生协同效应。

敏捷SE框架

敏捷SE（Forsberg等人，2005年）总结如下：

• 利用敏捷架构进行SE（流程），可预测地重新配置目标、需求、计划和资产。
• 利用敏捷SE（产品）架构，能够在开发和制造过程中可预测地对产品（系统）进行更改。
• 利用一个赋予权力的、深度参与的“产品所有者”（首席系统工程师、客户或等同负责产品愿景的权威），使广泛层面的系统思维能够随着需求理解的演变，为实时决策提供信息。
• 利用影响工程、制造和客户满意度的人类生产力因素，这些因素在不可预测和不确定的环境中发挥作用。

敏捷度量框架

敏捷性措施主要由架构在开发过程和产品中实现和限制：

• 响应时间，以理解响应必要性的时间和完成响应的时间来衡量
• 响应成本，既包括完成响应的成本，也包括因响应而在其他地方产生的成本
• 响应能力的可预测性，通过架构准备情况的事前测量和响应时间和成本估计的可重复准确性的事后确认来衡量
• 应对能力的范围，事先在架构准备中测量全面应对能力，并在事后通过可重复的广泛应对适应性证据进行确认。

敏捷架构框架

敏捷SE和敏捷系统工程是两件不同的事情（Haberfellner和de Weck，2005），它们共享一个共同的架构，使每个部分都具有灵活性（Dove，2012）。从简单的意义上来说，这个架构将被识别为一种拖放式即插即用的松散耦合模块化，其中一些关键方面通常不会在一般模块化架构的概念中被提及。

架构中有三个关键要素：一个拖放封装模块的清单，一个被动的最小但足够的规则和标准的基础设施，这些规则和标准能够支持和限制即插即用操作，以及一个积极的基础设施，该基础设施指定特定的责任以维持敏捷的操作能力：

• 模块——模块是自包含的封装单元，具有符合即插即用被动基础设施的明确定义的接口。它们可以被拖放到响应能力系统中，与其他模块的关系由被动基础设施决定。模块被封装，因此其接口符合被动基础设施，但其功能方法不依赖于其他模块的功能方法，除非被动基础设施规定。

• 被动基础设施——被动基础设施提供模块之间的拖放连接。它的价值在于隔离封装的模块，以最小化意外的副作用，并快速实现新的操作功能。选择被动基础设施元素是在必需的多样性和简洁性之间取得关键平衡——标准和规则足够多以促进模块连接，但又不至于过多地限制创新的系统配置。

• 活跃的基础设施——一个敏捷系统不是在固定事件中设计和部署后就置之不理的东西。敏捷性在新系统配置根据新需求进行组装时最为活跃——这可能非常频繁，甚至在某些情况下每天都会发生。为了在需要时启用新配置，需要四个责任：可用模块的集合必须不断发展以满足所需，可用的模块必须始终处于可部署状态，新配置的组装必须完成，并且当新配置需要新的标准和规则时，被动基础设施和活跃基础设施都必须发展。这些四个活动的责任必须被指定并嵌入到系统中，以确保在不可预测的时间内能够实现有效的响应能力。

模块组合——谁（或哪个过程）负责确保新模块被及时添加到名单中，以及现有模块得到升级以满足响应需求？

模块准备情况——谁（或什么流程）负责确保在不可预测的时间有足够的模块准备好部署？

系统组装——当新情况需要不同的能力时，谁（或什么过程）会组装新的系统配置？

基础设施演进——谁（或什么过程）负责在新的规则和标准被预期并变得合适时，演进被动和主动的基础设施？

敏捷架构设计原则

本节简要列举了十个可重用、可重构、可扩展的设计原则：

可重用原则如下：

• 封装模块——模块是独立的、可分离的、松散耦合的、独立的单元，它们协同工作以实现共同的目标。
• 促进接口（插件兼容性）——模块共享明确的交互和接口标准，并且可以轻松地插入或从系统配置中移除。
• 促进重用——模块可重复使用和复制，并提供支持以查找和使用适当的模块。

可重构原则如下：

• 对等交互——模块之间以对等关系直接通信；并且更倾向于并行而非顺序的关系。
• 分布式控制和信息——模块由目标而非方法指导；决策在知识最充分的地方做出，信息在当地关联并在全球可访问。
• 延迟承诺——需求可能会迅速变化并持续发展。将工作活动、响应组装和响应部署延迟到最后一刻，可以避免可能妨碍后续有效响应的昂贵浪费。
• 自组织——模块关系在可能的情况下是自我确定的，模块交互是自我调整或自我协商的。

可扩展原则如下：

• 演进的标准——被动基础设施标准化了模块间的通信和交互，定义了模块的兼容性，并通过指定的责任来维护当前和新兴的相关性。
• 冗余和多样性——重复的模块提供了容量调整选项和软故障容忍度，而采用不同方法的相似模块之间的多样性可以被利用。
• 弹性容量——模块可以组合成响应式组件，以在当前架构内增加或减少功能容量。

::: {#author name=reddish}
本文同步发表在 软件需求探索的https://srs.pub/specification/agile-systems-engineering.html

作者: reddish@srs.pub
:::

[^guancha]: 商业分析中的五十种分析方法和技巧之31-观察. https://srs.pub/babok/guancha.html
[^ruanjianxuqiuyufengxianguanli]: 软件需求与风险管理. https://srs.pub/theory/ruan-jian-xu-qiu-yu-feng-xian-guan-li.html