敏捷与架构

实施敏捷方法和设计企业架构之间似乎总是存在某种冲突。从表面上看，敏捷开发强调随着对业务领域的深入理解，逐步调整设计和计划。架构设计则要求建立起技术架构（technology stack）。它可以满足质量属性（quality attributes），也可以向感兴趣的利益关系人进行展示，作为一种沟通的途径。通俗来举个例子，出去旅游，敏捷开发则是走一步看一步，看到哪好玩就去哪玩，而架构则是先考虑好各种因素，选择一条最优的路线出行。
敏捷开发是一种软件过程方法和工具，敏捷开发本身并不能代表架构设计。这就好比建筑架构设计和建筑工程管理之间的差别一样，两者是建筑的两个方面。相同的软件行业也是类似的情况，软件架构设计描述的是事物本身，而敏捷开发描述的是创建这个事物的过程。所以敏捷开发和架构是没有直接替代关系的两个范畴。
敏捷表现为软件及其开发过程的可持续和高质量，非持续的低质量开发有悖于敏捷。敏捷宣言中写道“对卓越技术和良好设计的持续关注有益于敏捷”，这为架构指明了敏捷开发中扮演的角色——无需大量预先设计。但敏捷开发后，架构设计（内容和形式上）还是有了一定程度的变化。

敏捷开发和架构设计

1. 敏捷开发中架构设计的方式
这里的架构设计方式，指什么时候进行架构设计，并以什么样的方式进行架构设计，如Iteration中新需求引入时，重构的方式，Code is Design的方式等。
下图描述了敏捷开发前和后架构方式：

上图中，敏捷开发后软件架构设计的方式产生了变化：敏捷开发把原先软件过程前期的架构设计，分散到了整个敏捷开发软件过程中。
看到敏捷开发中分散化的架构设计，想起公司财务中的”马克威茨资产组合理论”，用马克威茨这个诺贝尔大师的理论来解释敏捷开发中的分散架构形式，却也行得通。
“马克威茨资产组合理论”中说道：可以通过分散投资使收益率不变而方差（风险）减少。通俗一点讲也就是不要把鸡蛋放在一个篮子里。资产组合分散化后，可以做到收益率不变的情况下，风险减少。
这里的风险指的是波动，也就是方差。这和软件工程中的风险有异曲同工之意，即软件工程中的风险指：需求的波动，数学化后就是需求的方差。然后可以按照统计定理推论出，把架构设计组合化，并分散化，有益于收益率不变的情况下，减少软件风险。（中间的推导过程省略，有兴趣的朋友参考相应文献）。
如果按照资产组合理论，下面这些就是软件架构设计中的组合，把一次性软件过程前期30%（甚至更多）的架构设计，换成如下的软件架构组合：
（1）引入新需求后的架构。每个Iteration中，新需求引入前，都可以进行构思和架构。
（2）重构产生架构。先让软件运行，再重构其代码。那么软件的架构随着重构自然而然的在软件过程中产生。
（3）开发过程中的设计：以前是设计完后开发，现在是边设计边开发。
（4）其他
所以敏捷开发不是轻架构设计，而是依然注重架构设计。只不过架构的方式变化了，变得更加有效且风险更小。

