敏捷建模——IBM Scott Ambler访谈录

建模和构建文档之间的联系有多强？

传统上，它们的关系非常强，这也是我们为什么全都如此关注的原因，但实际上它们之间的联系不是那么强。90%的建模工作在白纸板上完成，我们最近的一项调查显示，建模是团队中第四有效的工作。书面建模不是那么流行，关于用户叙述（User Stories）和CRC卡等的所有故事，是我喜欢看到的。

绝大多数建模工作都是在这种一次性的模型上完成的。但你可以提出非常强有力的证据，说明在开始编写代码前进行测试实际上也是建模，你在开始编写代码前说明程序的用法。就因为我没有画UML图并不表示我没有建模。

许多模型不会进化为文档，一些模型会，但在一个敏捷团队，你常常会随处看到白纸板，人们在上面画模型或别的什么，随着时间的推移，你会看到它们进化。当你开始考虑编写文档时，你会发现，那些仍然留在纸板上、你放进工具的、你夸耀并进行修饰的模型才是有用的模型。

你认为教育部门需要采取哪些措施来解决这个问题？

我认为大学应该解决几个问题：首先，他们没有必要的资金，他们的资金总是不够，事实就是这样。而且，由于某种原因，他们往往避开团队工作。建模是一个团体行为，你需要许多人参与进来，你们需要协同工作。

如果你在分配任务，你让人们绘制草图，那样很好，但他们可能只是粗略的编写出代码。他们还把教学内容划分成不同的课程，有Java课程、数据库课程、算术理论课程，那么学习的重点只是在数字编程或别的什么内容上面，他们从没有传授完整的生命周期。

另一个问题是他们并不安排项目。他们搞题海战术，或者给你一个任务让你去完成，但他们不会说：“接下来的两个时间我们研究这个系统”，因此两年里，他们传授不同的内容。你得不到任何实际经验。

我不是说做到这些很容易，但是他们应该着手解决这些问题。几年前我在多伦多大学工作，我们做了一件艰难的工作：在团队工作课程中，我们告诉学生他们会全程开发一个系统，然后在中途，我们撤走他们的所有材料，用前些年的材料进行替代，并且告诉他们：“好了，现在你们要维护一个遗留系统，现在你们该怎么办呢？”

他们十分震惊，我们听到的全都是说我们如何坏的牢骚和抱怨，但这就是现实。在现实世界中，你必须去维护其他人编写的代码。后来我遇到他们，他们告诉我说，这是他们学到的唯一确实有用的课程，因为那是真实发生的事情。你需要模拟那种情况，这确实很难做到。

我想知道，为什么一个为期三年的计算机课程不学习开源项目，为什么他们的任务不是让这三个人完成他们想要的项目；他们必须提供证据，表明他们具备某人确实感兴趣的素质——他们设计、执行、测试并交付该项目。那就是整个工作。那很容易做到，也更加有用。

随着我们进入一个更加全球化的开发模式，你认为敏捷开发过程有多重要？

由于某些原因，它显得非常重要。首先，人们在应用敏捷开发，所以对离岸工作的人来说，为什么不能以敏捷方式完成离岸团队工作呢？没有什么可以阻止他们。为什么不能以敏捷方式完成本土团队工作呢？同样没有什么可以阻止他们。

那么问题变为你如何在这些团队之间进行沟通，你必须擅长于此。你该如何组织团队，使他们即使在地球的另一面工作，也能保持高效率呢？要做到这一点并非易事，但你可以保持明智。

赋予每个位置尽可能多的责任。如果我得到一个离岸处理的子系统，那么它就是离岸工作的全部。如果本土团队确定需求和构造，再把它们交给离岸团队，你的项目就会缺乏活力。如果你在本土完成所有关键思考，你是在努力最小化风险，但实际上你已经增加了风险。

如果我把一份构造文档或一份详细的需求文档交给离岸团队，告诉他们说：“完成这项任务”。那么，如果你是离岸团队主管，你会怎么做。你会让下属来完成这件工作，因为他们已经为你安排好一切——实际上，任何高级职员都不想做那样的工作，在那种情况下，你只是一只“编程猴子”。

你需要承担尽可能多的责任——我看到许多成功的团队把它们的成员送到印度工作，你让一名项目经理在那边协调工作，但那样就足够了。长期来看，那样做的风险和成本都低许多。这实际上是一种非常有趣的工作方式，但你必须非常信任你的工作人员。