大型开发案“化整为零”更有效率！

如下方的IBM资料，图表中日程拉长是因为两个因素推动，第一是由于专案规模越来越大，有更多程式码行数(lines of code，LOC)；第二，如同图表右侧的数字，个别程式设计师的每月生产力会随着专案规模增加而呈数量级下降，这是非常大的打击。


当专案规模越大，个别程式设计师的生产力下降越多

构造性成本模型(Constructive Cost Models，COCOMO)是广为人知的软体开发时程估算方法(但该方法其实很少人使用；COCOMO II有15个系数必须针对一个特定团队做调整)，该模型很复杂，但基本上是说，开发时程与程式的KLOC大小成正比，并会升高到某个X指数，其中X大于1。显然这意味着如同前述的IBM资料所呈现，专案规模越大导致生产力越低落。

为什么会这样？越大的程式越不容易理解，有很多的交互作用以及其他技术问题，也有人为因素。如果一个专案是单人负责，就没有团队成员沟通的状况，所有的想法都在那个人的脑袋里，不需要讨论，他只要卷起袖子开始工作就对了。

如果一个团队有两个成员，他们之间会有一个沟通管道；如果以N代表专案中开发人员的数量，他们之间的沟通管道就会有N (N-1)/2个。因此在一个大团队中，大家可能会忙着相互讨论，根本没时间写程式，每天有一大堆email要回、还有开不完的会、做不完的报表；也许在另一场会议开始之前，有一点点时间可以挤出一行程式。

因此要保持开发效率，把专案的规模弄小一点就对了；但是有些案例，像是手机程式开发案，在本质上就非常庞大，一支手机可能内含数千万行程式码。

大型专案总是得背负着生产力的压力，但还是有一些方法能减轻那样的压力，也就是有效率地将系统功能划分；将系统的不同部分打散成一个个小区块，每个区块都由一个小型团队以高生产力完成，让彼此的交互介面小一点、清楚明瞭，并以妥善的文件归档来将各团队之间的沟通减到最少。

不久前我曾经被叫去支援一个棘手的专案；有700位软体开发工程师在做一个可执行的系统，花了几年时间终于出货，但其中有许多几乎不可能修正的错误，因此要添加新功能是会有问题的；讽刺的是，他们的竞争对手之一拥有一个类似的产品，而且开发团队的规模只有他们一半。其主要差异性在哪里？有两个最大的因素：

首先，那个遇到麻烦的大型团队成员完全萎靡不振，他们知道情况很糟，而且一直以来都感到绝望。那个较小的团队则是完成了惊人的架构区分，不使用拥有许多功能的单一处理器，而是使用许多CPU以及由许多子团队打造的个别执行档；有部分处理器内含经过精心考量的独立运作程序，那些程序也是分别由小团队完成。