第3章 外科手术队伍

第三章 外科手术队伍

标签： 人月神话

这些研究表明，效率高和效率低的实施者之间个体差异非常大，经常能够达到数量级的水平

第三章 外科手术队伍

问题

Mills的建议

如何运作

团队的扩建

如何在有意义的进度安排内创建大型的系统？

问题

观点：需要协作沟通的人员数量影响着开发成本，因为成本的主要组成部分是相互的沟通和交流，以及更正沟通不当所引起的不良后果（系统调试）。这一点，也暗示系统应该由尽可能少的人员来开发。

实际上，绝大多数大型编程系统的经验显示出，一拥而上的开发方法是高成本的、速度缓慢的、低效的，开发出的是无法在概念上进行集成的产品

小型、精干队伍概念上的问题：对于真正意义上的大型系统，他们工作太慢了。（设想OS/360的工作由一个小型、精干的团队来解决，譬如一个10人的团队，他们都非常能干，但是他们需要10年来完成5000人年的工作。一个产品在最初设计的10年后才出现，还有人会对它们感兴趣吗？或者它是否会随着软件开发技术的快速进步，而显得过时呢？）

这种进退两难的境地是非常残酷的。对于效率和概念的完整性来说，最好由少数干练的人员来设计和开发，而对于大型系统，则需要大量的人手，以使产品能在时间上满足要求。如何调和这两方面的矛盾呢？

Mills的建议

建议大型项目的每一个部分由一个团队解决，但是该队伍以类似外科手术的方式组建，而非一拥而上。也就是说，同每个成员截取问题某个部分的做法相反，由一个人来完成问题的分解，其他人给予他所需要的支持。

如果考虑所有可能想到的工作，这样的队伍应该如何运作？

外科医生（首席程序员）：亲自定义功能和性能技术说明书，设计程序，编制源代码，测试以及书写技术文档。（需要有极高的天分，丰富的经验和应用数学、业务数据处理或其他方面的大量系统知识和应用知识）

副手：作为设计的思考者、讨论者和评估人员。

管理员：老板，必须在人员、薪酬、办公空间等方面具有决定权

编辑：根据外科医生的草稿或者口述，进行分析和重新组织，提供各种参考信息和书目，对多个版本进行维护，并监督文档生成的机制。

两个文秘：

程序职员：维护编程产品库中所有团队的技术记录

工具维护人员：对编辑工具，开发工具，环境，机器等的维护

测试人员：

语言专家：懂得很多语言，语言专家，知道哪些语言最适合做什么，为外科医生服务

以上是如何参照外科手术队伍对10人的编程团队进行专业化的角色分工。

如何运作

文中定义的开发团队在很多方面满足了迫切性的需要。10个人，其中7个专业人士在解决问题，而系统是一个人或者最多两个人思考的产物，因此其在客观上达到了概念的一致性

传统的两人队伍与“外科医生——副手”的一些区别：

传统的队伍将工作进行划分，每人负责一部分工作的设计和实现（大家是平等的）

在外科手术团队中，外科医生和副手都了解所有的设计和全部的代码，不存在利益关系，观点的不一致之处可以有外科医生单方面来统一（上下级关系）

团队的扩建

如何完成500个人/年的项目？

扩建过程的成功依赖于这样的事实，即每个部分的概念完整性得到了彻底的提高————决定设计人员是原来的1/7或更少。所以，可以让200人去解决问题，而仅仅需要协调20个人，即那些“外科医生”的思路。