敏捷方法已经成为了当前软件开发的主流模式，可工作的代码（以及自动化测试）被认为是团队最重要的产出。
那么是否不再需要建模了呢？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”）、如果订购者能够用一张简单的图片（配上文字）来表达他的意图，那绝对可以避免这个悲剧。有些时候，真的是“一图胜千言”。
那么，在敏捷团队中，该怎样为了实现目的而有效地使用模型呢？