项目中如何进行敏捷建模

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

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

　　最后总结

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

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

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

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

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

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

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

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

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

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