弗雷德·布鲁克斯（Fred Brooks）的“外科团队”是否有效处理公交因素？
我的团队由4名经验丰富的开发人员组成，致力于大型模块化Windows应用程序（约200 KLoC）。自从项目开始（3年前）以来，我一直专注于核心代码库，尽管我不是团队经理，但已经逐渐转移到半领导开发人员的职位。 我们当前的迭代是高层管理人员要求的高优先级UI刷新，其中涉及对核心代码库的约15项更改。当经理询问时，我估计15项更改中的每项更改都需要不到4个小时来完成，总共不到7个工作日。然后，我自愿参加了这项工作。相反，经理决定将所有15个任务平均分配给所有四个开发人员。 从开始工作的三天里，我观察到两件事： 其他经验不足的团队成员每人完成大约1个或更少的任务。 布鲁克定律的实际应用：我花了大约一半的时间提供帮助（试图指导他们如何使用组件）。结果，我自己只完成了2个任务，而不是预期的5或6个任务。 我担心上班时间太晚，向经理咨询，并再次建议我完成剩余的任务。我的请求被拒绝，并且所述平均分配负载的原因有两个： 限制卡车/公共汽车的因素 -现在提高其他开发人员的技能，以便将来可以将任何工作提供给任何人，而不仅仅是我。 消除“瓶颈”（我）并更快地完成工作。 明确地说，我在以下方面没有问题：a）花时间进行教学，b）接触我的代码的人员，或c）工作安全。实际上，我经常向团队负责人建议，我会在核心代码库的某些方面对其他开发人员进行培训，以降低风险。 在此迭代中，我们还针对了许多高优先级的错误修复程序，因此，如果重新分配工作负载，似乎可以取得更大的进步。 在《神话人月》中，布鲁克斯建议建立一个“ 外科团队 ”，其中每个团队都由领导+副领导（经理和我）以及一些次要角色组成。我觉得我们很自然地会加入这个组织，但我的经理正在与之抗衡。我觉得总线因素已经得到解决（经理在核心代码中很精通），并且瓶颈实际上并不存在（让更多开发人员参与进来不会使工作进展更快）。在这方面，我认为手术团队是件好事。 这些是我的感受，但我不是经验丰富的经理，我们也不必处理公车因素（敲木头）。布鲁克斯说的对吗？您是否曾在公交因素发挥作用的“外科团队”中工作？是否有更好的技术来管理分销专业知识？ 类似问题： 如何同时增加总线系数和专业性？ /software/103718/always-keeping-2-people-expert-on-any-one-chunk-of-code