项目中如何进行敏捷建模

敏捷建模对于Web 2.0领域内的开发者有什么意义？

Scott Ambler：敏捷建模的目的是为建模和文档构建描述一组原则和实践，最好是用于敏捷项目中。但如果它们不是那么敏捷也没有问题。

我们已经看到，它的主要用途在于XP（极限编程）方面，目的是使现代文档构建过程更加明晰；或是与RUP（Rational统一过程）结合，降低一些官僚作风，并使它尽可能精简。

它只是通过你正在做的一些事情，不必死啃不必要的文件，为你描述有效思考的方法。从敏捷的角度看，它提出一些直接的策略，帮助你避开希望你做过多文案工作的官僚主义者，并就如何管理工作提供一些建议。

敏捷社区的一些更加极端的交流激发一些人去做错误的事情，我不是在嘲笑敏捷爱好者，只是他们的做事方式可能是错误的。

你认为程序员对于建模持什么观点？

我认为，许多程序员出于一些原因，对建模嗤之以鼻。

首先，他们没有受到过良好的培训。我想学校根本就没有建模课程，就我所知，从来就没有过，但他们现在在这方面的表面确实不如人意。

许多时候，开发者接受第一份工作，第一次做建模时，他们几乎总是会面临以下两种不良状况之一。他们要么加入一个项目团队，这个团队首先为你提供所有建模条件，然后你会慢慢忽略它。于是他们发现在建模文档方面浪费了许多精力，然后他们会说：“嗨，我做了所有这些建模工作，但它对产品没有任何影响，这真是浪费！”因此他们开始讨厌建模。

或者，更糟糕的是，他们会做他们的工作，他们成功部署项目进入生产，然后有人会指出：“嗯，现在我们需要用接下来的两个月时间构建所有的文档，我们应当让人们觉得我们遵循了工作流程。”这完全是浪费精力，只是有人为了给工作找到合理的理由，与交付价值根本无关。许多开发者厌恶这种事情。

另一个常见的问题是他们努力将建模与构建文档区分开来。如果我在一个白纸板上画草图，那么这是一个模型，但却不是一份非常整洁的文档。从某种意义上说，错在供应商，因为我们想出售CASE工具。我们试图让开发者确信，建模必须用这些复杂的工具来完成。

不，并不全是如此——我们只是观察到这样的事实：许多建模在白纸板上完成，许多建模在纸上完成，那样很好。如果你需要取得更加复杂的效果，就需要使用更加复杂的工具。

例如，我拥有熟练的建模技巧，因此在建模时，我使用RSA（Rational软件构建器，Rational Software Architect）或RSM（Rational软件建模器，Rational Software Modeller）这类工具比用手“涂鸦”更加有效，然后生成我的代码和数据库材料。

如果能够生成代码，却要去编写它，那样做就很愚蠢了。我认为在这方面，工具可以生成优良的代码。问题在于，使用工具需要掌握大量技巧——如果你不具备那种技巧，也没有花时间来掌握它，或是与某个掌握这种技巧的人合作，那么工作起来就相当艰难。许多开发者发现如果可以选择，他们愿意做更多建模工作，但他们并没有获得学习的机会。

我们肯定需要区分模型和文档，它们是完全不同的概念；虽然一些模型会进化成文档，但许多模型不会，那样也很好。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

你对轻视敏捷建模，认为其不必要的开发者有什么告诫？

首先，如果你正在做敏捷“软件开发”，你实际上就是在进行敏捷建模，只是没有意识到这一点而已。

于是我开始问这样的问题：“你在白纸板上工作吗？”，答案是肯定的。这令人鼓舞，如果你去参观一个运作中的XP团队，那里总是有上面画着图表的白纸板，或者上面有索引卡的软木板，那些都是敏捷建模。

