【IT168 技术文章】
Scott Ambler：敏捷建模的目的是为建模和文档构建描述一组原则和实践，最好是用于敏捷项目中。但如果它们不是那么敏捷也没有问题。
我们已经看到，它的主要用途在于XP（极限编程）方面，目的是使现代文档构建过程更加明晰；或是与RUP（Rational统一过程）结合，降低一些官僚作风，并使它尽可能精简。
它只是通过你正在做的一些事情，不必死啃不必要的文件，为你描述有效思考的方法。从敏捷的角度看，它提出一些直接的策略，帮助你避开希望你做过多文案工作的官僚主义者，并就如何管理工作提供一些建议。
敏捷社区的一些更加极端的交流激发一些人去做错误的事情，我不是在嘲笑敏捷爱好者，只是他们的做事方式可能是错误的。
你认为程序员对于建模持什么观点？
我认为，许多程序员出于一些原因，对建模嗤之以鼻。
首先，他们没有受到过良好的培训。我想学校根本就没有建模课程，就我所知，从来就没有过，但他们现在在这方面的表面确实不如人意。
许多时候，开发者接受第一份工作，第一次做建模时，他们几乎总是会面临以下两种不良状况之一。他们要么加入一个项目团队，这个团队首先为你提供所有建模条件，然后你会慢慢忽略它。于是他们发现在建模文档方面浪费了许多精力，然后他们会说：“嗨，我做了所有这些建模工作，但它对产品没有任何影响，这真是浪费！”因此他们开始讨厌建模。
或者，更糟糕的是，他们会做他们的工作，他们成功部署项目进入生产，然后有人会指出：“嗯，现在我们需要用接下来的两个月时间构建所有的文档，我们应当让人们觉得我们遵循了工作流程。”这完全是浪费精力，只是有人为了给工作找到合理的理由，与交付价值根本无关。许多开发者厌恶这种事情。
另一个常见的问题是他们努力将建模与构建文档区分开来。如果我在一个白纸板上画草图，那么这是一个模型，但却不是一份非常整洁的文档。从某种意义上说，错在供应商，因为我们想出售CASE工具。我们试图让开发者确信，建模必须用这些复杂的工具来完成。
不，并不全是如此——我们只是观察到这样的事实：许多建模在白纸板上完成，许多建模在纸上完成，那样很好。如果你需要取得更加复杂的效果，就需要使用更加复杂的工具。
例如，我拥有熟练的建模技巧，因此在建模时，我使用RSA（Rational软件构建器，Rational Software Architect）或RSM（Rational软件建模器，Rational Software Modeller）这类工具比用手“涂鸦”更加有效，然后生成我的代码和数据库材料。
如果能够生成代码，却要去编写它，那样做就很愚蠢了。我认为在这方面，工具可以生成优良的代码。问题在于，使用工具需要掌握大量技巧——如果你不具备那种技巧，也没有花时间来掌握它，或是与某个掌握这种技巧的人合作，那么工作起来就相当艰难。许多开发者发现如果可以选择，他们愿意做更多建模工作，但他们并没有获得学习的机会。
我们肯定需要区分模型和文档，它们是完全不同的概念；虽然一些模型会进化成文档，但许多模型不会，那样也很好。
建模和构建文档之间的联系有多强？
传统上，它们的关系非常强，这也是我们为什么全都如此关注的原因，但实际上它们之间的联系不是那么强。90%的建模工作在白纸板上完成，我们最近的一项调查显示，建模是团队中第四有效的工作。书面建模不是那么流行，关于用户叙述（User Stories）和CRC卡等的所有故事，是我喜欢看到的。
绝大多数建模工作都是在这种一次性的模型上完成的。但你可以提出非常强有力的证据，说明在开始编写代码前进行测试实际上也是建模，你在开始编写代码前说明程序的用法。就因为我没有画UML图并不表示我没有建模。
许多模型不会进化为文档，一些模型会，但在一个敏捷团队，你常常会随处看到白纸板，人们在上面画模型或别的什么，随着时间的推移，你会看到它们进化。当你开始考虑编写文档时，你会发现，那些仍然留在纸板上、你放进工具的、你夸耀并进行修饰的模型才是有用的模型。
你认为教育部门需要采取哪些措施来解决这个问题？
我认为大学应该解决几个问题：首先，他们没有必要的资金，他们的资金总是不够，事实就是这样。而且，由于某种原因，他们往往避开团队工作。建模是一个团体行为，你需要许多人参与进来，你们需要协同工作。
如果你在分配任务，你让人们绘制草图，那样很好，但他们可能只是粗略的编写出代码。他们还把教学内容划分成不同的课程，有Java课程、数据库课程、算术理论课程，那么学习的重点只是在数字编程或别的什么内容上面，他们从没有传授完整的生命周期。
另一个问题是他们并不安排项目。他们搞题海战术，或者给你一个任务让你去完成，但他们不会说：“接下来的两个时间我们研究这个系统”，因此两年里，他们传授不同的内容。你得不到任何实际经验。
我不是说做到这些很容易，但是他们应该着手解决这些问题。几年前我在多伦多大学工作，我们做了一件艰难的工作：在团队工作课程中，我们告诉学生他们会全程开发一个系统，然后在中途，我们撤走他们的所有材料，用前些年的材料进行替代，并且告诉他们：“好了，现在你们要维护一个遗留系统，现在你们该怎么办呢？”
他们十分震惊，我们听到的全都是说我们如何坏的牢骚和抱怨，但这就是现实。在现实世界中，你必须去维护其他人编写的代码。后来我遇到他们，他们告诉我说，这是他们学到的唯一确实有用的课程，因为那是真实发生的事情。你需要模拟那种情况，这确实很难做到。
我想知道，为什么一个为期三年的计算机课程不学习开源项目，为什么他们的任务不是让这三个人完成他们想要的项目；他们必须提供证据，表明他们具备某人确实感兴趣的素质——他们设计、执行、测试并交付该项目。那就是整个工作。那很容易做到，也更加有用。
随着我们进入一个更加全球化的开发模式，你认为敏捷开发过程有多重要？
由于某些原因，它显得非常重要。首先，人们在应用敏捷开发，所以对离岸工作的人来说，为什么不能以敏捷方式完成离岸团队工作呢？没有什么可以阻止他们。为什么不能以敏捷方式完成本土团队工作呢？同样没有什么可以阻止他们。
那么问题变为你如何在这些团队之间进行沟通，你必须擅长于此。你该如何组织团队，使他们即使在地球的另一面工作，也能保持高效率呢？要做到这一点并非易事，但你可以保持明智。
赋予每个位置尽可能多的责任。如果我得到一个离岸处理的子系统，那么它就是离岸工作的全部。如果本土团队确定需求和构造，再把它们交给离岸团队，你的项目就会缺乏活力。如果你在本土完成所有关键思考，你是在努力最小化风险，但实际上你已经增加了风险。
如果我把一份构造文档或一份详细的需求文档交给离岸团队，告诉他们说：“完成这项任务”。那么，如果你是离岸团队主管，你会怎么做。你会让下属来完成这件工作，因为他们已经为你安排好一切——实际上，任何高级职员都不想做那样的工作，在那种情况下，你只是一只“编程猴子”。
你需要承担尽可能多的责任——我看到许多成功的团队把它们的成员送到印度工作，你让一名项目经理在那边协调工作，但那样就足够了。长期来看，那样做的风险和成本都低许多。这实际上是一种非常有趣的工作方式，但你必须非常信任你的工作人员。
