一直以来，无论是在软件开发组织之内，或是行业广大人士之中，对于敏捷团队是否需要架构师一直存在争论。大家的质疑集中在：既然软件的架构是随着每个迭代而演进的，那一个架构师还能给敏捷项目带来哪些价值呢？这让许多传统的架构师都感受到了威胁，并力图寻找掩护，也为一种新类型的架构师——敏捷架构师——打开了机会的大门。在敏捷项目中，传统架构师的象牙塔已经逐渐成为最薄弱的一环，而他们的许多工作职责也已经被整个敏捷团队所分解。敏捷架构师的出现，正符合了查尔斯??达尔文的“适者生存”理论。在一个团队中，敏捷架构师角色的重要性是毋庸置疑的，而且许多敏捷团队都认为他是任何敏捷软件开发团队中最有价值的成员之一。

　　那怎么样才算敏捷架构师呢？我们如何识别团队的架构师是否是敏捷架构师呢？嗯，答案其实并不简单；不过敏捷架构师确实具备与众不同的品质，而且这些品质会体现在他们在每天的日常工作之中。如果团队中的架构师能够体现这些品质，那么他肯定就是一个很好的敏捷架构师。不过首先我要警告你：下面的描述听起来也许有些过于理想化了，但他们确实描绘出了敏捷架构师应该达到的境界。敏捷架构师的首要目标：以最优质量交付可用的解决方案。

　　这里有两个很重要的方面。首先：解决方案的质量应该是最优的。理想状态下，质量的需求（也被称为非功能性需求）在敏捷项目的每个迭代中都要有所体现。像安全、性能、代码质量等等这些方面会隐式地包含在一个用户故事之中，或者作为一个单独的用户故事在迭代中出现。然而，在迭代中工作的团队经常会陷入到对业务功能的开发中，而质量方面的要求就被抛在脑后了。敏捷架构师要保证团队在每次进行构建时，都能从持续集成环境中获得关于静态代码质量、性能统计数据等反馈。他还要注意监控这些统计数据和质量属性，并不断提起团队对它们的注意。

　　其次，解决方案必须是可以正常工作的。敏捷架构师要与团队评估众多不同的选择，并一起交付一个可以工作并且能够产生业务价值的解决方案。他必须要确保解决方案不只能够独立运行，而且可以与客户现有整个软件环境进行良好的集成。这个解决方案必须足够健壮，可以随着时间变化进行变更和扩展。他必须将注意力置于可工作的解决方案之上，而不是对业务价值没有多大贡献的文档和管理层要求提交的某些可交付物上。

　　维护概念完整性

　　他要确保在硝烟四起的战场上，任务能够得以顺利完成。在实施时间表和技术障碍的双重压力下工作，开发人员有些时候做出的决策会让项目偏离原有的业务目标。架构师必须注意这种状况，确保任务在整个开发过程中不会受到负面影响。

　　当系统展现出这样的一致性——所有的东西看起来都可以无缝结合，这样的系统就具备了概念上的完整性。它是通过不同部分中一致性的展现和非理性设计的缺失来体现的。在大多数操作系统中的拖放操作就是一个很好的例子。如果系统在设计时遵循了概念上的完整性，那么拖放操作在任何时候、任何地方都应该是可以运作的。例如，要打开一个文件，可以通过将该文件拖放到合适的应用程序中实现；删除文件可以通过将其拖放到垃圾桶中完成。简单来说，应用概念完整性可以创造一个易于使用、易于维护，而且在使用中不会给用户带来过多讶异和不便的系统。

　　与团队一起工作

　　他会参与项目整个过程。会像其他程序员一样领取开发任务、实现用户故事。类似工作不会占用他一整天的时间，却是每天的固定工作。

　　他会在整个项目中运用自己的经验，并指导架构完成演化。在最初的几个迭代中，架构是不会完成的，它会随着每个迭代的进行逐渐演进。这就意味着：敏捷架构师与传统的架构师不同，当所谓的架构设计阶段完成后，他也不会转向全新的项目。

　　编写系统级别的测试

　　他会撰写底层的测试来检查系统的架构。如果架构上存在漏洞，失败的测试就会将其暴露出来。由于敏捷主张测试优先，他会编写使系统在质量特性方面失败的测试，并修改架构的某些相关部分来通过测试。少数情况下，用代码进行测试也许无法起到作用，他会想出其他的方式来“测试”架构。这可以确保不会在未经证实的设计上耗费精力。任何设计上的决策，无论大小，必须经过测试用例的检验。

　　例如，如果要求系统达到同时为一万个用户提供服务的质量要求，敏捷架构师会使用JMeter 或类似的压力测试脚本，以模拟足够的负载，确保系统可以承担这样的压力。如果测试失败，他会重构架构以通过测试。