敏捷团队的扩张除了代码还需要什么?

　　扩张

　　极限编程团队先实现后分解(conquer and divide)，而不是相反(divide and conquer) – Kent Beck在一个不到10个开发者的小型团队中，你或许不需要在代码库之外再去维护某些模型了。但是当开发规模扩大到多个团队之后，你会从建模中获得更大的好处。

　　但请记住，不要仅仅为了将知识传递给某个你不认识的人，而花费太多时间去准备繁重的文档(而没有编写任何代码)。即使团队的规模变得更大了，你也应该尝试着首先按照某种简单的垂直划分的方式实现某个关键用例，将它作为架构的一个示例。随后，你将这个示例的可工作代码以及“保留模型”的知识分享给某个子团队。换句话说，不要尝试“先分解后实现”某个用例(在桌面上分解问题，随后将贴在墙上的规格说明丢给某个子团队并让他们实现)，而是让他们“先实现后分解”(关于这一话题的更多讨论，请阅读Craig Larman与Bas Vodde的文章——《大规模敏捷设计与架构》)。

　　这里，我将描述多个团队如何使用“保留模型”互相交流整个系统的“Big Picture”。首先有一个名为“Tiger”的团队，它有不足10名成员，他们将尝试实现第1部分内容。在首次成功的实现之后，他们可以将之前所述的各种“保留模型”作为良好的文档，用以互相交流对系统的理解。在Sprint 1中，Tiger团队首先完成了第一个关键用例，它建立起了第一个可作为范例的架构设计，并以此建立了软件架构文档(SAD)，作为保留模型的版本1.0。不要把这些模型当做一个规格说明，而是把它们当作建立理解和共识的基础平台。再一次记住，不要仅仅把这些文档的信息简单地传递给子团队。

图9，Tiger团队与子团队

　　沟通设计意图并达成共识的好方式，是与子团队一起开展一次建模研讨会(图9)

图10，建模研讨会的进程，在墙上显示的是保留模型的内容

　　在建模研讨会上，Tiger团队的一名成员Ken(见图9)首先解释了SAD，并简单描述了各个模型。在问答阶段，他将核心思想与系统的结构关联在一起。接下来，他以关键用例为例，解释了各个系统组件如何协作以实现某个用户目标，并使用这些组件设计出一至两个关键用例，在实现时可以使用临时模型，并可实行结对编程。

　　无需使SAD显得非常完整，以研讨会的形式建立起共识，抛弃信息传递的做法，并开展内容详实的对话，这非常好了。

　　反馈是子团队研讨会的一个重要部分。图9中，子团队1的Ken与子团队2的Tom将结果反馈给Tiger团队，并与其他成员一起讨论如何改善这些保留模型。图11显示了研讨会过程中众人的各种想法，包括了众人的理解与反馈。

图11，研讨会结束后的架构图，包含了众人的留言反馈

　　这种研讨会的方式需要不断保持。并且以建模的过程，而不是终的模型作为促进理解的方式。请记住，要将“模型”作为一个动词，通过建模以达到对话的目的。