所以他们在做这种建模工作，但不承认这是建模。XP中的规划游戏——那也是一种建模行为，不是吗？如果你在做一个月的周期开发，你用前半天或一天时间规划出下个月的工作，那么许多工作其实都属于建模，你把大家都集中到一个房间，你们开始讨论，填写卡片，然后找到白纸板，在上面画、绘制草图并进行辩论等等。这就是建模。因此他们在做建模工作，只是没有这么叫而已。

最终他们责备管理层，责备其它高级开发者，而且因为他们不理解、无法说明他们到底在做什么，他们受到高级管理层的轻视。

管理层心想：“哦，他们没有做任何建模工作，你们这些卑鄙的下属”。他们是这样认为的，因为在七八十年代，他们见过代码修复者做过这种事情；现在，许多这种激进主义分子似乎也准备继承代码修复者的传统行为，因此他们被视为失败——他们并不相同，但听起来好像一样。

对于敏捷社区所有关于沟通的讨论，我们有时确实努力去传达我们的工作，这是非常重要的事情。如果你正在进行调整，如果你必须处理某种复杂的问题、如果你在准备离岸搬迁，那么你就在准备建模，你将要构建文档。即使你不会建模，你仍然要构建文档，因为要交付一个系统，文档资料必不可少。这再正确不过了，你需要用户文档、支持文档、系统文档，就是这样。我请你做到明智，敏捷建模就在于此，一定要明智。

如果一个开发者轻视敏捷建模，我不得不质疑他的工作表现，我无法想象，没有敏捷建模，他仍然能够做好工作。

许多开发者并不担心白纸板工作理念，但宁愿把它限制成一组规则……

是，但事实上团队没有做某种建模工作吗？我的意思是说，仅仅因为它在白纸板上、或在RSA或Visio或你使用的任何工具上——那不是对过度建设的承诺。

这并不意味着它会数月数月地建立所有这些无用的框架，而不交付商业价值。这些不对过度建设进行控制的人们有什么毛病吗？因此你可能会选择利用建模的益处而不受到过度建设或过分文档化的影响。这是个合理的选择，许多团队这样做，他们只是不知道如何描述它。

代码生成的产品一般比手工编写的项目质量要差，你赞成这个观点吗？

这全都取决于工具。例如，我会挑战任何手工进行数据库开发或编写其它程序的人。使用任何一种先进的数据建模工具，他们都能生成一流的DLL和触发器。如果你手工编写DLL，你有毛病吗？如果你手工编写一个触发器，你到底出了什么问题？这完全是浪费时间，真的很愚蠢。这很有趣，编写数据库书籍时，我不得不重新学习DLL知识，因为编写DLL已经是多年以前的事了。我只要安装一个CASE工具，给按钮的功能建模，生成代码。我为什么还要去编写它呢？

在Java方面，为什么我要编写类存根、或构造器、或是OR映射代码等此类代码呢？我无法想象再去编写那种代码。当然，有一些工具可以生成不那么完美的代码，你必须找到合适的工具。

除机械触发器等工具外，人们一直准备将程序员排除在整个过程之外。

20多年来，我一直听到这种说法。它过去是废话，现在同样是废话。

你不能那样做，你需要高度的技巧，你需要优秀的工具，如果我已经掌握那些技巧，我还是可以更快进行编码。

你真正想做的是对可视化建模有意义的事物进行可视化建模，为对代码有意义的材料进行编码，找到实现上述两种情形的工具，并在合适的时间做合适的事情。

那样做并不容易，但很有现实意义。你绝不可能拥有一个100%的建模地点，只有少数团队可以做到那一点，那非常棒。你总是发现它非常小、非常狭窄、他们是一个万人公司里唯一的团队。

现实中这样的团队非常罕见；当然这有可能，但为什么要那么麻烦呢？

你提到过我们需要建模技巧和代码生成技巧。除了在那种环境中学习以外，你去什么学习那些技巧，向拥有那些技巧的人学习吗？

