工程师团队怎样做大型开发案更有效率?

2016-04-26 08:51:00
全芯编辑
转贴:
电子工程专辑
661

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

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

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

发表评论
评论通过审核之后才会显示。
updated: 2020-12-01 03:35:27