团队设计是敏捷方法论中很重要的一项实践。我们这里说的团队，指的并不是复数的人。一群人就是一群人，并没有办法构成团队。要想成为团队，有很多的工作要做。

我们之所以考虑以团队为单位来考虑架构设计，是因为软件开发本身就不是一件个人的事情，架构设计更是如此。单个人的思维不免有考虑欠妥之处，单个人的学识也不可能覆盖所有的学科。而组织有效的团队却能够弥补这些缺憾。

谁来负责架构的设计？

在我们的印象中，总认为架构设计是那些所谓架构设计师的专属工作，他们往往拥有丰富的设计经验和相关的技能，他们不用编写代码，就能够设计出理论上尽善尽美的架构，配有精美的图例。

问题1：理论上设计近乎完美的架构缺乏程序的证明，在实际应用中往往会出这样那样的问题。

问题2：设计师设计架构带有很大的主观性，往往会忽视客户的需求，导致架构无法满足需求。

问题3：实现的程序员对这种架构有抵触的情绪，或是因为不理解架构而导致架构实现的失败。

问题4：架构师设计架构主要是依据自己的大量经验，设计出的架构不能真实的反映目前的软件需要。

解决办法

团队设计的理论依据是群体决策。和个人决策相比，群体决策的最大好处就是其结论要更加的完整。而群体决策虽然有其优点，但其缺点也是很明显的：需要额外付出沟通成本、决策效率低、责任不明确、等等。但是群体决策如果能够组织得当的话，是能够在架构设计中发挥很大的优势的。

避免象牙塔式的架构设计

对软件来说，架构设计是一项至关重要的工作。这样的工作交给某个人是非常危险的。即便这个人再怎么聪明，他也可能会遗漏部分的细节。组织有效的团队的力量是大大超过个人的力量的，因此团队的成果较之个人的成果，在稳定性和思考的周密程度上，都要更胜一筹。

Scott W. Ambler在其著作中给出了象牙塔式架构（ivory tower architecture）的概念：

An ivory tower architecture is one that is often developed by an architect or architectural team in relative isolation to the day-to-day development activities of your project team(s).

中国现在的软件开发行业中也逐渐出现了象牙塔式的架构设计师。这些架构师并不参与实际的程序编写，他的工作就是为项目制作出精美的架构模型，这种架构模型在理论上是相当完美的。

例1：在XP中，我们基本上看不到架构设计的影子。并不是说采用XP技术的团队就不需要架构设计。XP不存在专门的设计时期，它提倡使用一些简单的图例、比喻的方式来表达软件的架构，而这种的架构设计是无时无刻不在进行的。其实，XP中的设计采用的就是团队设计的方式，结队编程（Pair Programming）和代码的集体所有制（Collective Ownership）是团队设计的基础，也就是基于口述的沟通方式。通过采用这样的方式，XP几乎不需要文档来表达架构的设计。

优秀的架构师能够充分的利用现有框架，减少软件的投入，增强软件的稳定性。这些都没有错，但是问题在于“过犹不及”。象牙塔式架构师往往会出现文章开始指出的那些问题。架构设计其实并不是非常复杂的工作，但它要求开发人员具备相关的技能、经验以及对问题域有一定的了解。开发人员往往都具有相关的技术技能（编程、数据库设计、建模），而对问题域的理解可以从用户和行业专家那里获得帮助。因此，在理论上，我们要实现架构设计的团队化是完全可能的。

在上面的象牙塔式架构定义中，我们看到架构师和日常的开发工作是隔绝的。这样设计出的架构有很大的局限性。在现实中，我们还会发现另外一种角色，他来自于开发团队外部，为开发人员提供相关的技术或业务的培训。这种角色称为教练，在软件开发中是非常重要的角色，不能够和象牙塔式架构设计师之间画等号。

选择你的设计团队

软件的架构在软件的生命周期的全过程中都很重要，也就是说，软件开发团队中的所有人员都需要和架构打交道。因此，最好的团队组织方式是所有开发人员都参与架构的设计，我们称这种方式为全员参与。全员参与的方式保证了所有开发人员都能够对架构设计提出自己的见解，综合多方面的意见，在全体开发人员中达成一致。这种方式尤其适合于一些小的团队。

还是会有很多的团队由于种种的原因不适合采用全员参与的方式。那么，组织优秀的开发人员组成设计组也是比较好的方式。一般，我们选择那些在项目中比较重要的，有较多开发经验，或是理论扎实的那些人来组成设计组。当然，如果你考虑到为组织培养后续力量，你也可以让一些新手加入设计组，或是你觉得自己的开发力量不足，邀请外部的咨询力量介入，这完全取决于具体的情况。

设计组不同于我们之前提到的象牙塔式架构设计师。设计组设计出来的架构只能称为原始架构，它是需要不断的反馈和改进的。因此，在架构实现中，设计组的成员将会分布到开发团队的各个领域，把架构的思想带给所有开发人员，编写代码来检验架构，并获得具体的反馈，然后所有的成员再集中到设计组中讨论架构的演进。

团队设计中存在的问题

在团队设计的过程，我们会遇到各种各样的问题，首当其冲的就是沟通成本的问题。架构设计时，需求尚未被充分理解，软件的设计思路还处于萌发的状态。这样的情况下，团队的每位成员对软件都有独特的见解，这些可能有些是相同的，有些是互斥的。就好比盲人摸象一样，他们的观点都代表了软件的一部分或是一方面，但是没有办法代表软件的全部。

在敏捷方法论中，我们的每一个流程都是迅速进行、不断改进的。架构设计也是一样，我们不可能在一次架构设计上花费更多的时间。而团队决策总是倾向于较长的讨论和权衡。

例2中的问题在架构设计中时有发生，纯技术的讨论很容易上升称为争吵。这种情况几乎没有办法完全避免。团队型的决策必然会发生观念的冲突。控制一定程度内的观念的冲突对团队的决策是有益，但是如果超出了这个程度就意味着失控了，需要团队领导者的调节。而更重要的，我们需要注意沟通的技巧。