“神话人月”的“手术团队”模式发生了什么？

几年前，当我读《神话人月》时，我发现了很多我已经从其他来源知道的东西。但是，尽管那本书是1975年的，但那里还是有新事物。其中之一是：

手术团队

Mills建议将大型工作的每个部分都安排到一个团队中，但该团队的组织应像外科手术团队一样，而不是生猪屠宰团队。就是说，不是每个成员都去解决问题，而是一个人去削减，其他人给他提供一切支持，这将提高他的效率和生产力。

对于组织软件开发团队来说，这是一个非常有趣的模式，但是我从未在任何其他软件工程书中找到它，甚至在任何地方都没有提及。

这是为什么？

• 当时的“手术团队”是否还很特别？
• 还是尝试过并失败了？
  • 如果是这样，它是怎么失败的？
  • 如果不是，为什么我们今天的软件项目中看不到这种模式呢？

我上大学的那一年出现了“神话人月”，用现在的话来说，UUUGE！:-)您需要了解的是分别是THEN和NOW的软件开发方式。回到今天（tm），几乎所有编码都是先在纸上完成的，然后将其打孔到（您猜对了）打孔卡上，然后读入，编译，链接，执行，获得结果，然后重复该过程。CPU时间很昂贵和有限的资源，您不想浪费它。同样，磁盘空间，磁带驱动器时间等等。在编译上浪费了完美的CPU时间，这会导致（震惊和恐怖！）错误，这是……好，浪费了完美的CPU时间。那是在1975年。当时，弗雷德·布鲁克斯（Fred Brooks）提出他的想法时，那是1960年中后期，CPU时间甚至更多。昂贵，内存/磁盘/任何东西甚至更多的限制，等等，等等。The Surgical Team的想法是确保一个超级伟大的Rockstar Developer不必在诸如桌面检查代码，按键打孔，提交工作，等待（有时需要几个小时）以取得结果。Rockstar Dude开发人员将编写代码。他的团伙/职员/初级开发人员大军本来应该做平凡的事。

问题在于，在布鲁克斯的书出版后不到两年的时间里，“外科团队”的基本思想就破裂了：

1. CRT终端和磁盘文件开始取代按键和卡座。计算机时间变得不那么昂贵，多台计算机可用，作业周转时间大大减少。当我上大学（迈阿密大学，牛津大学，俄亥俄州，类'79，感谢要求）好工作周转大约一个小时。在决赛周-四个小时，有时六个小时。（我们与许多商业公司和大学争夺CPU时间-商业用户获得了优先考虑）。在我高三的时候，到那时迈阿密已经脱离了“共享计算机”的安排，在校园里安装了自己的IBM 370/145，并且拥有我工作过的出色的HP mini，它充当了RJE工作站的角色，我们可以将大型机转为大型机。五分钟或更短的时间内完成工作。现在值得在HP上敲入您的代码，将其从HP发送到大型机，扭动手指/抽烟，并在很长时间之前完成输出检查之前就将输出取回。

2. 手术团队的基本前提是您（或“管理”，上帝帮助我们所有人）可以确定Rockstar手术开发商Dude。实际上，我怀疑这是可能的。这里是 Rockstar的开发人员，每个人都知道这一点-研究证明高达2000％，最好的和最差的开发商之间的生产率差异-但鉴定人，而不需要编写代码，在一段长时间是最不可能的。知道某人是否是Rockstar开发人员的唯一方法是让他们实际开发代码-但是，如果他们不是Rockstar Surgical Developer Dude，他们将做令人兴奋的事情，例如对他的代码进行桌面检查，将其密钥打入卡中，以及将打好的卡片装箱到工作录入部门，然后站着等待结果，以便他们可以将它们装回Rockstar外科手术开发人员杜德先生，而不是学习编写真正有效的唯一方法-通过编写代码，调试代码，等等。在Day（tm）中，没有编程竞赛，没有Stack Overflow，您没有PC，可以随时随地编写代码，没有《傻瓜算法》一书-学习编程的唯一方法是上学并主修一些需要进行一些编程的工作。但是编程本身并没有被认真对待，它被认为是人们不想做的事情。在我的第一门大学课程（SAN151-系统分析入门，汤姆·史伯（Tom Schaber）博士-谢谢，汤姆:-)时，讲师告诉我们：“ ...我们不得不面对这样一个事实，我们必须花费成为程序员两年后，我们才能成为系统分析师。” 我想：“两年？” “我只能这样做两年了！！？”。我认真地郁闷。值得庆幸的是，他错了，从那时起我一直在编写代码。:-)

