在敏捷项目中，架构师可以扮演重要的角色吗？还是说，因为他们倾向于“预先做大量设计（big design up front）”而只能成为辅助角色？最近，微软的企业架构师Nick Malik在一篇博文中对该话题进行了探讨，他的结论是，架构师完全可以在使用Scrum的软件项目中扮演关键角色。

Malik的博文源于一个项目。在这个项目中，他试图把架构实践活动作用于Scrum过程。在文章的开头，他就立即断言，软件架构与敏捷开发过程并不冲突。不过，他也承认，在一个交付周期较短的Scrum项目中，花费数月时间编写文档和图解系统的传统架构实践活动“相当傻”。但是，必须承认，任何软件项目——包括通过Scrum开发过程交付的项目——都有一个基本的软件架构。

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

这些问题的答案可以说明一个系统的架构是什么样子。

据Malik说，做每一项选择都要仔细平衡系统的一连串质量需求。软件架构师在软件架构职责的三个不同层次上工作时均需要考虑这些需求。

最上面一层称作“校准过程（Aligning Processes）”，每季度或者每半年发生一次，解决整个组织的信息和商业策略相关的架构问题。这一层的输出是组织的未来软件模型。第二层包括“平衡过程（Balancing Processes）”，它与给定的软件项目相关联，可能发生在前面几次Scrum冲刺的推进过程中。Malik解释说，在这一层会对系统的逻辑架构进行精心设计。

这些过程考虑单一系统的需求，但仅仅决定几个方面的问题，包括为什么软件要分成模块、层和组件，如何进行职责划分，以及最终系统使用特定技术部署到特定的环境以后是什么样子。

最后，该模型的最底层是“实现过程（Realization Processes）”。据Malik说，这一层是“架构变成软件的地方”，架构师做出具体的设计决定 ，软件开发人员按照决定构建系统。Malik承认，开发人员可能不接受架构师选择的设计模式，即便如此，“开发团队还是极有可能按照架构师的描述实现软件架构，但是可以改进它”。

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

Malik建议在冲刺规划会议前一周执行这个专注于架构的新步骤。

在冲刺规划会议前的一周里，那些与产品经理一起工作的人可以改进Story、增加约束、完善描述和验收标准。这时，架构师开始发挥作用。他完成了上述模型中的“平衡”任务，将有（或可以创建）一份描述软件系统架构的概要文档，并且能够把文档与受该设计影响的具体Story“链接”起来。

Malik的结论是，在敏捷项目中，一名架构师是“鸡”还是“猪”取决于他在哪一层。在精心设计第一层和第二层的时候，架构师是团队的一名普通参与成员，即扮演“鸡”的角色；当在第三层工作的时候，架构师是一名投入大量时间与精力的参与者，即扮演“猪”的角色。这项由Malik推动的活动继续对架构师在敏捷实践中所扮演的角色进行研究。在今年早些时候的一篇博文中，Malik提出，架构师天生敏捷，他们注重通过增量过程完成高价值的活动，这一点与敏捷精神一致。由于企业试图提高软件开发的效率，同时又希望能够避免增加架构方面的负担，所以敏捷与架构的交点仍然是一个热门领域。