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。

    总结

    架构描述的是软件本身的结构，敏捷开发描述的是制造这个软件的过程，他们二者是软件科学的两条脉络，互相影响。不管敏捷与否，架构设计依然软件中最重要之一，是软件开发人员的进阶目标。