敏捷时代的建模：敏捷团队的扩张除了代码还需要什么?(3)

　　扩张

　　极限编程团队先实现后分解(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，研讨会结束后的架构图，包含了众人的留言反馈

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

　　人是知识的传送带

　　许多设计思想都存在于种族记忆(tribal memory)中——Grady Booch对于开发与维护系统来说，尽管保留模型以及代码库能够覆盖大部分的必要知识，但仍有一部分隐藏的知识保留在团队成员的脑海中。Grady Booch将其称为种族记忆。

　　日本有一所神庙名叫伊势神宫。其中有一座神庙建筑，建立在两个相邻场地的其中一块，并且两块场地具有同样的大小。每隔20年，他们就会把建筑从一处移至另一处。不仅神庙经过了重新建造，并且它的庄严外表与宝库也得到了翻新。这一仪式将建筑的知识从这一代神庙传到下一代。虽然没有任何设计文档，但通过一起进行重新建造的过程，技术、工具以及实践知识都得以从这一代传递到下一代。记住，“经验是最好的老师”，并且只有在众人齐心协力时，才能够传递最丰富的设计知识。

　　伊势神宫(图片来源：维基百科)

　　建模的小提示

　　理解了我所介绍的思想与经验之后，在最后我将提供一些小提示，你可以在每日的建模会议或研讨会中用到它。

　　“逆向与模型”，许多UML工具支持“逆向工程”这一特性，它能够将代码即时转换为图形。其中某些工具支持从源代码中进行拖放操作，甚至直接支持Github代码库的URL。你还可以将从代码中逆向工程所得的包与类作为进一步建模的基础。这样，你就不仅仅可以从保留模型开始建模，还能以代码库所生成的模型作为建模的基础。

　　“打印与绘制”，如同之前所说的，一个具有良好互动性的建模研讨会应该在墙上(或者桌面上)贴上几张大纸，并使用这些纸张开展对话，将心得与反馈直接绘制在这些打印纸上(图11)。

　　“投影仪与白板”，在研讨会上分享模型的另一种方式是使用投影仪与白板，以模拟“打印与绘制”的情况。使用投影仪在白板上展示保留模型，并在白板上绘制各种留言，或者粘上便条贴。

　　“回顾”，我在之前推荐了一些我认为最简单的保留模型，但每个团队都可能有不同的情况。因此建议首先从我的建议，或者你觉得合适的模型作为第一部分的保留模型。并在每个Sprint之后为你选择的模型作一个回顾，讨论一下哪些模型起到了良好的作用而哪些没有，以及另外还需要哪些模型。总之，找到你的保留模型。

　　“思维导图建模“，在与用户交流时、做计划时以及其它一些氛围轻松但非常重要的工作时，UML以及其它软件工程图的作用并不理想，这时就可以使用思维导图了。具体细节请阅读《敏捷建模与思维导图和UML》。以下这个示例思维导图是我为某个用户创建的，名为“用户故事探索”。

原文转自：http://www.kuqin.com/shuoit/20131123/336470.html