海滨擎蟹

《人月神话》(P4)概念完整性和结构师【转】

外科手术队伍

常听到软件经理声称自己喜欢一流人才组成的精干的队伍,而不是那些几百人的大型团队,其实我也有同样的想法。不过,还有一个很困难的问题,大型项目的团队应该是怎样的呢?

问题

软件经理很早就认识到优秀程序员和较差程序员之间的生产率差异,研究人员对一组具有经验的程序员进行测量。在该小组中,不同人员之间生产率的差别最大为 10:1,编程速度和空间上具有 5:1 的差距。简单来说,工资 20000 程序员的生产率可能是 10000 元程序员的 10 倍。而且研究还显示,经验和实际的表现没有相互关系(我怀疑这种现象是否普遍成立)。所以结论很简单,小型精干的队伍是最好的,因为不需要过多的沟通和交流。

可是问题产生了,作者假设一个超过 1000 人工作了 3 年的项目,如果交给一个 200 人的团队,则至少需要 25 年的时间。在面对真正意义上的大型项目时,小型的团队太慢了。譬如有一个 10 人的团队,即便是假设他们都非常能干,是一般人生产率的 7 倍,那么他们需要 10 年来完成 5000 人 * 年的工作。技术可等不了 10 年。

这种进退两难的境地是非常残酷的,对于效率和完整性来说,最好是少数干练人员进行开发,而对于大型系统,则需要大量人手。如何调节这两方面矛盾呢?

建议

Harlan Mills 建议团队应该类似外科手术的方式组建,并非一拥而上。也就是说,由一个人来完成问题的分解,其他人给予他所需要的支持,以提高效率和生产力。

如何运作

首先,首席程序员负责和副手都了解所有的设计和全部的代码。这确保了工作概念上的完整性。

第二,观点不一致之处由首席程序员单方面统一。不对问题进行分解和上下级关系,使得队伍达到客观的一致性。另外,其余只能人员要进行专业化的分工也是高效的关键。

团队的扩建

当我们需要组建几百人参与的大型任务时,应该如何应用外科手术这个概念呢?为了保证概念完整性,决定设计的人员应该是总人数的 1/7 甚至更少,我们仅仅需要协调” 外科医生 “的思路即可。

对于分解技术,我们会在后面的章节继续讨论。整个系统必须具备概念上的完整性,要有一个系统结构师从上至下的进行所有设计。要使工作易于管理,必须清晰的划分体系结构设计之间的界限,系统结构师必须一丝不苟的专注于体系结构。上述的分工是可行的,在实际工作中具有非常高的效率。

以上就是《人月神话》第三章 —— 外科手术队伍所讲述的全部内容

在本章中,作者抛出了整本书的核心概念 —— 概念完整性和结构师

先是告诉了我们,绝大多数大型编程系统的经验显示,一拥而上的开发方式成本高、速度缓慢、效率低,开发出的产品无法进行概念上的集成。而后提供了一种类似于外科手术团队的团队架构,认为这样的架构(首席程序员)能够获得由少数头脑产生的产品完整性,又能拥有多人开发的效率,还彻底减少了沟通成本。

但仅仅是将首席程序员和外科医生作了形象的类比,并没有更深入的解读首席程序员。其实,从第四章到第七章,作者都不断的在论述结构师的重要性,第三章只是作为一个开头,后面我们将更加深入的了解什么是概念完整性,为什么概念完整性是产品质量的核心,以及结构师的必要性。

从第三章开始,我们不难发现(当时还需要用卡片进行输入输出),本书在描述的是 40 年前的软件开发经验,当时还没有传统意义的 PC,编程工作内容和现在也存在着巨大的区别。可为什么《人月神话》看上去仍然和现在的软件实践相关,最常听到的解释就是” 软件开发科学并没有正确的发展 “,通过对比电脑硬件生产的效率和软件生产率能够支持这个观点,前者在 40 年间至少翻了 1000 倍,而软件行业现在还存在大量落后的项目管理方式。

无论出于何种原因,我都热衷于讨论书中的观点,哪些是符合现在情况的,哪些可能已经过时,现在的情况和过去又有什么差别,相信这样的心态也是本书一直畅销的原因之一吧。

转自 fourn - learnku.com

当前页面是本站的「Google AMP」版。查看和发表评论请点击:完整版 »