哪种方法论最接近于《人月神话》中的外科手术团队？

Question

哪种方法论最接近于《人月神话》中的外科手术团队？

agilemethodologyextreme-programmingwaterfallmda

8

神话般的人月神话已经成为经典，但是“外科手术团队”方法仍然很有趣。什么方法最接近它或具有相同的精髓呢？

简要概括外科手术团队的类比：外科医生了解问题/业务领域并是专家。当团队内出现问题或冲突时，他们是权威。外科医生在设计等方面遇到问题时会相互协作，作为一个更小的紧密专家团队。所以从本质上讲，他们拥有该领域的知识，被委托去做他们认为正确的事情，实际进行编码工作。团队的其他成员则专注于支持、测试、文档和项目计划的委派任务。因此，外科医生也是最熟练/受过培训的资源。

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

- Ted Johnson

1

在TMM中，外科医生呈现出一种不稳定的Bus Factor。如果你还没有看过的话，我建议阅读Dave Thomas的文章，标题为《敏捷已死》（Agile is Dead）[https://news.ycombinator.com/item?id=7377798]，并考虑软件敏捷性的四个价值观之一——即“可工作的软件”。 - vhs

4个回答

3

在外科医生的情况下，关键参与者既是领域专家，也是执行者。换句话说，他既是软件程序经理(架构师)，也是开发人员。

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

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

- 为数不多的关键开发人员无法充分了解问题领域，必须依靠领域专家。这只是专业化的一个方面——很难找到既是律师、医生、会计师，又是软件所模拟领域的专家的全才程序员。 - 可扩展性受限于可用的"外科医生"数量。 - 当高度专注的“执行者”同时管理团队时，其他员工需要等待指示的时间很长。在手术室中这没关系，因为你要满足“零缺陷”的要求和“现场软件”的特点。但在当前的经济环境下，即使偶尔会导致团队成员之间的同步问题，分布式工作量更有效率。

- richardtallent

2

我并不认为你的第三个要点是一个问题。目标并不是让每个人都一直忙碌。目标是更快、更便宜地生产出同样质量的软件。 - T.E.D.

1

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

如果您正在寻找实现此目标的某种方法，我想这可能是个坏消息。我更喜欢将其视为“好消息”，因为这意味着您可以在几乎任何软件开发方法论中使用此方法。

我曾经参与过一个完全按照这种方式运行的项目。它非常愉快，我几乎觉得称其为“工作”有些不妥。我们四名开发人员（配备额外的支持人员，包括偶尔的初级代码猴子）在仅9个月内编写了大量的代码，并使其正常运行。其他地方即使有20人的团队也无法做到这么多。

- T.E.D.

0

从这段文字中我看到以下内容:

类敏捷:

小团队专注于解决特定问题
外科医生之间的协作

非类敏捷:

外科医生是权威，推动计划，确定设计，分配支持任务（视它们为服务于编码）并进行编码。所有这些都采取了命令和控制的方法，与自主指导团队相反
似乎没有与业务合作伙伴的协作（更不用说经常与业务合作伙伴协作了）
似乎没有优先级产品待办事项清单，因此外科医生选择重要的事情而不是业务合作伙伴
似乎没有增量交付（紧密的反馈循环）

对于瀑布项目，建议使用专家团队（外科医生）进行规划、设计、编码等，并将任务分配给“支持”人员。在敏捷团队中，测试不是支持而是交付的一个组成部分。

无法确定所倡导的方法论。然而，它似乎使用了语言（项目计划、任务），并假定采用瀑布式方法（设计、编码、测试等阶段由计划驱动）。无论使用何种方法，都是少数人决定了大多数人的工作。

- Cam Wolff

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- ChrisW · Accepted Answer

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

另一个来自同一来源的模式被命名为“架构师也实现”，它可能类似于“外科手术团队”，因为特别是架构师（据推测）具有高超的技能。