2. 敏捷开发中架构设计的内容
传统的架构设计，包括架构和设计两个方面、其中设计可以包含详细设计，如详细的UML图（详细的类图，顺序图等），详细的API设计以及接口描述，存储层数据库表字段设计等等。
出于下面两个方面的考虑，敏捷开发不适合这种架构设计内容：
（1）在当今的快速变化的社会中，业务需求和技术也都快速变化着，在软件过程前期花费30%（甚至更多）的时间进行架构设计，要么开发出来的软件不符合市场需求，要么就是一旦需求变动，造成较大的改动成本。如，作者了解的一个电子商务产品，当前所做的功能都是两年前规划设计的，而且如有新需求发生，需要下个版本才会采纳，导致整个产品脱离市场和客户的需求。
（2）架构设计包含两个方面，一是：架构，二是：设计。其中设计中的详细设计需要大量的时间，包含详细的流程，API，数据结构等设计。但软件开发阶段的Code编码阶段，同样蕴含了很多详细设计的内容，所以二者之间存在着Repeat Yourself的情况。换句话说，现在敏捷开发提倡Code is design，而以前是Design is code。但问题是，软件开发人员维护一套Design，外加一套Code，不堪重负，效率低。所以，现在是Code is Design盛行，敏捷盛行。
基于这两种原因，敏捷中将传统的架构设计分成：架构 + 设计：
（1）敏捷开发的架构保留架构部分
（2）转移设计到Code编码阶段、重构阶段、Unit Test阶段等。
分离后，敏捷开发中的架构就轻装上阵，内容可以包括：
（1）软件的架构层次，层次化是软件产品架构中很重要的一部分。
（2）产品和技术选型
（3）各个组件的结构，以及的关系
（4）重要模块，和重要类的说明。但无需设计全部的类，和类的方法。
（5）….
而详细设计阶段，则在Code编码和UT单元测试阶段进行。这个阶段重构很重要，重构使你的软件架构和组件结构自然呈现。
所以在敏捷开发中架构设计的内容发生了变化：敏捷开发中止于架构，轻详细设计。但详细设计不是消失不见了，而是转移到了开发阶段，也即是：Code is design。这样既能拥抱变化，又规避风险，又Don’t Repeat Yourself。

3. 敏捷开发中架构设计的人员
敏捷开发后，软件过程变化了，架构形式变化了，随之相应的人员的责任和需要素质也会变化。这里强调的是，敏捷开发架构设计变化后，对开发人员提出了更高的要求，要超越Code is Code阶段，达到Code is Design的要求。如上面我们分析，敏捷开发中架构设计内容变化后，一部分的设计职责转移到了开发人员身上。所以开发人员不仅需要是技术专家，不仅能够写很好的程序，还需要有架构设计思想和能力，能够在开发过程中不断重构出Design。
架构描述的是软件本身的结构，敏捷开发描述的是制造这个软件的过程，他们二者是软件科学的两条脉络，互相影响。不管敏捷与否，架构设计依然软件中最重要之一，是软件开发人员的进阶目标。

演进式架构设计

在敏捷开发过程中，我们还需要对系统架构进行设计吗?事实上，Martin Fowler在《Is Design Dead?》一文中已经给出了答案，那就是我们同样不能忽略对系统架构的设计。与计划性的设计(Planned Design)不同，我们需要演进式的设计(Evolutionary Design)。
IBM’s Methods Group的敏捷专家Scott W. Ambler提出了“架构预测(Architectural Envisioning)”的方法，以应对敏捷开发中逐步演进的架构设计过程。
Scott指出，敏捷模型驱动开发(Agile Model Driven Development，AMDD)明确地包括了初始需求分析与架构建模，这个过程发生在敏捷项目开发的第0次迭代中。
通过对架构的预测，可以在项目早期进行一些高层次的架构建模，以助于团队与关键利益相关人商讨系统采取的技术策略。这一行为的关键目标是识别出架构策略，而不是撰写如山一般堆积的文档，从而使得你能够快速完成架构建模。
架构建模是贯穿于整个项目周期的，因此这些图表(技术图表,用户交互流程图,领域图,变更情形)就是在项目结束时形成的整体文档的基础。由于你事先明确架构是演进的，因此就不必承担架构设计在项目早期必须“正确无误”的压力，而只需要在当前形势下保证足够好就可以了。
Scott指出，所谓的“架构预测”能够提供如下价值：

• 提高生产力
• 降低技术风险
• 减少开发时间
• 增强沟通
• 可伸缩的敏捷软件开发。

