敏捷架构--它是什么？

使用敏捷方法进行项目开发并不新鲜。然而，人们很容易联想到这样的想法：在敏捷项目中，不需要设计系统的架构。现在的问题是。系统的架构设计将如何适应敏捷开发？

很多人会认为，在敏捷开发的情况下，停下来思考架构是没有用的，这样它就不可避免地会随着时间的推移而改变。我们同意这个说法的第二部分，架构在项目中会发生变化，项目时间越长，最初定义的架构发生变化的概率就越大。

很多人对架构规划的看法，以及把这项活动理解为官僚主义的东西，甚至经常是项目进展的瓶颈，都是源于使用预测性软件开发方法的软件开发经验。

下面的章节对预测性方法和适应性方法进行了比较。

预测性/适应性方法的特点和区别

预测性方法

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

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

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

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

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

验证--系统以综合方式进行测试，并由用户批准。

维护--经过测试、批准并安装到生产中后，系统进入维护阶段。

我们可以看到，在预测性方法中，系统解决方案在流程的开始就已经给出。每一个系统项目都是基于开始时感知到的需求信息而制定的。

此外，架构的设计是为了满足所有的系统需求，往往没有实践测试来验证这一阶段的架构决策。在实施阶段出现与设计阶段有关的问题是很常见的，比如所选技术之间的不兼容和/或不能满足要求。

当这种情况发生时，有必要回到上一阶段并改变项目。由于项目是为整个系统设计的，改变它通常是一项高难度的工作（例如，改变所有的文件以纠正设计错误），在系统开发的时间和成本方面造成影响。

这种方法的另一个问题是，系统需求在其开发过程中没有被审查。开发周期越长，当系统最终投入生产时，引起系统建设的业务需求发生重大改变的可能性就越大。

下面的图说明了这一点。时间在项目的早期就瞄准了一个目标（感知的需求）。但这些需求随着时间的推移而改变，当系统最终投入生产时，它最终没有达到这个目标。

适应性方法

"产品开发团队正面临着一场静悄悄的革命，工程师和管理人员都在努力调整。在一个又一个的行业中--制药、软件、汽车、集成电路--客户对持续创新的需求和实验成本的急剧下降都预示着开发方式将从预测性转向适应性"。

上面的摘录是吉姆-海史密斯（Jim Highsmith）于2009年发表在他的《敏捷项目管理》一书中。对于那些不了解他的人来说，Jim Highsmith是敏捷宣言的签署者之一，正是他在1999年提出了ASD--自适应软件开发。他把赌注押在复杂系统开发的团队协作和自我组织上。

这里的适应性一词是用来描述系统将适应其周围环境的变化。就是说。敏捷宣言中提出的 "应对变化而不是遵循计划"。

有几种敏捷开发的方法。这些方法将一个系统/产品的开发分成小的增量/迭代。这种打破允许你减少实施前所需的规划和设计。这就像我们在一段时间内有几个瀑布周期。

在每个周期结束时，会向利益相关者展示一个功能性产品。这样就可以评估正在建造的东西，并验证在每个周期中是否需要改变/调整系统的目标/要求。

每个迭代涉及到一个跨职能的团队，将处理规划、分析、设计、编码、单元和验收测试。目标是在每个迭代结束时有一个可以发布到生产的产品。随着产品尽快在生产中进行测试，设计或构建产品的商业前提的缺陷会被尽快发现。这使我们有机会调整系统/产品，纠正其路线/方向。

下图正是例证了这一点。在每一次发布/迭代（灰色圆圈）中，产品发布到生产中，对系统必须满足的需求的认识发生了变化，对系统的规划被重新制定，纠正其路线以达到新的目标（在上一个增量发布后认识到的需求）。

敏捷架构

以SAFe中对敏捷架构的定义为例。

"敏捷架构本质上是一套价值观、实践和协作，它积极支持系统的设计和进化架构。这种方法采用了DevOps的思维方式，允许系统的架构随着时间的推移不断发展，同时支持当今用户的需求。它避免了阶段性门和大型前期设计（BUFD）过程中固有的启动-停止-启动的性质和大规模重新设计所带来的开销和延误。

敏捷架构通过协作、涌现式设计、有意的架构和设计的简单性来支持敏捷开发实践。伴随着敏捷开发实践，敏捷架构也实现了可测试性、实施和发布的设计。 领域和分散的创新"。

从这个定义中，出现了两个非常重要的术语，包括：新出现的设计和有意的架构。

新兴设计是分析和扩展架构的过程，刚好可以在开发周期中实施和验证下一个增量。

有意的架构是关于看到大的画面。大型企业需要同时应对新的商业挑战与大规模的架构举措。在大规模的情况下，我们可以理解，为了达到商业目标，将涉及多个团队、产品和系统。在这种情况下，Emergent Design是不够的，因为它被限定在一个团队中。如果没有有意的架构，我们会有几个问题，如难以整合、验证和维护非功能系统需求的满足，低重用，解决方案的冗余，等等。

有意的架构将给各团队一个共同的目标/目的地，允许调整工作和独立团队的工作平行化。换句话说，它将是指导性的轨道，是各团队工作之间的粘合剂。

敏捷架构就是要平衡这两种力量。如果过于强调新兴设计，我们最终会得到难以整合的组件，糟糕的软件质量，以及上面所涉及的所有其他要点。如果你走相反的路，也就是说，如果我们开始夸大未来架构组件的详细程度，它就会成为一个瓶颈，并大大减慢你的团队开发速度。

深究起来，敏捷架构是关于设计/选择系统的结构组件和标准的方式，使其能够对建设途中的感知需求（功能和非功能需求）的变化做出反应。

为了实现这一点，要避免大的前期设计，但要说明对最终状态的清晰看法。所期望的最终状态会随着时间的推移而改变，但这是可以的。第二，尽快试用你的系统。确保每个版本都能提供一个生产就绪的系统。这将使你能够测试和检查你的系统是否真的提供了价值，你将能够尽快发现任何失败（在需求或设计中），并作出必要的改变。

总结

敏捷架构是在适应性的软件开发方法中设计架构的方式。它允许架构随着每个系统的发展而发展，避免了BUDF--前期设计。