8

神话人月现在很经典，但“手术团队”方法仍然很有趣。哪种方法最接近它或具有相同的本质？

总结外科团队的类比：外科医生了解问题/业务领域并且是专家。当团队中有问题或冲突时，他们是权威。当出现问题时，外科医生之间会相互合作，比如设计，作为一个较小的紧密专家团队。所以本质上他们拥有领域的知识，被委托去做他们认为正确的事情，并做实际的编码？团队的其他成员专注于支持、测试、文档和项目计划，这些都是委派的任务。因此，外科医生也是最熟练/训练有素的资源。

答案可能是项目、编程、设计方法，因为它似乎对主要方法领域都有影响。采购开发中的敏捷、MDA、Extreme？这个问题对于复杂业务领域中的大型软件也更有意义，比如空中交通管制，而不是 COTS 开发人员或通用实用程序。

4

4 回答 4

6

敏捷软件开发的组织模式中提到的模式之一名为“每个角色三到七个助手”；它与 Surgical Team 的不同之处在于它关注每个角色，例如，不仅外科医生的“角色”具有帮助者或关系：所有角色都有一定数量的关系。

来自同一来源的另一种模式名为“Architect Also Implements”，它可能类似于“Surgical Team”，因为建筑师（可能）特别熟练。

于 2009-05-22T18:16:13.077 回答
3

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

即，他既是软件程序经理（架构师）又是开发人员。

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

然而，对于一般开发，这种“英雄”方法存在一些问题：

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

于 2009-05-22T18:34:33.437 回答
1

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

如果您正在寻找一些实现这一点的方法，我想这可能是个坏消息。我更愿意将其视为好消息，因为这意味着您可以将这种方法与几乎任何软件开发方法一起使用。

我从事的正是一个以这种方式运行的项目。这太令人愉快了，我几乎感觉不好称它为“工作”。我们四个开发人员（有额外的支持人员，包括偶尔的额外初级代码猴子）在短短 9 个月内编写并正常运行了大量的代码。我去过的其他地方不可能有一个 20 人的团队做的那么多。

于 2009-05-22T18:20:16.863 回答
0

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.

于 2009-05-22T18:35:23.170 回答