软件开发架构-使用敏捷方法进行项目开发并不是什么新鲜事？

使用敏捷方法进行项目开发并不是什么新鲜事。在本文中，我们将讨论系统的架构设计如何适应敏捷开发。

使用敏捷方法进行项目开发并不是什么新鲜事。然而，在敏捷项目中不需要设计系统架构的想法是很常见的。剩下的问题是：系统的架构设计如何适应敏捷开发？

许多人会争辩说，在敏捷开发场景中软件开发架构，停下来思考架构是没有用的，因为它会随着时间的推移而不可避免地发生变化。我们同意这个陈述的第二部分，架构会在项目期间发生变化，项目时间越长，最初定义的架构发生变化的可能性就越大。

对架构规划的许多看法以及对这一活动的理解是官僚主义的，甚至常常是项目进度的瓶颈，其根源在于使用软件开发的预测方法进行软件开发的经验。

下面的部分提供了预测和自适应方法之间的比较。

预测方法

每次我们谈论传统软件开发时，我们通常都在谈论预测性软件开发过程。这些方法中最常见的是著名的瀑布。

在这种类型的过程中，有明确定义的阶段：

要求- 了解所有系统要求。它应该执行的功能、体积（静态和动态）、集成以及任何其他功能性或非功能性需求。

项目- 在这个阶段，系统设计发生。正是在这里，它定义了系统将如何与外部世界交互、它的数据模型是什么、将使用的技术、它的类/程序、关联和交互。正是在这个阶段定义了系统架构。

实施——在这里，在设计阶段定义的系统的具体化发生。基本上，该项目是编码和单元测试的。

验证- 系统以集成方式进行测试并得到用户的认可。

维护——在生产中经过测试、批准和安装后，系统进入维护阶段。

正如我们所看到的，在预测方法中，系统解决方案是在过程开始时给出的。每个系统项目都是根据一开始就感知到的需求信息而制定的。

此外，该架构旨在预先满足所有系统要求，通常无需动手测试来验证在此阶段做出的架构决策。在实施阶段出现与设计阶段相关的问题并不少见，例如所选技术之间的不兼容和/或未能满足要求。

发生这种情况时，有必要回到上一阶段并更改项目。由于项目是为整个系统设计的，因此更改它通常是一项费力的任务（例如更改所有文档以纠正设计错误），从而在时间和成本方面对系统开发产生影响。

这种方法的另一个问题是在其开发过程中没有审查系统需求。开发周期越长，当系统最终投入生产时，导致其构建的业务需求发生显着变化的机会就越大。

下图举例说明了这一点。时间在项目早期瞄准一个目标（感知需求）。但随着时间的推移，这些需求会发生变化，系统最终会在最终发布到生产环境时错过目标：

自适应方法

“产品开发团队正面临一场悄无声息的革命，工程师和管理人员都在努力调整。在一个又一个行业——制药、软件、汽车、集成电路——客户对持续创新的需求和不断下降的实验成本正在发出巨大的转变从预期到适应的发展方式。”

以上摘录由 Jim Highsmith 于 2009 年在他的《敏捷项目管理》一书中发表。对于那些不认识他的人来说，Jim Highsmith 是敏捷宣言的签署者之一，正是他在 1999 年提出了 ASD——自适应软件开发。他专注于团队的协作和自组织，以开发复杂的系统。

这里的自适应一词用于描述系统是否适应其周围环境的变化。即：“响应变化而不是遵循计划”，如敏捷宣言中所述。

敏捷开发有多种方法。这些方法将系统/产品的开发分解为小的增量/迭代。此中断允许您减少实施前所需的规划和设计数量。就像随着时间的推移我们有几个瀑布循环。

在每个周期结束时，都会向利益相关者展示一个功能性产品。这允许评估正在构建的内容并验证在每个周期中更改/调整系统目标/要求的需要。

每次迭代都涉及一个跨职能团队，负责规划、分析、设计、编码、单元和验收测试。目标是让产品在每次迭代结束时发布到生产环境中。随着产品在生产中进行测试，其设计或施工场所的缺陷会尽快被发现。这使我们有机会调整系统/产品并纠正其路线/方向。

下图正好说明了这一点。在每次发布/迭代（灰色圆圈）软件开发架构，产品发布到生产中，对系统必须满足的需求的感知发生变化，重新制定系统规划，纠正其路线以达到新目标（之后感知的需求）释放前一个增量）。

敏捷架构

以SAFe中存在的敏捷架构的定义：

“敏捷架构本质上是一组价值、实践和协作，积极支持系统的设计和进化架构。这种方法采用 DevOps 思维方式，允许系统的架构随着时间的推移不断演进，同时它支持满足当今用户的需求。它避免了与启动-停止-启动性质相关的开销和延迟，以及相位门和大前期设计 (BUFD) 流程中固有的大规模重新设计。

敏捷架构通过协作、紧急设计、有意架构和设计简单性来支持敏捷开发实践。除了敏捷开发实践，敏捷架构还支持可测试性、实现和发布的设计。领域和去中心化创新。”

从这个定义中，出现了两个非常重要的术语，包括新兴设计和意向建筑。

紧急设计是分析和扩展架构的过程，足以实现和验证开发周期中的下一个增量。

意向性架构是要看到大局。大公司需要通过大规模的架构计划同时应对新的业务挑战。在大范围内，我们可以理解，为了实现业务目标，将涉及多个团队、产品和系统。在这种情况下，Emergent Design 是不够的，因为它被限制在一个团队中。如果没有意图架构，我们可能会遇到一些问题，例如难以集成、验证和维护非功能系统需求的实现、低重用性、解决方案冗余等。

有意的架构将为团队提供一个共同的目标/目标，从而使工作的一致性和独立团队的工作并行化。换句话说，它将成为指导轨道，团队工作之间的粘合剂。

敏捷架构就是要平衡这两种力量。如果过分强调新兴设计，我们最终会遇到难以集成的组件、较差的软件质量以及上述所有其他问题。如果你走相反的道路，也就是说，如果我们开始夸大未来架构组件的详细程度，它可能会成为一个瓶颈，并大大减慢你的团队开发速度。

深入来说，敏捷架构是关于设计/选择系统的结构组件和标准，使其能够在构建过程中响应感知需求（功能和非功能需求）的变化。

要实现这一点，请避免大的前期设计，但要清楚地说明您的最终状态。所需要的最终状态会随着时间而改变，但没关系。其次，尽快尝试您的系统。确保每个版本都提供生产就绪的系统。它将允许您测试和检查您的系统是否真正交付价值，并且您将能够尽快识别任何失败（在需求或设计中）并进行所需的更改。

结论

敏捷架构是在自适应软件开发方法中设计架构的方式。它允许体系结构随着每个系统的增量而发展，避免了 BUDF - Bid Up Front Design。

参考

海史密斯吉姆罗伯特 (2009-07-09)。敏捷项目管理（敏捷软件开发系列）