What methodology is closest to the Surgical Team i

问题:

The Mythical Man-Month is now classic, but the "Surgical Team" methodology is still interesting. What methodology most closely resembles it or has the same essence?

To summarize the Surgical Team analogy: A surgeon understands the problem/business domain and is the expert. They are the authority when there are questions or conflict with in the team. The surgeons work between themselves when there are issues, say with design, functioning as a smaller tight team of experts. So in essence they have the knowledge of the domain, are entrusted to do they think is right, and do the actual coding? The rest of the team focuses on support, testing, documentation, and project plans are delegated tasks. Consequently the surgeon is also the most skilled/trained resource.

The answer could be project, programming, design methodologies as it seems to have implications across main methodology domains. Agile, MDA, Extreme, in sourcing development? This question also make more sense for software that is large in a complex business domain, think air traffic control, not a COTS developer to or common utility.

回答1:

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.

回答2:

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.

回答3:

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.

回答4:

From the text I see the following:

Agile Like:

• Small teams focused on solving specific problems
• Collaboration among the surgeions

Non Agile Like:

• 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.