敏捷团队中，专家能胜过通才么？

在敏捷社区中有一个普遍的共识，那就是要组成包括通才和专家的跨职能团队。 Dave Gray 在他的 blog 中发表了一张有趣的图表，试图显示通才和专家之间的关系。Dave 认为，通才对多个领域的规则都有基本的理解，他们不一定具备解决问题所需的特殊技能，不过能很好地诠释问题。从另一个方面来说，专家对特定的领域有深入的了解。他们在解决问题和执行计划方面的能力是一流的。Dave 认为项目的成功执行需要这两种角色的参与。

Jurgen Appelo 强烈反对这种通才加专家的理论。在 blog 上，他不仅对专家的作用大加赞扬，而且不鼓励组织中的任何成员向通才转变。根据 Jurgen 的说法：

跨职能团队（一些敏捷专家推荐的方式）完全忽视了社会得出的经验，1776 年哲学和经济学家亚当·斯密在他的重要著作《国富论》中曾指出：专家能够带来更高的生产率和繁荣。

JurgenAppelo 还说：

当软件开发人员要去设计网站的时候，我都要哭了。一些人几乎分辨不出像素和厘米之间的差异。我见过软件工程师所做的网站功能设计，如果照其执行的话，网站访问者的身体会受到严重伤害。

为了增加说服力，Jurgen 引用了 David J. Anderson 书中的内容：

David J. Anderson 在《软件工程的敏捷管理》一书中提到了 Capers Jones 的研究，说明专家小组的表现通常能优于由通才组成的小组（第 272 页）。

他认为，使用专家所导致的效率降低不会比使用通才更严重，而通才处理工作的速度明显要落后于专家。

另一方面，敏捷社区中的一些成员坚信：团队应该不惜一切代价避免专家的存在。 David Christiansen 认为：使用通才而不是专家，这才是王道。在谈到如何组建好的团队时，他这样建议：

应该尽量避免使用专家。他们都是只会一种技能、而且脾气暴躁的家伙，他们对于形成良好的核心团队没有兴趣。此外，他们只做固定的工作，避开其他的任务。为了等待下一个“适合”他们的任务，专家们会耗费上许多时间。所以他们要么造成了项目资金的浪费，要么根本就处在半工作状态。所有这些情况增加了失败的风险，并造成棘手的计划依赖。从另一个方面来说，通才在项目的整个生命周期中一直在增加价值，他们在所有的阶段都能提供帮助，这意味着日程安排不是什么大问题。实际上，如果整个队伍都是由通才组成，能在很大程度上消除项目主要路径对人员安排的依赖。

Scott Ambler 采取了中间立场，他认为团队应该由通才型的专家组成。

不妨建立通才和专家都包括的团队，通才在团队内部起到粘合剂的作用，着眼于更宏观的问题；而专家则关注项目中较复杂的细节。这种方式的效果不错，因为通才的长处刚好能平衡专才的短处，反之亦然。通才和专才的结合因为达成了某种平衡，通常很有效。更好的方案是建立通才占多数的团队，并配备一到两个专家——通才型的专家。

Scott 认为，通才型的专家能够很好地把握事物之间如何配合，并能够因此更加了解团队工作的内容。

Jeff Atwood的观点与Scott 类似，他也喜欢通才型的专才。他认为，太多软件开发人员在一种专业领域内浸淫得越来越深。编程是一个狭窄的领域，工程技术的世界如此广阔，他们应该把自己培养成全面的软件开发者。

总的说来，并不是所有的敏捷社区成员都赞成专家机制。应该根据团队的人员和项目具体情况，来安排通才和专家的比例，或者努力增加通才型专家的数量，他们可以携手并进，推动项目取得成功。

查看英文原文： Do Specialists Outperform Generalists on an Agile Team?