敏捷团队中,专家能胜过通才么?

  • Vikas Hazrati
  • 郑柯

2008 年 6 月 22 日

话题:敏捷文化 & 方法

在敏捷社区中有一个普遍的共识,那就是要组成包括通才和专家的跨职能团队。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?

敏捷文化 & 方法