我们都看过有关项目失败的统计信息，也可能亲自遭遇过失败。大多数软件项目都逃脱不了失败的命运。思考一下，我们会发现导致项目失败的方式有（显然这个列表并不详尽！）：

技术上的：

解决方案不能满足项目需求（可伸缩性、性能、可靠性、成本等）

由于一些技术难题，我们不停推迟最后期限（或者靠增加成本保证期限），直到项目发起人对项目失去信心并撤资

工作方式上的：

团队不理解提供的需求

提供的需求并不正确

如果我们把这个问题抽象到一个高层次的视图，可以发现理解问题并形成解决方案是有困难的。

不过这个视图过于简化。从问题得出解决方案，我们不应该把这个过程看成是信息的单向流动，也绝不能把它看成是一次性、瀑布式的过程。这种做法我们先前都见过，它的进展并不顺利。

那来更新一下视图，我们发现问题和解决方案之间互有信息流，而且需要迭代。

现在的认知已经清楚一些了，不过它仍然很简单。让我们更进一层。我们都需要认识到，开发是一项团队活动。我们会有多个利益相关者，负责设计、开发、部署和运营的人也不少。

这样我们对这种情形有了更为真实的认识。不过值得思考的空间还是很大。虽然我们力求有一个本地协作的团队，但事实上我们的工作是分布式、网络化的。

总结一下这个过程，会发现项目的成功受限于我们的如下能力：

1. 理解

a. 我们了解问题领域么？

b. 我们是否通晓解决方案领域？

c. 我们知不知道两个领域之间该怎样转换？

2. 沟通

a. 利益相关者能不能把需求传递给确定解决方案的那些人？

b. 确定解决方案的人在彼此沟通时能不能把解决方案的细节描述清楚？

c. 确定解决方案的人能把挑战和替代方案准确地告诉利益相关者么？

此外，还要认识到一个棘手的问题，就是我们需要处理地理和时间的问题（比如工作地点和时区）。

解决这些问题的方法有很多，它们也能增加项目成功的胜算。但我们应该从哪里开始呢？从敏捷的一些基本理念（宣言、原则和部分常识）入手是个不错的主意。

与其把钱砸在一堆工具上（我敢肯定这种投入非常可观！），并试图采用命令方式和全方位的流程，还不如让我们用不同的方法。让我们更重视人、沟通、互动，来应对变化、交付软件。怎么才能用这种方法给人们提供最好的支持呢？

一种常被忽视、低估或误解的关键技术是建模的使用——尤其是我们开始采用敏捷方法之后。在反对重量级的流程和以工具为中心的开发过程时，建模也受到了牵连。让我们花几分钟时间来澄清一下……

我们先统一一下对建模的定义。简单说来，建模是对现实的简化。就是这样，不过如此。它并不意味着要用特定的符号、工具和流程。我们只是想研究复杂的东西，让其中的一些部分易于理解。正如他们所说，有时候你是见木不见林。不必要的细节反而会让情况更加难以理解。最好还是隐藏那些不必要的细节，只专注于具体情况的重要方面。

如果对建模的定义达成一致了，那我们就深入一步，考虑下敏捷建模吧。利用敏捷建模，我们可以用一种敏捷的方法去借助模型进行理解和沟通。很抱歉在这里进行了循环定义，但这很容易让我们提出问题：“使用模型的时候，我们怎么采用敏捷方法？”

和一般的敏捷开发一样，我们用一套价值观、原则和实践来进行指导，以便尽可能地敏捷。敏捷建模方法的重点有：

1.敏捷建模遵循敏捷宣言和原则。正因为如此，敏捷建模可以是一种实践，你可以把它添加到你的敏捷工具箱里。

2.模型能用来沟通和理解。

3.我们力争用简单的工具创建简单的模型。拥抱简单。

4.我们知道需求是变化的，因此我们在创建模型的时候要拥抱变化。

5.我们的重点是交付软件，而不是交付模型。模型能带来价值的时候，我们就使用它们。如果模型没有价值、不能加速软件的交付，那我们就不创建它们。

6.我们只保留需要的模型。如果模型完成了它的使命，我们就可以把它扔掉。这能让我们轻装上阵，而不会陷入繁忙的工作。

7.我们使用多种模型。我们使用模型时会考虑不同的角度和抽象层次，还有不同的读者。对于我们创建出来的所有模型，我们都知道它的读者是谁、要达成什么目标。要是我们还没理解目标，我们就不会创建模型。

8.根据具体情况、读者和目标的不同，我们会结合着用非正式和正式的模型。比如说，一个模型可以由多个简单形状组成，用来说明系统的隐喻，也可以用UML的类图。

总结

我们创建软件解决方案时，建模有助于我们进行沟通和理解。因为在交付软件解决方案的时候，沟通和理解是最关键的两个环节，所以不应该忽略建模这一有价值的工具。

消除对建模的误解吧，把它融汇到你的敏捷工作当中。敏捷建模遵循敏捷价值观和原则，应该成为敏捷工具箱里的实践之一。敏捷建模成为工具箱的一员后，会提高项目成功的胜算！

在这个系列的第二部分，让我们一起更深入地研究一下敏捷建模的价值观、原则和实践吧。