外科团队
Mills建议每个细分市场一项大工作要解决一个团队，但团队要像外科手术团队那样组织，而不要像屠宰场那样。也就是说，不是每个成员都去解决问题，而是一个人去做，另一个人给了他一切支持，这将提高他的效率和生产力。
这是一个非常有趣的模式是用来组织软件开发团队的，但我从未在其他任何软件工程书中找到它，甚至在任何地方都没有提到。
为什么？
当时的“外科团队”甚至还很不正常？
还是尝试过并失败了？
如果是这样，它怎么失败了？
如果不是，为什么我们在今天的软件项目中看不到这种模式？
#1 楼
我上大学的那一年出现了“神话人月”，用现在的话来说，UUUGE！ :-)您需要了解的是分别是THEN和NOW的软件开发方式。回到“一天”（tm），几乎所有编码都首先在纸上完成，然后在穿孔卡上打孔（您猜对了），然后读入，编译，链接，执行，获得结果，然后重复该过程。 CPU时间是昂贵且有限的资源，您不想浪费它。同样，磁盘空间，磁带驱动器时间等等。在编译上浪费了完美的CPU时间，这会导致（震惊和恐怖！）错误，这是……好，浪费了完美的CPU时间。当时是1975年。当时，弗雷德·布鲁克斯（Fred Brooks）提出他的想法时，那是1960年中后期，CPU时间更加昂贵，内存/磁盘/其他东西甚至更多，等等。手术团队将确保一位超级伟大的Rockstar开发人员不必浪费他的时间在平凡的任务上，例如桌面检查代码，按键打孔，提交作业，等待结果（有时数小时）。 Rockstar Dude开发人员将编写代码。他的团伙/职员/初级开发人员大军本该做世俗的事情。 br />CRT终端和磁盘文件开始取代按键和卡座。计算机时间变得不那么昂贵，多台计算机可用，作业周转时间大大减少。当我上大学时（俄亥俄州牛津的迈阿密大学，'79年级，感谢您提出要求），良好的工作周转时间约为一个小时。在决赛周-四个小时，有时六个小时。 （我们与许多商业公司和大学争夺CPU时间-商业用户获得了优先考虑）。在我高三的时候，到那时迈阿密已经摆脱了“共享计算机”的安排，在校园里安装了自己的IBM 370/145，并且拥有我工作过的出色的HP mini，它充当了RJE工作站的角色，可以用来转变大型机五分钟或更短的时间内完成工作。现在值得在HP上敲入您的代码，将其从HP发送到大型机，扭动手指/抽烟，并在很长时间完成桌面检查代码之前将输出取回。手术团队的基本前提是您（或“管理”，上帝帮助我们所有人）可以确定Rockstar手术开发商Dude。实际上，我怀疑这种可能性。有摇滚明星的开发人员，每个人都知道-研究表明，最好的开发人员和最糟糕的开发人员之间的生产率差异高达2000％-但要确定这个人而又不用他们长时间写代码是很不可能的。知道某人是否是Rockstar开发人员的唯一方法是让他们实际开发代码-但是，如果他们不是Rockstar Surgical Developer Dude，他们将做令人兴奋的事情，例如检查他的代码，将其密钥打入卡中以及将打好的卡片装箱到工作录入部门，然后站着等待结果，以便他们可以将它们装回Rockstar Surgical Developer Dude先生，而不是学习编写真正有效的唯一方法-通过编写代码，调试代码等等。在Day（tm）中，没有编程竞赛，没有Stack Overflow，您没有PC，可以随时在上面编写代码，没有《傻瓜算法》书籍-学习编程的唯一方法是上学并且要学习一些编程知识。但是编程本身并没有受到重视，并且被认为是人们不想做的事情。在我的第一门大学课程（SAN151-系统分析入门，汤姆·史伯（Tom Schaber）博士-谢谢，汤姆:-)时，讲师告诉我们：“ ...我们不得不面对这样一个事实，我们必须花费成为程序员的几年之前，我们就可以成为系统分析师。”我想：“两年？” “我只能这样做两年了！！？”。我很伤心。值得庆幸的是，他错了，从那时起我一直在编写代码。 :-)
外科小组假定程序员是一种相对稀少的资源。实际上花了几年时间，但是随着PC的出现，在80年代初期，编程成为了任何极客都可以参与的事情。计算机的价格开始下降，开发工具的价格开始下降，这一切都成为现实。冰雹Turbo Pascal-按照今天的标准，虽然还不算什么，但是当时它是一个完整的Pascal IDE，售价约40美元，这绝对是疯了！现在，任何人都可以开始编程-如果您买得起计算机，当IBM决定以大约500美元的价格出售PCjr（是的，我的第一台PC是IBM最大的错误之一：-）以摆脱这些火鸡，现金到处都是被束缚的极客，他们跳过了一个月的租金（“是的，我知道，但是我，...打破了我的小伙子，必须接受手术，...嗯，是的，下周，没问题，谢谢，伙计...），然后以低廉的价格吸纳了它们。然后花了比我们为购买附加组件花更多钱才能使用的计算机。（“是的，伙计，下周肯定会...“ :-)。将资源添加到一个较晚的项目中会使它变得更晚。“）他们给您一个茫然的印象-然后继续犯与OS / 360开发过程中所有这些年前完全相同的错误。所有旧的事物又是新的... ：-}
评论
如果有人阅读本书有20周年纪念版，则值得阅读新的序言和新的第19章。尽管20周年纪念版截至2017年已有20多年的历史，但作者指出了其中的一些主张。这个答案经常被匆忙地总结为“全书”，因为“将工程师添加到一个已经很晚的项目中会使其变得更晚了”。
–user22815
17年8月7日在13:44
“ UUGE”到底是什么意思？好的答案，顺便说一句。
–韦恩·康拉德
17年8月8日15:47
@WayneConrad白话的巨大。
–zzzzBov
17年8月8日在16:05
在那段时间是一名IBM系统程序员，在团队中定义非常严格的角色是很常见的，特别是在OS的特定部分。这些角色中的每个人都应该了解或学到所有有关它的知识，并充当其他专家的支持人员。最终，我们为每位员工配备了一支外科团队，每个团队都有自己的专业。
–乔·麦克马洪（Joe McMahon）
17年8月10日在0:27
为了回应您对一遍又一遍地犯相同错误的评论，该书的Wikipedia文章引用了您可能喜欢的作者的话：经理在项目开发中重复此类错误的趋势导致Brooks嘲笑他的书被称为之所以说“软件工程圣经”，是因为“每个人都引用它，有人读过它，而有些人则喜欢它”。
–瑞安
19年7月22日在21:43
#2 楼
该概念的某些方面在今天有时会被实施，而其他方面则可以避免。使团队保持小型化是敏捷方法的基本特征之一，但在敏捷之外也可以实践。
跨职能团队也是敏捷的重要组成部分，但在敏捷之外也很常见。控制系统，软件配置管理系统，变更管理系统，文档管理系统，Wiki，带有工件存储库的连续构建系统等。我的意思是，您真的可以想象雇用一名全职员工打印出源代码，并手动对其进行索引和归档吗？但最近几年典型的跨职能团队的一部分）已被DevOps（将Sysadmin的角色吸收到软件工程师的角色），平台即服务，基础架构即服务等概念所取代，实用程序计算（使Sysadmin成为“别人的问题”）或基础架构即代码（将系统管理转变为软件工程）。
我们今天要避免的方面之一，是最多两个人了解该系统。只有外科医生才能保证完全了解系统，副驾驶员可能会也可能不会。这样得出的总线系数在1到2之间。如果外科医生生病，则该项目已死。期。敏捷的答案是集体代码所有权，这与该模型完全相反：没有人单独负责系统的任何部分。相反，每个人都要对所有事情负责。
最后，该概念中包含了一些过时的假设。例如，即使没有明确说明，团队的建立方式是团队中只有一个人（外科医生）实际上拥有一台计算机。当然，那是因为在撰写本文时，甚至整个团队自己拥有一台计算机（更不用说团队中的一个人）的想法也是一个难题。 （即使在1980年Smalltalk发行时，导致其失败的原因之一是该系统的设置使得每个开发人员和每个用户都有自己的计算机-当时完全无法想象。 >
因此，简而言之：我认为该概念的实现并非完全如所描述的那样，但是它的某些方面确实得到了实现，某些方面被视为不受欢迎并被积极避免，某些方面已过时，有些可能是Good Ideas™，但没人做。
评论
关于倒数第二段，我认为医生应该使用笔和纸来工作，而书记员本来是可以使用计算机的一个团队成员。
–巴特·范·恩根·舍瑙（Bart van Ingen Schenau）
17年8月6日在18:18
“您真的可以想象雇用全职员工打印出源代码，并手动对其进行索引和归档吗？”不，但是我绝对可以想象雇用一名全职员工来管理版本控制和连续构建系统，实际上，在任何中型或大型公司中，这都是规范。实际上，管理Wiki，文档管理系统等是完全独立的，甚至更大的角色，通常有很多技术作家会花全部时间来做专职工作。
–Miles Rout
17年8月6日在22:53
“整个团队将拥有一台计算机……这是一个负担” –在1980年代初期，组织将拥有微型计算机+基于终端的系统，因此，尽管它是同一台计算机，但用户仍然可以平等地使用它。基础和运行自己的程序的能力（假设存在良好的用户隔离和安全性）。
–代
17年8月7日在4:33
1975年，计算机虽然很昂贵，但键击相当便宜。当我第一次编程大型机时（不是在75中，而是在77中），我们将代码写在纸上，将其打孔在卡上，将其传送到检票口，然后定期检查以查看是否已将打印输出送回。 （对我们来说，转弯时间可能是2个小时，在某些地方，转弯时间可能会超过一天。）除了这些任务中的第一个任务，店员会非常方便。直到1979年左右，我才看到码头。
–西奥多·诺维（Theodore Norvell）
17年8月8日在16:15
回复：Smalltalk –不仅每个开发人员和每个用户都应该拥有自己的计算机，而且这些计算机还应该是功能强大的计算机，具有大量内存和GUI。认为“工作站”而不是“ PC”。原始的IBM PC没有运行Smalltalk的能力。在我看来，真是丢脸……
–Bob Jarvis-恢复莫妮卡
17年8月9日在16:20
#3 楼
过去，大学教育是独一无二的，而工程师则是少数人选。计算机非常昂贵，并且团队要使用具有明确的业务投资回报率的项目进行工作。这些不是很常见。发生的事情是微型计算机，无所不在的本科教育以及甚至不需要大学学位才能取得进步的计算机系统。经济学和人工成本的上升。
8：2的支持率：工程师比例的经济学不再有意义。工程师必须得到他们自己的支持。拥有足够的教育和技能，能够有效地与开发团队联系在一起的现代人，代价太高，以至于不能自己进行某种形式的开发。
（一个相关的经济学术语是“服务部门。“）
评论
由于对人工成本上涨的荒谬说法，我投了反对票。如今，即使是专门的工程知识的劳动，今天也比1969年便宜。事实上，当今的劳动力成本更高，这是整个答案的基础，这是错误的说法。
– RibaldEddie
17年8月6日在19:42
@RibaldEddie关于什么？如果将劳动力与生活成本进行比较，那么它就在减少。一个小时的工作可以为您提供比1969年更多的食物/住房
– k_g
17年8月6日在19:58
@k_g确实取决于位置。在通货膨胀方面，在美国的大多数地方，您可以聘用的开发商如今的通货膨胀调整后美元价格要比1969年少。 10k用于运行工厂程序员的工作，后者负责大部分工作。以今天的美元计算，这10k约为65k。今天，让您团队中的大多数开发人员获得65k的收入是一个很好的价格。
– RibaldEddie
17年8月6日在20:23
从本质上讲，该软件的薪资从1969年起就没有变化。鉴于总体通胀和较高的生活成本，如今的开发人员便宜得多。
– RibaldEddie
17年8月6日在21:11
的确，现代经济环境在生产力和廉价劳动力方面的所有好处都已经转移到企业的执行人员和股东级别。正如我所说，即使根据通货膨胀进行调整，软件开发人员的薪水也保持不变，而高管薪酬却比通货膨胀高了数百倍。此外，在许多地方，尤其是在北美西海岸，生活成本的增长速度明显快于通货膨胀率（参见房地产），而专业开发商的薪水却几乎跟不上通货膨胀率。
– RibaldEddie
17年8月6日在21:33
#4 楼
这种模式在我看来就像Mob编程一样：整个小组（质量保证，开发人员甚至产品负责人，如果需要的话）在同一时间同时工作。无需站起来，高度沟通，直接部署到现场。
来自http://codebetter.com/marcushammarberg/2013/08/06/mob-programming/
mob编程的基本概念很简单：整个团队一起工作
一次完成一项任务。也就是说：一个团队–一个
（活动）键盘–一个屏幕（当然是投影仪）。就像
进行全团队对编程一样。 >
评论
那句话基本上就是我在想的：听起来像是结对编程，其中“外科医生”就是我们所说的“驱动程序”，只是比例不同。
–伊兹卡塔
17年8月7日在3:49
在我看来，这将需要外向型，以人为本的胜任软件开发人员。祝您好运。
–Bob Jarvis-恢复莫妮卡
17年8月7日在11:41
来这里说这话；或各种形式的团队自组织。
–马辛
17年8月7日在20:26
@BobJarvis我不同意。我在性格内向的团队中取得了巨大的成功（我认为有些人也包括性格外向的人）。关键是要创造一个让人们感到安全和开放以做出贡献的空间，并愿意为了他们的利益而暂时延长自然倾角。苏珊·凯恩（Susan Cain）的《安静》（Quiet）在理解如何以不同的性格表现得很好方面大有帮助：ted.com/talks/susan_cain_the_power_of_introverts
– David Carboni
17年8月9日在13:15
#5 楼
这种团队模型在第305页的Steve McConnell的“快速开发-驯服野性软件计划”中再次提到。它被称为首席程序员团队。并且计算资源有限。由于天才是罕见的，因此它不受欢迎，并且由于无处不在的计算机和分布式版本控制，我们在手术台上可以容纳很多手。其他参考文献： F.特里。 “生产编程的首席程序员团队管理”，《 IBM系统杂志》，第1卷。 11号1972年1月1日，第56-73页。
Baker，F。Terry和Harlan D. Mills。 “首席程序员团队。” Datamation，第19卷，第12号（1973年12月），第58-61页。
#6 楼
我的猜测是，无论如何，大多数小的自组织团队都会倾向于采用事实上的外科手术团队模型。 ，通常是一名高级（外科医生），一名中级（副驾驶）和几名初级/专家。如今，Brooks提到的外科团队中的某些角色由Scrum管理员，系统管理员或云提供商填补。请记住，当时几乎没有源代码控制，更不用说像git一样强大的功能了。那是您的自组织手术团队。评论
所以基本上，什么都没发生。 +
–哎呀
17年8月6日在22:02
@gordy是和否。您会注意到，在Brook的示例中，极有可能由经理来确定谁是团队中的每个角色，但是在现代敏捷概念中，团队是自我组织的。因此，外科医生或副驾驶员的角色自然会从团队工作方式中消失。我认为这是一个关键的区别：自组织与公司决定。
– RibaldEddie
17年8月6日在23:26
我将“大多数”更改为“一些”。这实际上取决于团队的动力。如果外科医生自上而下的话，那肯定是必须有机成长的，结果将是次优的，所以自组织的+1。
–彼得
17年8月7日14:03
软件之道的说法：#IV-团队之道：好的软件是由工作迅速的小型团队编写的。糟糕的软件是由工作缓慢的大型团队编写的。推论：-团队的最佳规模为1； -团队规模的最大实际价值为3； -对于大于3的团队，（错误）沟通成为一个严重的问题； -对于大于6人的团队，项目完成会受到严重影响。截止日期之前的项目完成很可能即将完成。在这种情况下，更聪明的开发人员将使用该门...这样写成……（BWOOoooonnnggggg !!!）
–Bob Jarvis-恢复莫妮卡
17年8月8日在17:52
#7 楼
HP上有一篇论文提出了类似的建议：每个软件工程师都需要多个管理人员和多个支持人员。
应该有一名技术作家，测试人员，开发人员经理，是每个工程师的工具制造者。每年，它的评论都会从“荒谬可笑”转变为“也许我们应该这样做”。
众所周知，实际测试很难设计，因此它可能仍然是意见。 。可能存在一些项目及其完成率的调查。
评论
使我微笑（？）的部分是“ ...多个经理...”。一位经理足以降低生产力。多个管理人员可能会促使开发人员想到自杀（性格内向）或谋杀（性格外向）。
–Bob Jarvis-恢复莫妮卡
17年8月7日在11:41
@BobJarvis-根据项目的不同，我曾经有多达五名同时担任“经理”，职务不同。效果几乎与您想象的一样。
–罗布·克劳福德
17年8月7日在14:03
显然你是一个外向的人。那么...精神错乱防御？墨西哥？或者...合理的杀人罪..？ :-)
–Bob Jarvis-恢复莫妮卡
17年8月8日在17:56
这就是为什么我在一家公司有五个老板。当我在那里的时候，无论是我的还是其他人的任何问题，我都会从5个不同的角度听到。通常我会根据出现的时间2来分析它，并且听到更多次只是令人讨厌。
–罗伯特·巴伦（Robert Baron）
17年8月9日在11:29
最初的想法不是“让五个不同的经理试图干预”，而是提供例如“人力资源福利人员”和“人力资源职业发展人员”等。我认为如果您根据每个经理的部门向其开帐单，则多个经理会工作他们多久联系一次工程师。会做一个有趣的视频游戏！
–查尔斯·梅里亚姆
17年8月25日在21:46
#8 楼
我想知道，由于互联网，集成开发环境和软件开发工具包的兴起，对外科手术团队的需求有多少变得多余了，这些功能可以承担归因于外科手术团队的许多功能，包括： br />外科医生：程序员
副驾驶：结对程序员，同事，在线社区（如StackExchange或IRC）
管理员：通常由软件项目承担的角色manager
编辑器：集成了文档生成器（如Javadoc或Doxygen）的IDE；软件开发套件中的文档
秘书：电子邮件客户端，项目管理工具（例如问题跟踪器和拉取请求，公司聊天室和邮件列表）
程序职员：IDE存储有关项目设计的信息，并添加了重构代码的能力；软件开发套件中的文档和示例
Toolsmith：整个开源社区
Tester：立即提供测试套件和测试库。但是，当然对于生产代码而言，需要单独的质量检查流程。
语言律师：在线文档，StackExchange
#9 楼
我认为您需要了解《神话人月》的前提。雇用更多的程序员只会使有问题的/过期的软件项目变得更糟。问题在于沟通，使新加入的程序员加快项目速度（从现有开发中抽出时间），技术以及领域本身。协调。假设您聘请了一名技术X顾问。与其让该顾问加快项目速度，以使该人员可以完成该领域的所有编码，不如说他只是在指导现有的开发人员，使他可以构建一些东西。在某些监督下。团队将工作分散，每个人都去做自己的事情。结对编程，评论以及任何带有微管理气味的东西都被皱眉了。许多人不认为编程是一项团队运动。一个人在解决给定问题时会考虑整体约束。#10 楼
我会说，我们越是将设计，实施，测试，文档，构建，部署，操作等划分为由专家完成的独特角色，我们就越遵循“外科团队”的理念（尽管可能不是完全按照所描述的方式）。以我的经验，每个人都应该有能力执行每项任务的devOps理念是对猪屠宰模型的回归（并不是说它很糟糕，只是有所不同）。 >
评论
绝对不是DevOps模型。
– RibaldEddie
17年8月6日在18:27
实际上，DevOps更像是外科手术团队模型，因为开发人员运营意味着运营存在于为开发服务中。 DevOps涉及两个核心概念：应将操作视为一种开发实践，因此，操作应使用开发中使用的工具和技术（例如源代码控制和敏捷管理方法），并且那里的操作可以支持开发。
– RibaldEddie
17年8月6日在18:30
@RibaldEddie有趣。我在我公司的DevOps小组的经验是，他们仅雇用开发人员，并且他们负责产品开发，测试，文档，部署等所有工作。想到“跨功能”一词。哦，好吧，我有15分钟之内2票赞成票和1票删除票，我想我将远离这个站点。
–麦克·恩斯沃思（Mike Ounsworth）
17年8月6日在18:35
嗯，那么我们对“跨功能”有不同的定义。我用它的意思是团队中的每个成员都有能力完成每项任务-Jiras通常会在人与人之间四处乱扔，因为他们已经放弃了专业化。正在开发此功能的人员将测试或记录下一个功能。那就是我经历过的“ DevOps”。
–麦克·恩斯沃思（Mike Ounsworth）
17年8月6日在18:48
@MikeOunsworth：这是一个跨职能团队：-D
–‐Jörg W Mittag
17年8月8日在20:16
#11 楼
作为一个经常担当DevOps和Build Master角色的程序员，我觉得我经常最终成为外科团队的一员。作为构建大师，我对整个代码进行了概述，并且在失败时是第一行。我经常是自己编写这些度量标准系统，并测量代码中的热点，经常失败的部分，引起最多错误报告的人。对团队的结果，我也将对其进行分析，找到引起问题的纽结，并提出解决方案和体系结构更改以解决此问题。
作为DevOps，我将自动化大量的过程和开销。我研究的技术和工具可以使团队，整个团队，开发人员，质量检查测试人员的工作变得更加轻松。但是通过使用（痛苦的）过程使我的视线集中在团队（实际的人）上，我能够将其分解为使其完全透明的点，同时仍然获得了大量有用的数据以客观地了解该过程。永远难以捉摸的“大图景”。我知道当没有人注意到该过程，没有人考虑构建管道时，我的工作做得很好。因此，是的，涂油的机器很快就会被视为理所当然。但是我知道，事实上，我衡量了这项工作对团队生产力产生的乘法影响，这是值得投资的。
所以，我认为今天的角色仍然非常活跃，尽管可以肯定的是它确实是从那时开始发展的。
评论
我会说这只能带来基于意见的答案。我的观点是，任何“软件工程师”都不想被视为“支持”角色。他们希望被视为与团队中的其他人平等。这可能与以下事实有关：大多数软件开发人员都非常年轻。大多数团队没有任何人可以宣称自己的资历并被视为团队的“外科医生”。当您有意组建一支团队时，我看到的一个潜在问题是正确确定外科医生应该是谁。
@Euphoric不要忘了一些自欺欺人的管理者，以为他们已经有了他们的超级特级专家星际程序员，那么为什么要首先雇用所有这些支持农民的人呢？我所见过的管理人员中的一部分，在“管理”软件团队时，没有显示出了解软件开发及其固有挑战的证据，不幸的是（通常，尽管并非总是如此，接近退休的人们） ）。
“外科手术”是医学上最落后的分支之一，这可能与以下事实有关：确实，这是英国众所周知的笑话，外科医生花费了7年的时间研究才能被称为“医生”然后又是7年，这样他们就可以再次称为“先生”或“太太”！实际上，通过遵循具有较低错误率等的其他行业的“最佳实践”（尤其是民用航空）来重组手术以提高其性能是医学界正在进行的一项工作。 ...
@alephzero：有几个有趣的说法。您到底在哪里做手术？在这里，您称之为“最佳实践”的废话占据了外科医生的大部分时间，并且产生了零收益。超级聪明的人[ironic]几乎每周都会尝试通过添加更多官僚废话来努力改善他们不了解的事情。相反，您提到的故障率的原因没有得到解决。几乎所有失败都是由于睡眠不足，教育不足和高估造成的。通常三个人都在一起。