作为一个整体，团队应该包含交付产品所需的所有人才。

　　Scrum团队正在组织其开发工作，并正在选择团队成员，或正在评估如何使团队的技能获得成长。

　　Scrum团队如果不能自主工作，就是因为它不具备完成复杂任务网络所需的所有技能。如果依赖团队外部人员的技能，团队就不能真正“拥有”手头的工作。这样团队对工作的完成时间就没那么有掌控力了，并且最终工作的质量也会受到影响。

　　一致性（Consistency）和减少返工（Reduced Rework）这两项核心精益原则依赖于短的反馈回路。大多数复杂的开发工作都需要有来自不同领域（如人类工程学、工程卓越和质量保证等）的众多人才。很少有人能在一个团队中找到所有这些人才，更不用说在任何一个人身上找到所有这些技能。团队通常围绕着能力领域进行组织，正所谓物以类聚，人以群分。这有时被称为职能型组织（Functional Organization）。

　　然而，跨越团队边界协调这些职能的成本很高，因为只有在那些共享当前工作背景的人之间才能存在有效沟通——这通常只有同一个团队的成员才能做到。

　　一个复杂的产品可能需要团队掌握许多技能才能“完成”各项功能。如果需要为每项所需的技能都分别增加一个人，那么团队就会变得过于庞大而无法有效工作。要解决这个问题，通常会有两种选择：你可能会倾向于不扩大团队的技能组合，而是引入外部依赖；你也可能会选择把工作交给团队，让他们去发展和学习所需的技能。但学习是需要时间的。

　　局部学习可以导致局部优化，也就是说专家会发展出优化他们工作的实践和流程。专业化（Specialization）、局部实践（Local Practices）和流程（Processes）都可以成为一个组织的效率来源，但也会在团队的边界处产生问题。

　　为了解决这些问题，这个组织可以定义“合同”，说明如何与对方合作（例如，服务请求）。这样的合同可以规定这个组织愿意做什么性质的工作，以及对请求的预期响应时间。任何需要该团队专业技能的人都必须使用这些合同与他们打交道。然而，这可能会减缓整个产品的开发，即使它提高了局部部门的效率。

　　同时，可能需要在组织内设立额外的协调小组来管理这些边界合同、协商例外情况或确保所有各方了解所需的内容，并确保每个团队根据这些合同的义务，履行对其他团队以及对客户的义务。

　　新产品或现有产品的新版本，目的都是要为客户创造一个新世界。因为你无法事先知道这个新世界会是什么样子，所以你必须在产品开发过程中专注于学习和试验。团队必须从客户使用产品的经验中吸取教训，而不是单纯按预先安排的计划行事。而且，团队必须在整个产品开发过程中整合这些经验。每个人都认识到在流程的某一步骤或某一职能领域内作为个体工作所带来的局部流动（local flow）、自主（autonomy）和控制（control）的优势。

　　然而，这样的工作结构使每个人（除了做最后一步的人）离最终用户更远，从而失去与最终用户进行互动才能获得的广泛洞察力。（从全局考虑问题）这可能导致局部职能不是最优，但整个产品开发流程的优化程度会更高。

　　因此：每个Scrum团队应该包括交付“完成”的功能所需的所有人才。

　　在团队创建初期，关注技能的覆盖度是一个很好的起点，但更重要的是，团队成员要对愿景有共同的热情，并愿意学习新鲜事物。因为工作会随着时间的推移而变化，团队不可能从一开始就预见到所有的长期技能需求。

　　与其因为需要新的技能就去更换团队成员，不如在内部培养人才，并努力建立小而稳定的团队。随着时间的推移，对团队成员进行交叉培训，使他们的技能组合不断增长，以适应越来越多的能力领域。这将提高团队作为一个自主团队工作的能力。有了跨职能的团队，就更容易均匀分配工作。

　　团队成员现在有太多的机会去学习次级技能。比如他们可以在产品待办事项（PBI）上使用蜂拥模式，这样就可以增加学习的机会，优化流动，有助于功能快速达到“完成”的状态。次级技能的发展使团队更加灵活，因此如果有人不在，其他任何人都可以顶上来。这样团队总是可以取得进展，并且是自主的。

　　Scrum对如何处理能力缺失的问题没有提及，它相信这些都是常识可以搞定的 ：例如，向其他团队寻求帮助，或把大的工作外包出去，不过外包出去的工作结果就不好说了，有可能会让团队大吃一惊。如果团队偶尔需要这样的帮助，还是可以理解的。但如果团队发现他们经常要依赖外部的帮助，那么他们就应该把这看作是一种阻碍，并采取措施（如培训、重组或招聘）来补救这种情况。

　　例如，一个由软件程序员组成的团队可能会发现自己正在构建一个不属于自己专业领域的产品，如制药或航空航天。我们很想在团队中为每个弱势能力指定一个负责人，也许可以咨询外部领域专家。然而，团队代表可能不知道他们有多少不知道的东西，甚至可能不知道该向领域专家提出什么问题；反过来，大多数领域专家把领域专业知识当做隐性知识（译者注：已经成为专家潜意识的一部分），所以他们可能也没有办法意识到软件人员真正想要的洞见是什么（译者注：因为专家不会注意到他们觉得理所当然的事情，即隐性知识）。

　　至关重要的是，团队成员要理解领域因素对实施的影响，并对业务和解决方案的空间都有全面的了解。亚马逊的Jesse Watson指出，这两个因素（译者注：两个因素分别是业务知识和解决方案）“在一个头骨内”并存是至关重要的。[1]最好是将专家带入团队，并通过交叉培训扩大知识面。但要记住保持小团队：向团队中增加专家可能会使团队合作减弱到几乎没有的地步。

　　这些团队自然会像“特性团队”（Feature Team，详见后续推出的康威定律模式）那样工作，因为大多数PBI都是以特性的形式（Feature-Shaped）存在的：产生收入的功能性产品增量中的可销售元素（marketable elements of revenue-generating functional product increment）。

　　如果由跨职能团队来开发产品，那么交接动作自然会从价值流中消失：团队本身就可以开发任何特性，无需外部支持或干预。让多个团队参与进来，会造成反馈回路的延迟，增加返工的浪费（Muda），并在价值流的不同开发阶段之间产生不一致（Mura）。

　　《哈佛商业评论》（Harvard Business Review）发表了一项关于两家公司的研究，其中一家是按职能组织的，另一家是按产品组织的。研究表明，相比之下，跨职能团队交付特性的效果是最好的。

　　基于集合的设计是一种技术，它可以让开发人员参与到许多可能与业务相关的学科和领域中，即使这些学科和领域最终可能没有用在当前产品中。这种实践拓宽了团队和企业的专业知识基础，并且也让团队不会惊讶于需要掌握某些新学科。

　　随着团队整合新的经验，他们会对产品有新的想法。变化将会非常迅速（而且必须允许它迅速）。变化将是常态，而不是例外。这需要小规模的组织，因为在小规模的组织中，每个人都知道正在发生什么：这些组织能够拥抱变化、跨专业工作、定期交付价值，用一个词来形容就是：敏捷。

　　组建几个小团队，在游戏中竞争制作和飞行纸飞机。每个团队成员一次只能做一个折叠动作，然后必须换到另一个飞机上。任何飞机都不得有超过15个折痕。它必须至少有15厘米长，8厘米宽。它必须有一个至少2厘米宽的钝头。要成为优质产品，测试员测试时，飞机必须水平飞行3米。测试员对每架飞机只能测试一次。

　　试试这个游戏，并应用Scrum Pattern（提示：蜂拥模式）来优化在一分钟长的Sprint中生产的优质飞机的数量。