3. 外科团队假定程序员是一种相对稀少的资源。实际上花了几年时间，但是随着PC的出现，在80年代初期，编程成为了任何极客都可以参与的事情。计算机的价格开始下降，开发工具的价格开始下降，这一切都成为现实。冰雹Turbo Pascal-按照今天的标准，虽然还不多，但是当时它是一个完整的Pascal IDE，售价约40美元，这绝对是疯了！现在，任何人都可以开始编程-如果您买得起计算机，当IBM决定以大约500美元的价格出售PCjr（是的，我的第一台PC是IBM最大的错误之一：-）以摆脱这些火鸡，现金遍布各地的极客们跳过了一个月的房租付款（“是的，嗯，我知道，但是我，嗯...打破了我的小伙子，必须接受手术，并且.. .uh ...是的，下个星期，没问题，谢谢，伙计...），以火热的价格吸食了他们​​。然后花费超过我们为购买附件而为计算机支付的费用，以使其可用。（“是的，伙计，下周，肯定是……” ：-）。

让我感到非常难过的是，即使在今天，如果您问人们是否读过“神话般的月”或了解其主要课程（“向较晚的项目添加资源会使其以后”），他们还是给您空白。凝视-然后继续进行与OS / 360开发过程中所有这些年前完全相同的错误。旧的一切又都是新的...：-}

有一些概念的某些方面是今天有时落实，存在的其他方面避免。

保持团队规模小是敏捷方法的基本特征之一，但在敏捷之外也可以实践。

跨职能团队也是敏捷的主要组成部分，但在敏捷之外也很常见。

程序文员的角色主要由诸如版本控制系统，软件配置管理系统，变更管理系统，文档管理系统，Wiki，带有工件存储库的连续构建系统等计算机化系统所承担。我的意思是，您真的可以想象雇用一名全职员工打印出源代码，并手动对其进行索引和归档吗？

同样，DevOps之类的概念已淘汰了系统管理员（不是Mills外科团队的一部分，而是过去一个典型的跨职能团队的一部分）的角色（将Sysadmin的角色吸收为软件工程师的角色） ，平台即服务，基础架构即服务和实用程序计算（使Sysadmin成为“别人的问题”）或基础架构即代码（将系统管理转变为软件工程）。

我们今天要避免的方面之一是，最多两个人了解该系统。只有外科医生才能保证完全了解系统，副驾驶员可能会也可能不会。这样得出的总线系数在1到2之间。如果外科医生生病，则该项目已死。期。敏捷的答案是集体代码所有权，它与该模型完全相反：没有人单独负责系统的任何部分。取而代之的是，每个人都负责一切 为一组。

最后，该概念中包含了一些过时的假设。例如，即使没有明确说明，团队的建立方式是团队中只有一个人（外科医生）实际上拥有一台计算机。那当然是因为在撰写本文时，甚至整个团队自己拥有一台计算机，更不用说团队中的一个人的想法了。（即使在1980年Smalltalk发布时，导致其失败的原因之一是该系统的设置使得每个开发人员和每个用户都有自己的计算机，这在当时是完全不可想象的。）

因此，简而言之：我认为该概念的实现方式并非完全如所描述的那样，但是确实可以实现它的某些方面，某些方面被视为不受欢迎且应避免，某些方面已过时，有些则可能是Good Ideas™，但是没有人做。

过去，大学教育是独一无二的，而工程师则是少数人选。电脑很昂贵，并且团队要按照定义的业务投资回报率来从事项目。这些不是很常见。

发生的事情是微型计算机，无所不在的本科教育以及甚至不需要大学学位才能取得进步的计算机系统。另外，发生的事情是经济发生了变化，劳动力成本不断上升。

8：2支持比例：工程师比例的经济意义已不复存在。工程师必须得到他们自己的支持。一个拥有足够的教育和技能，能够有效地与开发团队建立联系的现代人，代价太高，无法进行自己的某种形式的开发。

（一个相关的经济学术语是“服务业的成本病”。）

这种模式对我来说就像Mob编程一样：

整个团队（质量保证，开发人员，甚至产品负责人，如果需要的话）都在同一时间解决同一问题。无需站起来，高度沟通，直接部署到现场。

从http://codebetter.com/marcushammarberg/2013/08/06/mob-programming/

暴民编程的基本概念很简单：整个团队当时以团队的形式共同完成一项任务。也就是说：一个团队–一个（活动）键盘–一个屏幕（当然是投影仪）。就像进行全团队对编程一样。

在此处查看实际效果：https：//www.youtube.com/watch？v = dVqUcNKVbYg

此团队模型在第305页的Steve McConnell的“快速开发-驯服野性软件时间表”中再次提到。在这里，它被称为首席程序员团队。

之所以出现这种模型，是因为团队有天才，并且计算资源有限。由于天才很少，因此它不受欢迎，并且由于使用了无处不在的计算机和分布式版本控制，我们在手术台上可以容纳很多手。

