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

　　敏捷方法已经成为了当前软件开发的主流模式，可工作的代码(以及自动化测试)被认为是团队最重要的产出。

　　那么是否不再需要建模了呢?UML真的已死?我并不这么认为。

　　在本文中，我将探索在敏捷时代，建模方法依然适用并且扮演关键角色的所在。尤其在开发规模扩张到多个团队后，对整个系统的“Big Picture”达成共识将变得非常关键。

　　敏捷中的“设计”在哪里

　　虽然代码表现了事实，但它并没有表现事实的全部 – Grady Booch在开篇部分，我将描述一个使用Scrum的敏捷团队的精简流程。图1展示的是一个经过有意简化的流程，它仅仅保留了关键的部分。

　　列举在“Product Backlog”中的“用户需求” 。

　　开发团队从列表中选取一些需求，并在一个较短的迭代(或者一个Sprint)时间内实现它们。

　　每个Sprint结束后，团队创建了“可工作的软件”(或者是“增量内容”)，表现为“产品代码”与“测试代码”。

　　图1，简单的Scrum框架

　　在这个最精简的框架中，团队所知的是“Product Backlog”上的“用户需求”，而产出的是代码(“产品代码”与“测试代码“)所呈现的“可工作的软件”。这里并未显式地描述两者间的设计成果。理想的情况是，这个Sprint所产生的设计意图作为团队产出的一部分，已经体现在最终发布的代码中了。但有些信息是无法用代码直接表达的。Scrum本身是一种流程框架，它并不有意图地表现任何设计的部分，但团队中仍然少不了各种各样的设计工作。

　　正如Grady Booch所说，“代码表现了事实，但它并没有表现事实的全部”。因此如果有些信息无法以代码形式进行表述或交流，我们将把这些知识财富保留在哪里呢?这正是本文尝试解答的疑问。

　　写文档就不是敏捷了吗?

　　建模是为了进行对话 – Craig Larman与Bas Vodde对以上问题的一个回答也许是：“在我们的脑海中!”。每日例会、结对编程、设计研讨等等互动性的实践以一种同步的方式持续地将团队成员的思想进行归总。但是当团队开始扩张、或分布在不同地域、或有成员离开团队时，“脑海中的模型”的内容会被很快遗忘。我们需要以文档的形式将对系统的共识保存起来，以分享那些仅用代码形式不易保留及沟通的信息。

　　敏捷方法清晰地阐述了一个观点，即对话的价值更胜于文档，因此编写繁重的设计文档(它经常会重复代码中表述的信息)并非正确的途径。我们应该采取的途径是只编写那些使对话更有效的文档，它应该尽可能保持最简单的模型集合，与代码产生互补作用。

　　模型胜过代码的一个方面是它的可视化表达能力。换句话说，在某些情况下，文字是一种糟糕的交流媒介。图2表现了文字交流会失效的一种情况(感谢Jeff Patton为我推荐了这本书)。

　　图2，文字交流的失败

　　我猜测，这个“悲剧的”蛋糕是在给蛋糕厂家的电话答录机留言时的误解造成的(译注：订购者的原意是在“Best wishes Suzanne”这一句下方(Underneath that)加上“We will miss you”)、如果订购者能够用一张简单的图片(配上文字)来表达他的意图，那绝对可以避免这个悲剧。有些时候，真的是“一图胜千言”。

　　那么，在敏捷团队中，该怎样为了实现目的而有效地使用模型呢?

　　敏捷建模以及两种模型

　　保留建模，但去掉那些官僚主义的东西 – Scott Ambler“敏捷建模”是一系列可以应用在你的团队里以实现有效建模与文档的实践。这一方法遵循了敏捷价值与原则，并且使你依然可以从建模中受益。这里要强调的是，建模是为了更好地开展对话，而不是仅仅为了信息传递。

　　我们的软件开发团队已经在使用敏捷建模的实践与原则，并且发现模型起到的最主要作用是以可视化方式交流系统设计的“Big Picture”或者说是“鸟瞰图”，这一点是单凭代码难以表现的。缺乏模型的支持，整个团队的工作就好似盲人摸象，“四个盲人在摸象，每个人只能感觉到他所触摸的那一部分，最终花费了许多时间，才把这些部分统一成一个整体：一头大象!”

　　我的建议是，保持并维护一个反映“Big Picture”的模型，它应该包括以下内容：

　　系统的“架构”，以便于团队对于整个系统结构有一个初步的认识。

　　“领域模型”将帮助团队理解问题领域中的各种概念。

　　“关键用例”有助于发现系统的典型用户，并了解他们如何从系统中受益。

　　以上每一点对于建立对系统的理解都是非常关键的。缺少了模型的支持，你又怎样确保达到这种理解程度呢?如果你的代码库内容庞大，但只基于你所看到的一小部分不完整的内容推测系统的“Big Picture”，那么你将会对于如何维护整个代码库做出糟糕的选择。“Big Picture”不仅反映了团队对于系统的理解的模型，并且也构成了他们在对话中以及在代码中所用到的词汇，例如代码的结构，以及各种编程结构的命名方式，包括类、方法、变量、字段、数据、配置等等。换句话说，这些模型不仅对于团队建立起对系统整体的共识非常重要，同时也促使团队保持代码库的一致性与可维护性。

　　另一方面，某些临时模型的信息以代码形式记录下来之后，这些模型就会被丢弃。这一类别的模型包含画在白板上的松散类图，它通常包含一些类以及描述这些类的交互情况的时序图。这种模型将鼓励你开展有效的对话，其中产生的各种信息将以代码形式固定下来，并随后丢弃。

　　因此这一观点的核心是将模型分为两种类别 –应保留模型将作为资产保留维护，而临时模型则促进了有效的对话。我们将前者称为“应保留模型”或“保留模型”，而将后者称为“临时的模型”或“临时模型”(图3)。要注意的是，“保留模型”并不代表“已冻结的”，而是代表“应长期维护的”，并且将持续发展。在下一节中，我将为敏捷团队推荐三种“保留模型”。

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