外科手术队伍
常听到软件经理声称自己喜欢一流人才组成的精干的队伍，而不是那些几百人的大型团队，其实我也有同样的想法。不过，还有一个很困难的问题，大型项目的团队应该是怎样的呢？
问题
软件经理很早就认识到优秀程序员和较差程序员之间的生产率差异，研究人员对一组具有经验的程序员进行测量。在该小组中，不同人员之间生产率的差别最大为10：1，编程速度和空间上具有5：1的差距。简单来说，工资20000程序员的生产率可能是10000元程序员的10倍。而且研究还显示，经验和实际的表现没有相互关系（我怀疑这种现象是否普遍成立）。所以结论很简单，小型精干的队伍是最好的，因为不需要过多的沟通和交流。
可是问题产生了，作者假设一个超过1000人工作了3年的项目，如果交给一个200人的团队，则至少需要25年的时间。在面对真正意义上的大型项目时，小型的团队太慢了。譬如有一个10人的团队，即便是假设他们都非常能干，是一般人生产率的7倍，那么他们需要10年来完成5000人*年的工作。技术可等不了10年。
这种进退两难的境地是非常残酷的，对于效率和完整性来说，最好是少数干练人员进行开发，而对于大型系统，则需要大量人手。如何调节这两方面矛盾呢？
建议
Harlan Mills建议团队应该类似外科手术的方式组建，并非一拥而上。也就是说，由一个人来完成问题的分解，其他人给予他所需要的支持，以提高效率和生产力。
- 首席程序员。他亲自定义功能和技术说明，设计程序，编制源代码，测试以及书写文档。他使用结构化的编程语言，负责版本控制。首席程序员要求极高的天分、丰富的经验和大量的系统知识。
- 副手。是首席程序员的后备，能够完成任何一部分工作。他主要是设计的思考者、讨论者和评估人员。这是一种保险机制，避免首席程序员的人为错误。他可能编写代码，但对代码的任何部分，不承担具体的开发职责。
- 管理员。也就是老板，必须在人员、薪酬、办公空间等方面有决定权。在法律、合同、报表和财务方面具有全部责任。
- 编辑。首席程序员负责文档生成，而编辑负责根据首席程序员的草稿或口述，进行分析和重新组织，并监督文档生成。
- 两个文秘。管理员和编辑每个人需要一个文秘，负责那些非产品文件，以及使项目写作一致。
- 程序职员。负责程序的具体输入输出，日志归档保存。
- 工具维护人员。检查所有文件编辑、交互调试的工具，保证机器的可靠性。
- 测试人员。为各个功能设计系统测试用例，辅助日常调试。
- 语言专家。大多数计算机项目中，总有一两个乐于掌握复杂编程语言的人，大家会向他们咨询。
如何运作
首先，首席程序员负责和副手都了解所有的设计和全部的代码。这确保了工作概念上的完整性。第二，观点不一致之处由首席程序员单方面统一。不对问题进行分解和上下级关系，使得队伍达到客观的一致性。另外，其余只能人员要进行专业化的分工也是高效的关键。
团队的扩建
当我们需要组建几百人参与的大型任务时，应该如何应用外科手术这个概念呢？为了保证概念完整性，决定设计的人员应该是总人数的1/7甚至更少，我们仅仅需要协调”外科医生“的思路即可。
对于分解技术，我们会在后面的章节继续讨论。整个系统必须具备概念上的完整性，要有一个系统结构师从上至下的进行所有设计。要使工作易于管理，必须清晰的划分体系结构设计之间的界限，系统结构师必须一丝不苟的专注于体系结构。上述的分工是可行的，在实际工作中具有非常高的效率。
以上就是《人月神话》第三章——外科手术队伍所讲述的全部内容
在本章中，作者抛出了整本书的核心概念——概念完整性和结构师。
先是告诉了我们，绝大多数大型编程系统的经验显示，一拥而上的开发方式成本高、速度缓慢、效率低，开发出的产品无法进行概念上的集成。而后提供了一种类似于外科手术团队的团队架构，认为这样的架构（首席程序员）能够获得由少数头脑产生的产品完整性，又能拥有多人开发的效率，还彻底减少了沟通成本。
但仅仅是将首席程序员和外科医生作了形象的类比，并没有更深入的解读首席程序员。其实，从第四章到第七章，作者都不断的在论述结构师的重要性，第三章只是作为一个开头，后面我们将更加深入的了解什么是概念完整性，为什么概念完整性是产品质量的核心，以及结构师的必要性。
从第三章开始，我们不难发现（当时还需要用卡片进行输入输出），本书在描述的是40年前的软件开发经验，当时还没有传统意义的PC，编程工作内容和现在也存在着巨大的区别。可为什么《人月神话》看上去仍然和现在的软件实践相关，最常听到的解释就是”软件开发科学并没有正确的发展“，通过对比电脑硬件生产的效率和软件生产率能够支持这个观点，前者在40年间至少翻了1000倍，而软件行业现在还存在大量落后的项目管理方式。
无论出于何种原因，我都热衷于讨论书中的观点，哪些是符合现在情况的，哪些可能已经过时，现在的情况和过去又有什么差别，相信这样的心态也是本书一直畅销的原因之一吧。
