在敏捷社区中有一个普遍的共识，那就是要组成包括通才和专家的跨职能团队。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类似，他也喜欢通才型的专才。他认为，太多软件开发人员在一种专业领域内浸淫得越来越深。编程是一个狭窄的领域，工程技术的世界如此广阔，他们应该把自己培养成全面的软件开发者。
总的说来，并不是所有的敏捷社区成员都赞成专家机制。应该根据团队的人员和项目具体情况，来安排通才和专家的比例，或者努力增加通才型专家的数量，他们可以携手并进，推动项目取得成功。
原文如下：
There is a general consensus in the Agile community on the relevance of cross functional teams and the idea of having generalists and specialists on the team. Dave Gray, in an interesting diagram on his blog, tries to show the relationship between a generalist and a specialist. According to Dave, a generalist has a basic understanding across many disciplines. Generalist may not have a specific skill required to solve the problem, however, he is very good in defining the problem. A specialist on the other hand is a person who has a deep understanding of a specific discipline. He is best used when solving a problem or executing a plan. According to Dave both are required in a project for the successful execution of the project.
JurgenAppelo however, has a strong opinion on the generalist and specialist theory. In his blog he mentioned that, not only specialists are good , he also discourages any team member in his organization from becoming cross functional. According to Jurgen,
Cross-functional teams (in the way they are promoted by some agilists) completely ignore everything society has learned since philosopher and economist Adam Smith pointed out in 1776 (in his landmark book The Wealth of Nations) that specialization leads to higher productivity and prosperity.
He further added
When the design of a web site is being implemented by a developer, it can bring tears to my eyes. Some of them seem not to be able to see the difference between a pixel and a centimeter. I have seen functional designs for web sites, created by software engineers, that would probably have caused physical injuries among our web sites' visitors, if we had followed the designs.
Jurgen added more weight to his argument when he quoted the book by David J. Anderson
In his book Agile Management for Software Engineering David J. Anderson mentioned research done by Capers Jones which showed that a team of specialists will usually outperform a team of generalists (page 272).
According to him, the inefficiencies associated with specialists do not outweigh the much bigger inefficiencies of generalists, who are apparently slower at doing their jobs than the specialists are.
On the other hand, some members of the Agile community strongly believe that specialists should be avoided on the teams at any cost. David Christiansen is of the opinion Generalist first, specialists last. In response to a question on the composition of a well formed team, he suggested
You should avoid specialists if you can. They tend to be grumpy one-trick-ponies that aren't particularly interested in developing a good core team. Besides, they only do certain tasks, eschewing all other work. Specialists spend a lot of time waiting between tasks that are "appropriate" for their skills, so they are either wasting your project's money OR only partially allocated. Both of these situations add risk and invite failure and can cause tricky scheduling dependencies. Generalists, on the other hand, can add value throughout the entire project lifecycle. They can help at all phases, which means scheduling isn't such a big deal. In fact, having a team staffed entirely with generalists can go a long way to eliminating dependencies on your projects critical path.
Scott Ambler takes a middle ground when he suggests that a team should be comprised of generalizing specialists.
One approach is to build a team with some people who are generalists and some who are specialists, the generalists provide the glue within the team and focus on the bigger picture whereas the specialists focus on the detailed complexities of your project. This works well because the strengths of generalists balance the weaknesses of specialists and vice versa, and it is often quite useful for a generalist to pair with a specialist because of this balance. A better approach would be to build a team comprised of people who are generalists with one or two specialties -- generalizing specialists.
According to Scott, a generalizing specialist is someone with a good grasp of how things fit together and as a result of this they tend to have greater understanding of what the team is working on.
On similar lines Jeff Atwood, voiced his opinion in favor of generalizing specialists. According to him too many software developers are burrowing themselves deeper and deeper into the same skill sets and specialties. Coding is a narrow realm and there is a vast universe of engineering skills, which should be cultivated to become a full rounded software developer.
In conclusion, not all members of the Agile community feel that specialists is the way to go. Depending on the people and project either a team can have the desired ratio of generalists and specialists or else can aspire for having generalizing specialists who can work together towards the success of the project.
最新评论