问在神话中的人月里，哪种方法最接近外科团队？

EN

Organizational Patterns of Agile Software Development中提到的模式之一是“每个角色三到七个助手”；它与外科团队的不同之处在于它关注每个角色，例如，不仅仅是外科医生的“角色”有助手或关系:所有角色都有一定数量的关系。

来自同一来源的另一个模式名为"Architect Also Implements"，这可能类似于"Surgical Team“，因为架构师(可能)具有很高的技能。

在外科医生的情况下，关键参与者既是领域专家又是实施者。

也就是说，他既是软件项目经理(架构师)又是开发人员。

这种方法可能适合某些短暂的情况:例如，像实时服务器迁移或软件升级这样的复杂操作。

然而，对于一般的开发，这种“英雄”方法有几个问题：

• 很少有关键开发人员对问题领域有足够的了解，他们必须依赖领域专家。这只是一种专业化的功能--很难找到优秀的程序员，他们也是律师、医生、会计或其他领域的专家软件是受“外科医生”数量的限制你有大量的停机时间( available.
• There's )让其他员工在等待指令的同时，因为高度专注的“实干家”也在管理团队。这在OR中是可以的，因为您正在处理“零错误”命令和“活动软件”。但在这种经济情况下，更分布式的工作负载更有效率，即使它会导致团队成员之间偶尔出现同步问题。

我不确定是否有任何方法论真正解决了这个问题，因为这实际上是一个优先考虑开发人员并将一切都满足他们的需求的问题，而不是关于这些开发人员如何实际开发他们的软件的问题。

如果你正在寻找一些方法论来推动这一点，我想这可能是个坏消息。我更愿意认为这是个好消息，因为这意味着你可以在几乎任何软件开发方法中使用这种方法。

我只做过一个以这种方式运行的项目。它是如此的令人愉悦，我几乎感觉很糟糕，我把它叫做“工作”。我们中的四个开发人员(有额外的支持人员，包括偶尔额外的初级代码猴子)在短短9个月内就获得了真正大量的代码并正常运行。在我去过的其他地方，20人的团队做不到这么多。