详细解读敏捷和架构的关系

为了理解敏捷和架构的关系，我们继续讨论第1部分曾经讨论的3个主要的方法：XP、Scrum和RUP。

1,极限编程：架构形成

XP是以程序员为中心的开发，其中没有一个核心实践明确讨论了软件架构，然而，这并不是说XP项目和XP团队不用或不理解架构在软件开发中的作用。Beck［2000］提到：“架构在XP项目中和在其他软件项目中一样重要”。因此，我们在概念上从XP方法入手是一个好的开端。接着Beck继续解释架构是如何形成的。

首次迭代，先挑选一些简单的和基本的故事，这些故事可以支持你创建整个架构。接下来，缩小范围，用最简单有效的方法实现这些故事。这个过程一旦结束，你就拥有了架构。

这些评论在XP的视角上提供了附加的解释。如果一个范围适度的系统，通过少量故事的一两次迭代展现出一个合理的架构基线，那么这种方法可能非常有效，使用这种模型就可能形成相当好的架构。并且，由于XP主要被推荐和应用于小团队，其有关团队大小和架构策略的观点是一致的。

此外，如果时间证明形成的系统架构不能支持系统继续演化，那么系统也可以较快地改写或者重构。事实上，重构代码是XP这个快速开发方法的关键组成部分，也是XP的特色。正如Beck［2000］所提到的：XP热中于重做，而不是减少重做的频率。对XP程序员来说，没有重构的日子就像没有阳光的日子一样。

在一个重构课堂上，Highsmith讲述了一个敏捷项目第一次发布的情况，项目是由一个10人小团队花费了大约7个月的时间后交付的。这次交付足以使公司在一个新兴市场稳坐头把交椅，并通过产品用户的客观反馈，更好地理解产品到底需要做什么。Highsmith接着讲述了一个大约60天的重构阶段，团队重新改写了系统以前实现的一个重要部分，把这部分加入到更好的结构基线中，并实现了新出现的需求。

由于仅花费两个月来重新开发系统，尝试早期交付过程的确是获取需求和形成架构的高效方法，并且能够很快推出满足新兴市场需求的产品，而尽早交付是XP方法的基本原则。因此，该重构模型在此环境中非常有效。

2, Scrum

我们在第1部分中提到，Scrum是一个敏捷软件项目管理过程，其特征是面向团队和授权、固定周期的评审和调整，以及驱动组织变更以实现提高软件生产率的目标的过程。

虽然Scrum并没有描述软件工程实践本身，[9]但是许多Scrum领导者认为XP是合适的开发过程，并且许多Scrum主管推荐把XP作为Scrum的同伴过程。例如，Sutherland［2005b］在PatientKeeper公司把XP实践应用于系统开发，以及Scrum和高级Scrum持续改进中。此外，Scrum中的３个角色（开发者，产品主管和Scrum主管）都不承担特定的架构职责。相反，Scrum依赖于一条久经考验的敏捷宣言原则“最好的架构、需求和设计来自于自组织的团队”。因此，正如其言，Scrum没有多少关于软件架构的内容，我们需要在其他地方寻找敏捷架构指南。

3,在FDD中的架构

我们在第6章中提到，域对象建模是FDD 8个最佳实践之一（其他7个是按特征开发、私有代码所有权、特征团队、审查、定期构建、配置管理和结果的可视化）。域对象建模是唯一涉及系统架构的最佳实践，这样，域对象建模在特定敏捷实践中为架构概念占据了重要的一席之地。

域对象建模是从应用系统支持的现实世界对象（实体）的视角创建系统模型的过程，是所有面向对象设计和架构技术的关键原则，也是FDD的一项关键实践。域对象模型除了定义这些对象之外，还用于定义这些实体间的关系。这些关系可以是静态的（通用性/特异性、多重性和依赖性），也可以是动态的（消息传递），这样域模型就可以达到团队想要的足够高（或足够低）的建模深度。正如Palmer［Palmer和Felsing 2002］所提到的一样。

当分析师和开发者得知需求……他们开始在头脑中形成待建系统的思维图像。他们非