团队规模与实施效率

IBM 360操作系统之父的F.P.布鲁克在他著的《人月神化》中提到：需要协作沟通的人员的数量影响着开发成本，因为成本的主要组成部分是相互的沟通和交流，以及更正沟通不当所引起的不良结果（系统调试）。

人与人之间必需通过沟通来解决各自承担任务之间的接口问题，如果项目有n个工作人员，则有n×（n -1）/ 2个相互沟通的路径。假设一个人单独开发软件，年实施效率为10000行代码，而每一条沟通路径上每年消耗掉的工作量可折合500行代码，则团队规模和沟通消耗以及实施效率存在以下关系：
团队规模n  沟通路径数
n×（n -1）/ 2  沟通消耗（LOC/人年）
沟通路径数×500  实施效率（LOC/人年）
10000－沟通消耗/n
1  0  0  10000
4  6  3000  9250
6  15  7500  8750
10  45  22500  7750

由此可知，一个人单独开发一个软件，人均效率高，只可惜大部分软件规模和时间要求都不允许一个人单独开发，而团队开发的沟通消耗却呈二次方增长。所以，项目团队应该尽可能精简，以较少的人在可能允许的时间内完成任务是相对高效的。

团队的组织方式与实施效率

不难看出，通过减少沟通消耗、提高沟通效率能够提高项目团队工作效率。良好的团队组织可以减少不必要交流和合作的数量，是提高团队效率的关键措施。

减少交流的方法是明确的个人分工和接口定义。卡内基－梅隆大学的D.L.Parnas认为，编程人员仅了解自己负责的部分，而不是整个系统的开发细节时，工作效率高。

一种行之有效的方法是改变沟通的结构和方式。比如上面的例子中，一个10人的项目团队，沟通路径有10×(10-1)/2=45条，这种计算基于一种假设，即团队中成员间的关系是对称的，各人在团队中的沟通地位完全对等，沟通方式是全通道式的。同样一个项目，把组织方式改变为下图所示：

　 由一位系统架构师将系统分为三个相对独体的子系统，构架师负责子系统间的接口定义；然后将其余9人分为三个小组，每个小组负责一个子系统，小组组长和架构师相互沟通子系统间的接口，小组间的交流通过架构师组织进行；每个小组内部采用全通道式的沟通方式。那么，这样的一个组织方式沟通路径只有9条，沟通效率是全通道式组织方式的五倍。

当然，这种方法的先决条件是有一个对整个项目总体把握很好的软件架构师以及精确完整地定义所有接口。

团队的默契度与实施效率

很显然，团队的默契程度对软件实施效率影响很大。一个经过长期磨合、相互信任、形成一套达默契的做事方法和风格的团队，可能省掉很多不必要的沟通，相反，初次合作的团队因为团队成员各自的背景和风格不同、成员间相互信任度不高等原因，要充分考虑沟通消耗。

软件企业人员流动率高的特点导致团队凝聚力和默契度的锤炼比较困难。而凝聚力和默契度的需要长期的、大量的内部沟通和交流才能逐步形成，由此不难理解持续良好的沟通和交流是一个团队的无形资产，自然，稳定、默契的开发团队形成一个软件企业的核心竞争力的道理。

还有一点不容忽视，那是软件开发这种以人脑为主要工具的创造性很强的作业，开发人员的心情和兴奋度对个人工作效率影响很大，而一个人置身于氛围良好、合作默契的团队中心情一般较好，这种良好的氛围所能带来的能量是不可估量的。