你对轻视敏捷建模，认为其不必要的开发者有什么告诫？
首先，如果你正在做敏捷[软件开发]，你实际上就是在进行敏捷建模，只是没有意识到这一点而已。
于是我开始问这样的问题：“你在白纸板上工作吗？”，答案是肯定的。这令人鼓舞，如果你去参观一个运作中的XP团队，那里总是有上面画着图表的白纸板，或者上面有索引卡的软木板，那些都是敏捷建模。
所以他们在做这种建模工作，但不承认这是建模。XP中的规划游戏——那也是一种建模行为，不是吗？如果你在做一个月的周期开发，你用前半天或一天时间规划出下个月的工作，那么许多工作其实都属于建模，你把大家都集中到一个房间，你们开始讨论，填写卡片，然后找到白纸板，在上面画、绘制草图并进行辩论等等。这就是建模。因此他们在做建模工作，只是没有这么叫而已。
最终他们责备管理层，责备其它高级开发者，而且因为他们不理解、无法说明他们到底在做什么，他们受到高级管理层的轻视。
管理层心想：“哦，他们没有做任何建模工作，你们这些卑鄙的下属”。他们是这样认为的，因为在七八十年代，他们见过代码修复者做过这种事情；现在，许多这种激进主义分子似乎也准备继承代码修复者的传统行为，因此他们被视为失败——他们并不相同，但听起来好像一样。
对于敏捷社区所有关于沟通的讨论，我们有时确实努力去传达我们的工作，这是非常重要的事情。如果你正在进行调整，如果你必须处理某种复杂的问题、如果你在准备离岸搬迁，那么你就在准备建模，你将要构建文档。即使你不会建模，你仍然要构建文档，因为要交付一个系统，文档资料必不可少。这再正确不过了，你需要用户文档、支持文档、系统文档，就是这样。我请你做到明智，敏捷建模就在于此，一定要明智。
如果一个开发者轻视敏捷建模，我不得不质疑他的工作表现，我无法想象，没有敏捷建模，他仍然能够做好工作。
许多开发者并不担心白纸板工作理念，但宁愿把它限制成一组规则……
是，但事实上团队没有做某种建模工作吗？我的意思是说，仅仅因为它在白纸板上、或在RSA或Visio或你使用的任何工具上——那不是对过度建设的承诺。
这并不意味着它会数月数月地建立所有这些无用的框架，而不交付商业价值。这些不对过度建设进行控制的人们有什么毛病吗？因此你可能会选择利用建模的益处而不受到过度建设或过分文档化的影响。这是个合理的选择，许多团队这样做，他们只是不知道如何描述它。
代码生成的产品一般比手工编写的项目质量要差，你赞成这个观点吗？
这全都取决于工具。例如，我会挑战任何手工进行数据库开发或编写其它程序的人。使用任何一种先进的数据建模工具，他们都能生成一流的DLL和触发器。如果你手工编写DLL，你有毛病吗？如果你手工编写一个触发器，你到底出了什么问题？这完全是浪费时间，真的很愚蠢。这很有趣，编写数据库书籍时，我不得不重新学习DLL知识，因为编写DLL已经是多年以前的事了。我只要安装一个CASE工具，给按钮的功能建模，生成代码。我为什么还要去编写它呢？
在Java方面，为什么我要编写类存根、或构造器、或是OR映射代码等此类代码呢？我无法想象再去编写那种代码。当然，有一些工具可以生成不那么完美的代码，你必须找到合适的工具。
除机械触发器等工具外，人们一直准备将程序员排除在整个过程之外。
20多年来，我一直听到这种说法。它过去是废话，现在同样是废话。
你不能那样做，你需要高度的技巧，你需要优秀的工具，如果我已经掌握那些技巧，我还是可以更快进行编码。
你真正想做的是对可视化建模有意义的事物进行可视化建模，为对代码有意义的材料进行编码，找到实现上述两种情形的工具，并在合适的时间做合适的事情。
那样做并不容易，但很有现实意义。你绝不可能拥有一个100%的建模地点，只有少数团队可以做到那一点，那非常棒。你总是发现它非常小、非常狭窄、他们是一个万人公司里唯一的团队。
现实中这样的团队非常罕见；当然这有可能，但为什么要那么麻烦呢？
你提到过我们需要建模技巧和代码生成技巧。除了在那种环境中学习以外，你去什么学习那些技巧，向拥有那些技巧的人学习吗？
那相当困难，你是说你可以学习课程。我想你可以在课程中学会编程，但你无法学会合理编程，你应该在实践中学习。你必须做那样的工作，因此当你学习这种内容时，你会得到一些培训，那会给你提供一些启示，但你需要一些指导，你需要实际动手经验——这都需要时间来学习。
如果你认为每个人都会有长达30或40年的职业生涯，那么在这方面投入一些努力会有许多好处。是的，掌握这些技巧可能要几年时间，但从职业生涯和学习时间的百分比来看，你值得这样做。
你必须积累动手经验，你必须与哪些了解如何建模的前辈一起工作。建模没有什么特殊之处，除非有人从头到尾地教你，否则很难学会建模。
如果一切都要靠经验，那么如果公司需要在建模工作中启用新人，他们需要寻求哪些素质呢？
许多因素。我寻找的个人素质：现有的经验固然不错，但他们愿意学习吗？他们愿意和其他人共同协作吗？他们愿意做重复性的工作，并以软件为中心吗？我们讨论了许多建模问题，但事实上你的目的是开发软件，这可不是建模。
我想这个领域有许多专业建模师，建模是他们的努力方向，因为几十年来他们一直接受这样的教育：“首先完成建模，你是商业分析师，把你的工作成果交给其他人，他们再从那里开始。”
不，我不需要那样的人才。我需要职员能够做一点分析、设计、编码、测试，然后从头再来。我不需要那些只会建模、或者只会编码或测试的人才。
我想那是我们如今在社区中看到的主要差异，拥有多方面技能的人才。我们一直称他们为“专才”，其他人叫他们“工艺师”或“复兴开发者”， Gartner group使用了一个新词：“多面手”（Versitalist）——即多才多艺的专家，或专门研究某个问题的人才。这是一个呦口的词，他们一定没有给它注音。我不知道他们怎么想，但这个想法不错。
最后总结
最后要向开发者说一句——公平对待建模。
我想，对那些有点轻视建模和构建文档的开发者来说——世界上没有绝对，建模没有错，构建文档也没有错，达到目标就已足够。
对程序员来说，如果你们掌握一些建模技巧，你们的生产效率肯定会有显著提高。对专业建模师而言，人们一直告诉他们要提前详细建模，如果他们少做些建模工作，及时建模，他们的生产效率也会得到提高。
如果你选择研究，有一个重要的证据，在生命周期之初就制定详细的需求说明实际上并不是好的做法。证据表明，在项目早期就进行周密设计实际对项目的结果不会产生影响。如果你提前进行大量详细设计，和根本不进行设计，成功的可能性是相同的；这两种做法都是极端行为。
这不是一个非黑即白的世界，我不是说根本不进行设计，也没有说做大量设计，敏捷建模是指为手头的工作做足够的设计，提供足够的需求，找到一个平衡点。
这就是搞混的地方——两个极端的人都必须找到平衡。提前建模没有合理理由，那不是建模的非常好的时机，你不可能一开始就全盘考虑所有问题。
我们知道这一点，我们多次看到这样做的项目遭到失败。如果你拥有今天提前建模的技巧，那么在六个月你确实需要所有信息时，你当然还是拥有这些技巧，那你为什么不能等等呢？没有什么理由预先做好一切。
你收集信息等待的时间越长，那些信息就越有可能是你需要的信息——你可以提出更加聪明的问题。如果我今天为某个工作建立模型，对于这个模型，我了解的信息最少，如果我在六个月以后建模，那么我就可以收集六个月的领域知识——我可以提出更合适的问题。我的股东已经对交付的软件研究了六个月，他们能够提供更好的反馈。
因此，采用敏捷建模方法比传统建模方法效率更高。这就是筑桥理论，软件开发就像是修筑一座桥梁。
告诉我上述观点的是那些没有筑过桥的人。虽然这很有趣，但那些既有筑桥经验，又有软件开发经验的人会告诉你，筑桥比我们想象的要复杂得多。
