首页 > 无线通信 > 业界动态 > 大型专案让工程师崩溃?这里有解

大型专案让工程师崩溃?这里有解

2015-11-27   来源:互联网   点击:
要扼杀一个软体工程师团队生产力的最好方法是什么?答案是交给他们一个大型专案;有不少研究都显示,当专案规模越大,团队中个别程式设计师的生产效率就会崩溃。如下方的IBM资料,图表中日程拉长是因为两个因素推...

要扼杀一个软体工程师团队生产力的最好方法是什么?答案是交给他们一个大型专案;有不少研究都显示,当专案规模越大,团队中个别程式设计师的生产效率就会崩溃。

如下方的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以及由许多子团队打造的个别执行档;有部分处理器内含经过精心考量的独立运作程序,那些程序也是分别由小团队完成。

这就是为什么许多小型任务,往往能比数量更少的大型任务在更短时间之内完成。

[page]

上一篇:150岁的诺基亚,能否借收购阿朗“返老还童”?
下一篇:最后一页