敏捷建模:增强沟通和理解

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

工作方式上的：

• 团队不理解提供的需求
• 提供的需求并不正确

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

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

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

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

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

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

1. 理解

• a. 我们了解问题领域么？
• b. 我们是否通晓解决方案领域？
• c. 我们知不知道两个领域之间该怎样转换？

2. 沟通

• a. 利益相关者能不能把需求传递给确定解决方案的那些人？
• b. 确定解决方案的人在彼此沟通时能不能把解决方案的细节描述清楚？
• c. 确定解决方案的人能把挑战和替代方案准确地告诉利益相关者么？

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

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

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

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

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

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

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

1. 敏捷建模遵循敏捷宣言和原则。正因为如此，敏捷建模可以是一种实践，你可以把它添加到你的敏捷工具箱里。
2. 模型能用来沟通和理解。
3. 我们力争用简单的工具创建简单的模型。拥抱简单。
4. 我们知道需求是变化的，因此我们在创建模型的时候要拥抱变化。
5. 我们的重点是交付软件，而不是交付模型。模型能带来价值的时候，我们就使用它们。如果模型没有价值、不能加速软件的交付，那我们就不创建它们。
   
6. 我们只保留需要的模型。如果模型完成了它的使命，我们就可以把它扔掉。这能让我们轻装上阵，而不会陷入繁忙的工作。
7. 我们使用多种模型。我们使用模型时会考虑不同的角度和抽象层次，还有不同的读者。对于我们创建出来的所有模型，我们都知道它的读者是谁、要达成什么目标。要是我们还没理解目标，我们就不会创建模型。
8. 根据具体情况、读者和目标的不同，我们会结合着用非正式和正式的模型。比如说，一个模型可以由多个简单形状组成，用来说明系统的隐喻，也可以用UML的类图。

总结

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

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

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

资源

AgileModeling.com：Scott Ambler创建、维护的敏捷建模主页，里面的资源又好又详细。

敏捷建模的要点： 这个工作坊主要提供敏捷建模的基本技能。

规范敏捷交付（Disciplined Agile Delivery）：提供敏捷交付规范方法的社区网站。

关于作者

Lee Ackerman是The Emphasys Group的产品副总裁和CTO。Lee多年来主要调查、评估新理念，设计、开发解决方案，其他人做这些事情的时候他也会伸出援手。他目前的工作重点是帮助一些组织，让他们借助自动化、重用和敏捷最佳实践去提升交付软件的能力。

---

^[1] 《IT项目：超支400%，却只实现了25%的收益》：这篇新闻研究了IT项目风险和一些失败相关的惊人数据。

查看英文原文：Agile Modeling: Enhancing Communication and Understanding