那相当困难，你是说你可以学习课程。我想你可以在课程中学会编程，但你无法学会合理编程，你应该在实践中学习。你必须做那样的工作，因此当你学习这种内容时，你会得到一些培训，那会给你提供一些启示，但你需要一些指导，你需要实际动手经验——这都需要时间来学习。

如果你认为每个人都会有长达30或40年的职业生涯，那么在这方面投入一些努力会有许多好处。是的，掌握这些技巧可能要几年时间，但从职业生涯和学习时间的百分比来看，你值得这样做。

你必须积累动手经验，你必须与哪些了解如何建模的前辈一起工作。建模没有什么特殊之处，除非有人从头到尾地教你，否则很难学会建模。

如果一切都要靠经验，那么如果公司需要在建模工作中启用新人，他们需要寻求哪些素质呢？

许多因素。我寻找的个人素质：现有的经验固然不错，但他们愿意学习吗？他们愿意和其他人共同协作吗？他们愿意做重复性的工作，并以软件为中心吗？我们讨论了许多建模问题，但事实上你的目的是开发软件，这可不是建模。

我想这个领域有许多专业建模师，建模是他们的努力方向，因为几十年来他们一直接受这样的教育：“首先完成建模，你是商业分析师，把你的工作成果交给其他人，他们再从那里开始。”

不，我不需要那样的人才。我需要职员能够做一点分析、设计、编码、测试，然后从头再来。我不需要那些只会建模、或者只会编码或测试的人才。

我想那是我们如今在社区中看到的主要差异，拥有多方面技能的人才。我们一直称他们为“专才”，其他人叫他们“工艺师”或“复兴开发者”， Gartner group使用了一个新词：“多面手”（Versitalist）——即多才多艺的专家，或专门研究某个问题的人才。这是一个呦口的词，他们一定没有给它注音。我不知道他们怎么想，但这个想法不错。

最后总结

最后要向开发者说一句——公平对待建模。

我想，对那些有点轻视建模和构建文档的开发者来说——世界上没有绝对，建模没有错，构建文档也没有错，达到目标就已足够。

对程序员来说，如果你们掌握一些建模技巧，你们的生产效率肯定会有显著提高。对专业建模师而言，人们一直告诉他们要提前详细建模，如果他们少做些建模工作，及时建模，他们的生产效率也会得到提高。

如果你选择研究，有一个重要的证据，在生命周期之初就制定详细的需求说明实际上并不是好的做法。证据表明，在项目早期就进行周密设计实际对项目的结果不会产生影响。如果你提前进行大量详细设计，和根本不进行设计，成功的可能性是相同的；这两种做法都是极端行为。

这不是一个非黑即白的世界，我不是说根本不进行设计，也没有说做大量设计，敏捷建模是指为手头的工作做足够的设计，提供足够的需求，找到一个平衡点。

这就是搞混的地方——两个极端的人都必须找到平衡。提前建模没有合理理由，那不是建模的最佳时机，你不可能一开始就全盘考虑所有问题。

我们知道这一点，我们多次看到这样做的项目遭到失败。如果你拥有今天提前建模的技巧，那么在六个月你确实需要所有信息时，你当然还是拥有这些技巧，那你为什么不能等等呢？没有什么理由预先做好一切。

你收集信息等待的时间越长，那些信息就越有可能是你需要的信息——你可以提出更加聪明的问题。如果我今天为某个工作建立模型，对于这个模型，我了解的信息最少，如果我在六个月以后建模，那么我就可以收集六个月的领域知识——我可以提出更合适的问题。我的股东已经对交付的软件研究了六个月，他们能够提供更好的反馈。

因此，采用敏捷建模方法比传统建模方法效率更高。这就是筑桥理论，软件开发就像是修筑一座桥梁。

告诉我上述观点的是那些没有筑过桥的人。虽然这很有趣，但那些既有筑桥经验，又有软件开发经验的人会告诉你，筑桥比我们想象的要复杂得多。