编写系统级别的测试

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

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

    参与紧密的协作

    他不会单独完成设计和技术上的决策；这些决策是与团队共同协作完成的。他拥有开放的心态，并且坚定认为自己不是全知全能的万事通，而且不会对自己的主意保有盲目的保守心态。当团队坐在一起进行头脑风暴时，就会产生最好的主意；任何人都可能提供好的想法和有价值的见识。开放和诚实的沟通可以帮助人们基于更好的信息做出更好的决策。敏捷架构师是一个善于与人打交道的人，他对任何人都充满敬意，并且会利用每一个机会向别人学习。他会促进共识的形成，并欢迎团队中每一个人为解决方案做出贡献。

    如果业务发起者在解释完项目的目标之后，架构师马上就可以提出一个解决方案，那么这个架构师也许不是一个真正的架构师。

    做坚定的指导者

    他经常与团队一起工作，来提升团队的决策制定能力。根本上，这可以帮助架构师更好地利用大家的智慧，而不是成为项目中单一的决策制定者。通过指导团队使用新的技术、为技术架构构建并提供支持，他与团队可以更好地形成协作与互利关系。他可以确保团队不会因为缺少某些经验或是对某些技术感到不适而简单地拒绝一种设计方案。如果真的发生了类似情况，他会为团队弥补中间的隔阂，从而让大家可以做出更加明智的决策。

    正如Martin Fowler 指出：“这指出了如下这条基本原则：一个架构师的价值与其所做出的决策数目成反比。”

    做熟练的协调者

    敏捷团队中包括技能熟练、富有激情的团队成员。对于设计决策、实现功能的非常好的方式、开发流程的改进措施，团队中经常会出现不同意见。还会带来激烈的争吵，如果不能迅速妥善处理，会影响成员之间彼此的感情。这些场合下，团队成员需要一个拥有丰富经验、足够成熟、并且见多识广的调解人，来帮助团队打破僵局，重新和谐。而敏捷架构师由于其成熟的水平和经验就成为了不二之选。

    不做大型的预先建模

    通常他不会使用重型的CASE 工具来做大型的建模设计和决策。一般来说，所有的建模都是“足够”的建模，并且是在白板上完成的。简单的模型会随着每个迭代慢慢成长、逐步改进。他会跟随敏捷建模的概念，对他来说“代码就是模型”。如果需要为了文档生成模型，那么这些模型也是通过一种合适的逆向工程工具从代码生成的。

    模型、文档、沟通的方式会以尽可能简洁扼要的方式保存。关键是要将注意力放在内容上，而不是展现或其他为了看起来好看而作的事情，这些东西并不能添加多少业务价值。