One of the patterns mentioned in Organizational Patterns of Agile Software Development is titled "Three to Seven Helpers per Role"; it differs from Surgical Team in that it pays attention to every role, for example it isn't only that the surgeon 'role' that has helpers or relationships: all roles have some number of relationships.
Another pattern from the same source in named "Architect Also Implements", which may be analogous to "Surgical Team" in that the Architect in particular is (presumably) highly skilled.
Surgeons are the authority, driving the plan, determining the design, allocating support tasks (viewng them as subservent to coding) and doing the coding. All of those are very command and control in approach and contrary to self directing teams (vs a directed team)
There appears to be no collaboration with the business partner (let alone frequent collaboration with the busines partner)
There appears to be no prioritized product backlog, thus the surgeon picks what is important not the business partner
There appears to be no incrmental delivery (tight feedback loop)
For a waterfall project, it is suggesting to use a team of experts (surgeons) to do the planning, designing, coding etc. and allocating tasks to the "support" staff. On an agile team, testing is not treated as support but an integral part of delivery.
One can't say with certainty the methodology being advocated. However, it does appear to use the language (project plans, tasks) and assume that the waterfall approach is being followed (phases like design, coding, testing driven by a plan). Whatever methodology is being used, it one for which the few determine the work for the many.
I'm not sure any methodology really addresses that, as it is really a matter of prioritizing the developers and bending everything to their needs, rather that being anything about how those developers actually develop their software.
If you were looking for some methodolgy that impements this, I suppose this may be bad news. I prefer to consider it good news, in that it means you can use this approach with pretty much any software development methodology.
I've worked on exactly one project that was run that way. It was so enjoyable, I nearly feel bad calling it "work". Four of us developers (with extra support personell, including the occasional extra junior code monkey) got a truly prodigous amount of code written and running properly in only 9 months. Other places I've been couldn't have done as much with a team of 20.
In the case of a surgeon, the key actor is both the domain expert and the implementor.
I.e., he's both the software program manager (architect) and the developer.
This sort of methodology might fit certain short-burn situations: for instance, a complex operation like a live server migration or software upgrade.
For general development, however, there are a few issues with such "hero" methodologies:
Few key developers understand the problem domain to a sufficient degree, and must rely on domain experts. This is simply a function of specialization--it's tough to find kick-butt programmers who also are lawyers, doctors, accountants, or otherwise are experts in the domain the software is modeling.
Scalability is limited by the number of "surgeons" you have available.
There's a lot of down time for the other staff while they wait on instructions, since the highly-focused "doer" is also managing the team. That's ok in the OR, since you're dealing with a "zero-bug" mandate and "live software." But in this economy, a more distributed workload is more efficient, even if it results in the occasional sync problem between team members.
发布评论
评论（4）
敏捷软件开发的组织模式 标题为“每个角色三到七个助手”； 它与外科团队的不同之处在于它关注每个角色，例如，不仅仅是外科医生“角色”有助手或关系：所有角色都有一定数量的关系。
来自同一来源的另一种模式名为“架构师也实现”，它可能类似于“外科手术团队”，因为架构师（大概）特别熟练。
One of the patterns mentioned in Organizational Patterns of Agile Software Development is titled "Three to Seven Helpers per Role"; it differs from Surgical Team in that it pays attention to every role, for example it isn't only that the surgeon 'role' that has helpers or relationships: all roles have some number of relationships.
Another pattern from the same source in named "Architect Also Implements", which may be analogous to "Surgical Team" in that the Architect in particular is (presumably) highly skilled.
从文本中我看到以下内容：
敏捷式：
非敏捷式：
对于瀑布项目，建议使用专家（外科医生）团队来进行规划、设计、编码等. 并将任务分配给“支持”人员。 在敏捷团队中，测试不被视为支持，而是交付的一个组成部分。
人们无法肯定地说出所提倡的方法论。 然而，它似乎确实使用了语言（项目计划、任务），并假设遵循瀑布方法（由计划驱动的设计、编码、测试等阶段）。 无论使用什么方法，它都是少数人决定多数人工作的方法。
From the text I see the following:
Agile Like:
Non Agile Like:
For a waterfall project, it is suggesting to use a team of experts (surgeons) to do the planning, designing, coding etc. and allocating tasks to the "support" staff. On an agile team, testing is not treated as support but an integral part of delivery.
One can't say with certainty the methodology being advocated. However, it does appear to use the language (project plans, tasks) and assume that the waterfall approach is being followed (phases like design, coding, testing driven by a plan). Whatever methodology is being used, it one for which the few determine the work for the many.
我不确定是否有任何方法论真正解决了这个问题，因为这实际上是一个优先考虑开发人员并根据他们的需求调整一切的问题，而不是关于这些开发人员如何实际开发他们的软件的问题。
如果您正在寻找某种方法来实现这一点，我想这可能是个坏消息。 我更愿意将其视为好消息，因为这意味着您可以将这种方法与几乎任何软件开发方法一起使用。
我曾经参与过一个以这种方式运行的项目。 这太令人愉快了，我几乎感觉不好称其为“工作”。 我们四个开发人员（有额外的支持人员，包括偶尔额外的初级代码猴子）在短短 9 个月内编写了大量代码并正常运行。 我去过的其他地方不可能用一个 20 人的团队做这么多事情。
I'm not sure any methodology really addresses that, as it is really a matter of prioritizing the developers and bending everything to their needs, rather that being anything about how those developers actually develop their software.
If you were looking for some methodolgy that impements this, I suppose this may be bad news. I prefer to consider it good news, in that it means you can use this approach with pretty much any software development methodology.
I've worked on exactly one project that was run that way. It was so enjoyable, I nearly feel bad calling it "work". Four of us developers (with extra support personell, including the occasional extra junior code monkey) got a truly prodigous amount of code written and running properly in only 9 months. Other places I've been couldn't have done as much with a team of 20.
就外科医生而言，关键角色既是领域专家又是实施者。
即，他既是软件程序经理（架构师）又是开发人员。
这种方法可能适合某些短期情况：例如，实时服务器迁移或软件升级等复杂操作。
然而，对于一般开发来说，这种“英雄”方法存在一些问题：
很少有关键开发人员能够充分理解问题领域，并且必须依赖领域专家。 这只是专业化的一个功能——很难找到同时也是律师、医生、会计师或软件建模领域专家的出色程序员。
可扩展性受到可用“外科医生”数量的限制。
其他员工在等待指示时有很多休息时间，因为高度专注的“实干家”也在管理团队。 在手术室中这没有问题，因为您正在处理“零错误”任务和“实时软件”。 但在这种经济环境下，工作量更加分散会更加高效，即使这会导致团队成员之间偶尔出现同步问题。
In the case of a surgeon, the key actor is both the domain expert and the implementor.
I.e., he's both the software program manager (architect) and the developer.
This sort of methodology might fit certain short-burn situations: for instance, a complex operation like a live server migration or software upgrade.
For general development, however, there are a few issues with such "hero" methodologies:
Few key developers understand the problem domain to a sufficient degree, and must rely on domain experts. This is simply a function of specialization--it's tough to find kick-butt programmers who also are lawyers, doctors, accountants, or otherwise are experts in the domain the software is modeling.
Scalability is limited by the number of "surgeons" you have available.
There's a lot of down time for the other staff while they wait on instructions, since the highly-focused "doer" is also managing the team. That's ok in the OR, since you're dealing with a "zero-bug" mandate and "live software." But in this economy, a more distributed workload is more efficient, even if it results in the occasional sync problem between team members.