2.2.3 交付速率

如果把管道直径比作组织的规模，效率的一个目标是提升管道的吞吐率，也就是交付管道直径不变的情况下，提高单位时间内通过管道的工作单元的数量。对应到软件开发组织，就是单位规模的组织在单位时间内所能交付的软件规模，我们简称其为交付速率。

最近这些年，印度和中国的软件开发组织飞速扩张，相对欧美的同类型组织，这些发展中国家的软件开发组织，很大程度上还处于以规模取胜的阶段，用人海战术、加班战术来拼速度、拼产量，但随着人力成本的上升，生活水平的改善，人们对工作和生活平衡的追求，使得这些以成本为核心的战术呈现出边际效益递减的效果。

软件开发本身的特点，使得在传统制造业中大放异彩的规模效应，并没有在软件开发中产生明显的效果。业界分析的结果指出，规模能够对软件开发效率带来2个正面效应。

（1）在以提高生产效率为目的的工具和基础设施上的投入可以被更广泛的共享。

（2）产品和项目管理的成本不会直接随着项目规模的增大而增加，可以想象，一个项目经理或一个产品经理，可以应对从十来号人到上百人团队的管理工作。

不过经验告诉我们，规模似乎对软件开发效率带来更多的是负面效应。

1．沟通成本

正如Brooks在《人月神话》中说的，开发规模大了之后，团队成员之间、团队和团队之间的沟通路径是几何级数增长的。由于沟通成本的增加，协作互信的关系难以维护，由于误解和信息不对称带来的返工和浪费，使得软件开发的规模边际效益是递减的。不管是传统基于流程的各种开发模型，还是敏捷社区中尝试的各种团队划分方法和沟通协作技巧，充其量只是在试图缓解这种规模负效应，并不能从根本上解决问题。

2．人员投入程度

软件开发是一个需要紧密协作的活动。大团队增加了人员间个性冲突的概率，会造成团队内不良的化学反应，降低团队效率。此外，大团队还降低了大多数个体的参与感。我们在多个拥有长期历史的产品开发团队中一次又一次地观察到，在团队规模较小的时候，每个成员都把项目当成自己的宝贝，全力投入，精心呵护，当团队规模逐步增大的时候，似乎只有项目经理等少数几个所谓骨干真正关注整体产品的交付，其他人大多只想着完成手头的一点局部任务就算了事，因此单体的贡献效率大幅下降。

3．系统复杂度

产生大规模团队的一个原因是系统本身的规模，而根据Conway’s Law，软件设计的架构，实际上反映了开发组织的结构与沟通架构。随着组织结构的扩展和复杂化，模块间接口数量也会随着模块数量的增加呈几何级数增长的。这意味着系统复杂度的增长，而且更加难以评估引入变更的影响，这也意味着系统维护、演进成本的增加。另外，复杂度带来专业分工，因而也带来了沟通成本。系统复杂度带来的第三个问题是计划和文档的成本，复杂的系统意味着大量的系统和项目信息，需要额外的手段来传承知识，这也带来成本。

上述分析表明，对于软件开发组织来说，提高单位规模下的交付速率是从效率的角度提升竞争优势的关键。