什么方法最接近神话人月的手术团队？

Question

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

总结手术团队的类比： 外科医生了解问题/业务领域并且是专家。当团队中存在问题或冲突时，他们是权威。当有问题时，外科医生在他们自己之间工作，比如设计，作为一个较小的专家团队。所以从本质上讲，他们拥有领域的知识，委托做他们认为是对的，并做实际的编码？团队的其他成员专注于支持，测试，文档和项目计划是委派任务。因此，外科医生也是最熟练/训练有素的资源。

答案可能是项目，编程，设计方法，因为它似乎对主要方法论领域产生了影响。 Agile，MDA，Extreme，在采购开发方面？ 对于复杂业务领域中的大型软件，考虑空中交通管制，而不是COTS开发人员或公用事业，这个问题也更有意义。

Answer 1

Organizational Patterns of Agile Software Development中提到的一种模式标题为“每个角色三到七个助手”;它与外科团队的不同之处在于它注重每个角色，例如，不仅外科医生的“角色”有助手或关系：所有角色都有一些关系。

来自同一来源的另一种模式，名为“建筑师也实施”，可能类似于“外科团队”，特别是建筑师（大概）是高技能的。

Answer 2

对于外科医生来说，关键角色既是领域专家又是实施者。

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

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

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

• 很少有关键开发人员能够充分理解问题域，并且必须依赖域专家。这只是专业化的一个功能 - 很难找到那些同时也是律师，医生，会计师或其他软件正在建模的领域的专家。

• 可扩展性受到您所拥有的“外科医生”数量的限制。

• 其他员工在等待指示时会有很多停工时间，因为高度专注的“实干家”也在管理团队。在OR中没问题，因为你正在处理“零错误”授权和“实时软件”。但是在这种经济环境中，更加分散的工作负载更有效率，即使它导致团队成员之间偶尔出现同步问题。

Answer 3

我不确定任何方法确实可以解决这个问题，因为这实际上是优先考虑开发人员并将所有内容都放在他们的需求上，而不是那些开发人员如何实际开发他们的软件。

如果你正在寻找一些方法来推动这一点，我想这可能是坏消息。我更愿意将其视为好消息，因为这意味着您可以将此方法用于几乎任何软件开发方法。

我已经完成了以这种方式运行的一个项目。这太令人愉快了，我差点把它称为“工作”。我们四个开发人员（有额外的支持人员，包括偶尔额外的初级代码猴）只需9个月就可以编写并运行正常的代码。其他地方我和20岁的团队一样无法做到这一点。

Answer 4

从文中我看到以下内容：

Agile赞：

• 小团队专注于解决具体问题
• 激增之间的合作

非敏捷就像：

• 外科医生是权威，推动计划，确定设计，分配支持任务（将其视为编码的子服务）并进行编码。所有这些都是方法上的指挥和控制，与自我指导团队相反（与指导团队相反）
• 似乎没有与业务合作伙伴合作（更不用说与业务合作伙伴经常合作）
• 似乎没有优先产品积压，因此外科医生选择重要的不是商业伙伴
• 似乎没有包含递送（紧密反馈循环）

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

人们不能确定地提倡所采用的方法。但是，它似乎确实使用了语言（项目计划，任务）并假设正在遵循瀑布方法（设计，编码，由计划驱动的测试等阶段）。无论使用何种方法，少数几种方法都决定了许多人的工作。