其他参考：

贝克，特里。“生产编程的首席程序员团队管理”，《 IBM系统杂志》，第1卷。11号 1972年1月，第56-73页。

贝克，F。特里和哈兰·米尔斯。“首席程序员团队。” 数据通讯，第19卷，第12号（1973年12月），第58-61页。

我的猜测是，无论如何，大多数小型自组织团队都倾向于建立事实上的外科团队模型。

我参加的最后两支队伍通常由三到四人组成，通常是一名高级（外科医生），一名中级（副驾驶员）和几名初级/专家级人员。如今，Brooks提到的外科团队中的某些角色由Scrum管理员，系统管理员或云提供商填补。请记住，当时几乎没有源代码控制，更不用说像git这样强大的功能了。

想想贝佐斯的两个比萨饼规则。那就是您的自组织手术团队。

惠普的一篇论文提出了类似的建议：

• 每个软件工程师将需要多个经理和多个支持人员。
• 每个工程师都应该有一名技术作家，测试人员，构建经理和工具制造商。

这篇论文是在网络发布前的日子，时常被认为很有趣。每年，它的评论都从“荒谬可笑”转变为“也许我们应该这样做”。

众所周知，实际测试很难设计，因此它可能仍然是人们的看法。可能存在一些项目及其完成率的调查。

我想知道，由于互联网，集成开发环境和软件开发套件的兴起，对外科手术团队的需求有多少变得多余了，这些功能可以承担归因于外科手术团队的许多功能，包括：

• 外科医生：程序员
• 副驾驶：结对程序员，同事，在线社区，例如StackExchange或IRC
• 管理员：通常由软件项目经理担任的角色
• 编辑器：集成了Javadoc或Doxygen等文档生成器的IDE；软件开发套件中的文档
• 秘书：电子邮件客户端，项目管理工具（例如问题跟踪程序和请求请求），公司聊天室和邮件列表
• 程序职员：IDE存储有关项目设计的信息，并具有重构代码的附加功能；软件开发套件中的文档和示例
• 工具匠：整个开源社区
• 测试人员：立即提供测试套件和测试库。但是，当然对于生产代码而言，需要单独的质量检查流程。
• 语言律师：在线文档，StackExchange

我认为您需要了解《神话人月》的前提。雇用更多的程序员只会使有问题的/过期的软件项目变得更糟。问题在于沟通，使新加入的程序员加快项目速度（从现有开发中抽出时间），技术，有时甚至是领域本身。

一个受良好支持的程序员消除了许多通信时间和协调。假设您聘请了一名技术X顾问。与其让该顾问加快项目速度，以使该人员可以完成该领域的所有编码，不如说他只是在指导现有的开发人员，使他可以构建一些东西。在一些监督下。

您看不到太多的原因之一是因为大多数软件还是由一个人编写的。团队将工作分散，每个人都去做自己的事情。结对编程，评论以及任何带有微管理气味的东西都被皱眉了。许多人不认为编程是一项团队运动。一个人解决了给定的问题时会考虑整体约束。

我会说，我们越是将设计，实施，测试，文档，构建，部署，操作等划分为由专家完成的独特角色，我们就越遵循“外科团队”的理念（尽管可能不是完全按照所描述的方式进行） ）。

以我的经验，每个人都应该有能力执行每项任务的devOps理念是对猪屠宰模型的回归（并不是说它很糟糕，只是有所不同）。

作为一个经常担当DevOps和Build Master角色的程序员，我感到我常常最终成为外科团队的一员。作为构建高手，我对整个代码进行了概述，并且是失败时的第一行。通常我会自己修复。
我经常是写这些度量标准系统并测量代码中的热点的人，这些热点经常发生故障，吸引了最多的错误报告，等等。我不只是将结果发布给团队，我也会对其进行分析，找到导致问题的纠结，并提出解决方案和体系结构更改以解决此问题。

作为DevOps，我将自动化大量的过程和开销。我将研究使团队，整个团队，从开发人员到QA测试人员的整个过程变得更加轻松的技术和工具，从IT一直到管理。我的职责是了解流程，是的。但是通过使用（痛苦的）过程使我的视线集中在团队（实际的人）上，我能够将其分解为使其完全透明的点，同时仍然获得了大量有用的数据以客观地了解该过程。难以捉摸的“大局”。

拥有它，这可能是一个忘恩负义的立场，并且为什么会如此之大。我知道当没有人注意到该过程并且没有人考虑构建管道时，我的工作做得很好。所以是的，一台注油的机器很快就被视为理所当然。但是我知道，事实上，我衡量了这项工作对团队生产力的成倍影响，这是值得投资的。

所以是的，我认为今天的角色仍然非常活跃，尽管可以肯定的是，它确实是从那时开始发展的。