需要明确的是，这样的一种架构预测方式，正好符合敏捷开发迭代的需要。在项目开发早期，对系统整体进行一次高层次的概览，并对关键业务需求进行甄别与分析，划分合理的系统模块，有助于在迭代开发中为团队成员建立一个统一的标准与目标。而在每次迭代过程中，团队就可以对本次迭代期间的功能进行深入的架构建模，然后通过TDD充分理解需求，对模块的细节进行设计与实现。这是敏捷架构设计的核心操作原理，它与敏捷开发原则是一脉相承的。

敏捷项目中的架构师

在敏捷项目中，架构师可以扮演重要的角色吗？还是说，因为他们倾向于“预先做大量设计（big design up front）”而只能成为辅助角色？
软件架构与敏捷开发过程并不冲突，不过，在一个交付周期较短的 Scrum 项目中，花费数月时间编写文档和图解系统的传统架构实践活动“相当傻”。但是，必须承认，任何软件项目——包括通过 Scrum 开发过程交付的项目——都有一个基本的软件架构。

软件架构的价值在于，它对系统自身核心基础设施做一系列关键决策：哪里需要泛化？要使用分层模式吗？如果使用，每一层的职责是什么？每一层包含哪些模块以及为什么要创建这些模块？如何在层和组件之间划分系统的职责？如何将模块进行大规模部署？信息如何在模块之间以及系统与外围系统之间流转？ 这些问题的答案可以说明一个系统的架构是什么样子。

软件架构师在软件架构职责的三个不同层次上工作时均需要考虑这些需求。

1. 最上面一层称作“校准过程（Aligning Processes）”，每季度或者每半年发生一次，解决整个组织的信息和商业策略相关的架构问题。这一层的输出是组织的未来软件模型。
2. 第二层包括“平衡过程（Balancing Processes）”，它与给定的软件项目相关联，可能发生在前面几次Scrum 冲刺的推进过程中。，在这一层会对系统的逻辑架构进行精心设计。这些过程考虑单一系统的需求，但仅仅决定几个方面的问题，包括为什么软件要分成模块、层和组件，如何进行职责划分，以及最终系统使用特定技术部署到特定的环境以后是什么样子。
3. 最后，该模型的最底层是“实现过程（Realization Processes）”。这一层是“架构变成软件的地方”，架构师做出具体的设计决定 ，软件开发人员按照决定构建系统。开发人员可能不接受架构师选择的设计模式，即便如此，“开发团队还是极有可能按照架构师的描述实现软件架构，但是可以改进它”。

那么，在实践中，对于一个给定的Scrum 软件开发过程，如何开展这项工作呢？Malik 直接在“冲刺规划（Sprint Planning）”会议之前增加了一个阶段。原先，可以从优先“产品待办事项列表（Product Backlog）” 阶段直接进入到冲刺规划会议及后续软件冲刺阶段。现在，项目团队插入了“冲刺前Story 审查（Pre-Sprint Story Review）”阶段，用于对Story 进行改进及架构评估。

在冲刺规划会议前的一周里，那些与产品经理一起工作的人可以改进 Story、增加约束、完善描述和验收标准。这时，架构师开始发挥作用。他完成了上述模型中的“平衡”任务，将有（或可以创建）一份描述软件系统架构的概要文档，并且能够把文档与受该设计影响的具体 Story“链接”起来。
在敏捷项目中，一名架构师是“鸡”还是“猪”取决于他在哪一层。在精心设计第一层和第二层的时候，架构师是团队的一名普通参与成员，即扮演“鸡”的角色；当在第三层工作的时候，架构师是一名投入大量时间与精力的参与者，即扮演“猪”的角色。

The fable of the Chicken and the Pig is used to illustrate the differing levels of project stakeholders involved in a project。
制造一份有培根和鸡蛋早餐，为此，猪要牺牲生命奉上火腿，而鸡只要轻松的下下蛋就可以了。用这个比喻不同人对一个项目的参与程度，pig is committed while chicken is only involved. For a Scrum project, Scrum Master, Product Owner, and Team are considered as people who are committed to the project while customers and executive management are considered as involved but not committed to the project.

参考