Martin Fowler上海交流实录：谈谈敏捷

李锟：我问Martin的第一个问题是：（speak in English）我是一个敏捷软件开发的爱好者，特别是极限编程。我也是一个交互设计和以使用为中心的设计的爱好者。我认为将两种方法论结合在一起可以产生高质量的软件，同时非常好的满足用户的需求。我曾经读过一篇Kent Beck和Alan Cooper在2002年1月的访谈，似乎两种方法论之间存在着一些冲突。我还阅读了Thomas Technologies公司的Jeff Patton写的一篇文章，他们找到一些将两种方法论相结合的很好的方法。我在ThoughtWorks的一些朋友告诉我，你们也在尝试将两者结合起来的方法。您能为我们介绍一下这方面的情况吗？

Martin：我可以介绍一下这方面的背景情况。这些年以来，我跟很多人交流过交互设计和以使用为中心的设计。他们希望能够捕获到用户的需要，并且可以使系统更关注于用户的使用。Alan Cooper是这个社区（community）的一个重要成员。这个社区存在的一个问题是他们在工作中或者一个提交中，趋向于假定把过程放在最重要的地位。这是与敏捷的思想不相符合的。这也是与Kent Beck和Alan Cooper的想法相脱节的，这两个人在你刚才的提问中提到，他们曾经接受采访。值得一提的是Jeff Patton在这方面确实做了很多有意义的工作，他是thoughtworks美国公司的员工，他使得交互设计得以应用于敏捷过程。然而，Jeff是一个非常受欢迎的人，我们把他和客户安排在一起，希望他能与客户有良好的合作。但是所有的thoughworks的员工都希望能给Jeff多一些时间，让他完成他自己的著作。

 

郭晓：李锟提到的Jeff Patton原来在Thomas Technologies工作，现在已经在ThoughtWorks工作了。

 

Martin：他已经为ThoughtWorks工作了一年或者更长时间了。我不能在这里过多的谈论事情的进展。但是如果你想抱怨Jeff的书为什么还没有出来，你可以去“责怪”Markku（ThoughtWorks全球首席执行官），去问他这件事情。我认为Jeff的这些是很有价值的。交互设计我认为是非常重要的,我们发现它非常值得去尝试，我希望知识传播的越快越好。不幸的是，写一本书需要付出很多很多艰辛。

 

李锟：我刚才听到Martin刚才讲到敏捷开发方法的一个核心理念就是对于人本身的重视。我在这几年学习敏捷开发方法的过程中对这一点体会也比较深。我现在想问Martin一个关于人本身的一个问题：每天8小时没有加班，只是一种很理想的状况，但是在很多公司里面存在着大量的加班的状况。有一个最近的例子是华为公司的胡新宇，他倒在自己的工作岗位上面，因为过度的加班。很多年以前，我也是华为公司的员工，我对这件事感到非常的悲哀，我知道在中国很多公司都存在这样的一种加班的文化，加班是取得晋升的诀窍，代表着这个员工对这家公司的忠诚度，而且实际上在很多公司这种加班实际上是一种半强迫的性质，我也知道大多数的开发者都憎恨这种开发。就是短期的加班没有问题，但是长期的会带来很多的问题。我想问一下Martin对这个问题怎么看？在ThoughtWorks怎么控制加班的情况？

 

Martin：这确实是一个非常重要的问题。在我上个世纪末参与的Netscape的一个咨询项目的时候，这个问题让我十分的困扰。我参与团队的一些工作。他们开始工作的时间是10点至11点，这个不好预测，但是他们工作到很晚，有的时候要到凌晨两三点。有的时候我们需要在下午开一个会，来开始一天真正有意义的工作。所以，在凌晨的那些工作通常是工作变得更复杂，制造了很多的错误。这并不能够提高团队工作效率。另外一种情况是，他们并没有按照Manager告诉他们的方式去工作，而是随心所欲的进行工作，从而忽视了他们犯错误的因素。软件是一项复杂的工程，需要你同时考虑很多，所以，当你头脑不太清醒的时候完成的工作会存在很多问题，往往需要花很多时间去解决这些问题。所以当你疲劳了，就不要再继续工作了。因为这会给整个团队和项目带来负面的影响。还有一个最大的问题，项目管理者很多时候没有写过代码，或者是一个非常好的开发人员，他们没有意识到这个问题，认为更多的工作时间意味着更多效果。但是这是应该意识到的问题。比如下一次你乘飞机的时候，被告知那个飞行员已经工作了12个小时，你应该不会高兴。这里的道理是相同的。我们虽然没有严格的法律规定不能超时工作,但是这个规则应该是相通的。在疲劳的时候工作，会使得工作生产率下降。工作10个小时或更多是对项目是不利的。因为你在项目中制造了更多的麻烦。当你觉得疲劳的时候，你需要放松。不要在代码中随意加入潦草的代码。我是这样认为的。

         

熊节：这边还有另外一个关于敏捷方法的问题。敏捷方法能否在较大范围的团队，比如上百人的团队以及分布的团队，位于几个不同地方的开发团队这样的项目中使用？

 

Martin：我们在几百人的项目中使用敏捷的方法，并且有一些分布式的开发，比如在不同的大洲,是不是有效果呢？这取决于你对于work是怎么样定义的。是每一个人自己的生产效率还是一个团队整体的效果？我不知道。不过在软件领域中一个基础的规则是它具有规模不经济(diseconomy of scale), 意思是你项目的团队越大，你每一个人的工作效率就越低，因为这里存在沟通的问题。所以当你的团队扩到两倍的时候并不意味着你的工作效率也扩到两倍。这个可能只有大约1.5倍的提高。当你遇到一些压力必须要提高效率的时候，你可能不得不通过增加团队规模来实现。当需要把一个耗时两年的工程在八个月内结束的时候，你唯一能做的就是增大团队规模，这不是一个有效率的方法，也不是我们所愿意见到的。但这是唯一的方法。同样的现象出现在分布式的团队。你到ThoughtWorks的印度分公司的时候，他们就是通过分布式的方式工作的。他们会告诉你，这样的团队的效率会大大提高。但是有另外一个问题出现了，这就是在美国和印度的团队之间的沟通。从另外一种意义上来看，敏捷是不是能够给上百人的,分布式的团队带来高的生产效率，带来有价值的工作，我的回答时可以的。我们有上百次成功地经验，这些证明我们是能够做到的。与传统的feature driven的方式相比，我想我们是有优势的。软件里面有另外一个问题，就是很难去衡量一个产出。我们确实分布式的开发了很多项目，并且这是我们的敏捷思想的体现之一。所以我的回答是肯定的。