软件团队建设之辩：提高团队效率而非简单地增加人手

作者 Sadek Drobi 译者 孙涛 发布于 2007年12月2日

领域

过程 & 实践,

语言 & 开发

主题

质量交付 ,

协作技术 ,

工件和工具 ,

质量 ,

协作 ,

工具 ,

软件工匠 ,

团队工作 ,

生产力 ,

架构 ,

敏捷

分享到

一场有关团队规模的大讨论正在通过博客悄无声息地进行着。它始于Reg Braithwaite在一篇博客文章中怀疑，在一个庞大的团队里，强大的语言可能也起不了什么作用：

如果编码规定（programming conventions）、元程序设计(meta-programming) 、表述性的类型系统（expressive type systems） 、 注释（annotations） 以及其他所有能帮助我们建立起强大抽象的工具无法适应大型团队的开发模式，那么我们该怎么办？

Reg在文章中认为工程效率会随着团队规模的增加而急剧下降。这个观点得到了相当的认同。Bob Warfield在其早先的一篇博客中强调，小而精的团队远胜于大的团队，不但效率更高，连质量都更胜一筹。对此产生的原因，Guillaume在评论Reg的博客时这么写道：“在大型团队中你只能依照团队中水平最低的人的标准来编写代码，不然就会有一大批程序员看不懂代码”。 Reg Braithwaite在博客中最后得出结论认为，通过增加在开发工具和过程改进中的投入从而增加团队效率，比单纯地增加团队人员的做法更值得提倡。如果这个原则得以贯彻，团队建设就会紧紧围绕更有效利用优秀的辅助开发工具和更合理的开发流程去去开展工作，而不仅仅是随意地增加两个人手。

持有不同意见的也大有人在，他们认为小团队虽然也可以开发象Linux这样复杂的软件，但是团队规模的增加也是难以避免的。一款成功的软件往往会吸引大量的客户，随之而来便是功能需求的激增，因此Chris Winters得出结论，软件的前期开发和后期的维护以及持续改进在复杂性上绝对不可同日而语，增加人手也成为很自然的事情。Warfield认为团队人员的膨胀的趋势更多是源于文化层面的原因——决策者往往在IT方面的专业程度有限，他们头脑中固有的原则是更多人力投入才能有更多更快的产出。此外，人事的升迁也会使更多的初级员工加入进来，这也是使团队人数不断增加的一个原因。

当团队规模增长不可避免的时候，怎样去保持开发效率和产品质量呢？通常的做法的是增加复查的次数，虽然这在一部分人看来纯属浪费时间。也有人并不认为开发人数增加就意味着产品品质的下降，Mike Kucera就是其中一个典型代表。他在评论中强调了增加抽象和代码可读性在对代码功能的理解和后期维护中的作用是不可小视的。同时，他认为抽象能使工程更易于分解成可由小团队独立开发的模块：

适当的抽象有助于使软件分解为松散耦合的模块，从而使每个小的团队专注于自己那一部分的模块的开发。

然而，Warfield却坚持认为并不是任何时候都可以将一个项目分解为独立模块的。因此他提出了缩小项目范围来解决问题的方法，并且他坚信客户的满意度并不会因此而受到太大的影响。这就是Warfield所谓的伟大的软件艺术，这样才能使一个小团队长久地保持产品的鲜活。

1. 返回顶部

   re：

   发表人 jiang yan

   在大型团队中你只能依照团队中水平最低的人的标准来编写代码，
   不然就会有一大批程序员看不懂代码.
   经典。

   回复