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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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