外科手术队伍
优秀和较差程序员的生产率差多少？
- 数据: Sackman、Erikson 和 Grant 对一组有经验的程序员测量, 最好与最差的生产率平均为 10:1;
- 运行速度和空间上: 差异达 5:1;
- 换算: 20,000 美元/年的程序员生产率可能是 10,000 美元/年的 10 倍;
- 反直觉: 数据显示经验和实际表现之间没有相互联系（作者怀疑这是否普遍成立）;
为什么不能靠"全用高手"解决大型系统？
- 直觉方案: 200 人项目中留下 25 个最能干的经理去编程, 开除其余 175 人;
- 方案一的问题: 25 人超过"小型精干团队不超过 10 人"的共识, 至少需要两层管理和额外支持;
- 方案二的问题: 一拥而上的方法下, 200 人仍不足以开发真正的大型系统;
- OS/360 尺度: 顶峰超过 1000 人参与, 1963-1966 年设计、编码和文档约花 5000 人年;
- 10 人精英队伍的算术: 即使每人生产率 7 倍、沟通节省又 7 倍,
5000/(10×7×7)=10年--产品 10 年后才出现是否还有人感兴趣; - 残酷的两难: 效率和概念完整性偏好少数干练人员, 大型系统的进度要求又需要大量人手;
Mills 的外科手术队伍由哪些角色组成？
- 核心思想: 由一个人分解问题, 其他人给予他支持以提高其效率和生产力, 而不是每人截取问题的一部分;
- 角色分工:
| 角色 | 职责 |
|---|---|
| 外科医生（首席程序员） | 亲自定义功能和性能技术说明、设计程序、编制源码、测试、写技术文档; 需极高天分和十年经验 |
| 副手 | 后备; 作为设计的思考者、讨论者和评估者; 代表小组参与接口讨论; 了解全部代码但不承担具体开发职责 |
| 管理员 | 控制财务、人员、工作地点和机器, 充当与其他管理机构的接口; 小项目可为两个团队共用 |
| 编辑 | 根据外科医生的草稿或口述进行分析重组, 提供参考信息和书目, 维护版本并监督文档生成 |
| 两个秘书 | 分别服务管理员和编辑 |
| 程序职员 | 维护产品库中所有团队的技术记录; 管理机器码文件和可读文件, 归档输出, 记录状态日志 |
| 工具维护人员 | 保证基本服务可靠, 并构建、维护、升级团队成员需要的特殊工具 |
| 测试人员 | 为各功能设计系统测试用例, 为日常调试设计测试数据, 计划测试步骤并搭建测试平台 |
| 语言专家 | 寻找简洁有效的语言用法解决复杂晦涩问题; 一个语言专家可服务两到三个外科医生 |
- 关键转变: "从个人艺术到公共实践"的编程观念--所有程序和数据是团队所有物, 而非私人财产;
- 程序职员的意义: 把程序员从书记杂事中解放出来, 同时系统整理这些杂事, 强化团队最有价值的财富--工作产品;
外科手术队伍和传统两人队伍有什么本质区别？
| 维度 | 传统团队 | 外科手术队伍 |
|---|---|---|
| 工作划分 | 每人负责一部分工作的设计和实现 | 外科医生和副手都了解全部设计和全部代码 |
| 决策方式 | 大家平等, 观点不同就要讨论、妥协、让步 | 不存在利益差别, 不一致由外科医生单方面统一 |
| 结果 | 不同意见造成策略和接口不一致, 最终必须整合 | 客观上达到概念一致性 |
| 沟通 | 沟通模式复杂 | 剩余人员职能专业化, 使交流模式非常简单 |
- 附带收益: 不做问题分解节省了空间分配、磁盘访问等劳动量;
- 规模: 10 人队伍中只有 7 个专业人士在解决问题, 系统是一个人（最多两个人）思考的产物;
外科手术队伍如何扩展到几百人的项目？
- 依据: 每个部分的概念完整性被彻底提高--决定设计的人员只有原来的七分之一或更少;
- 做法: 200 人解决问题, 但只需协调 20 个"外科医生"的思路;
- 前提: 整个系统必须有概念上的完整性, 由一位系统结构师从上至下进行设计;
- 界线: 必须清晰划分体系结构设计和实现之间的界线, 系统结构师一丝不苟地专注于体系结构;