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

¶7 Scrum团队正在组织开发工作，并且正在选择团队成员，或者正在评估如何发展团队技能集。

Scrum团队无法自主工作，因为它不具备完成复杂任务网络所需的所有技能。由于依赖团队外部人员的技能，团队无法承担起完成任务的责任。它减少了团队对完成时间的影响，并可能影响最终结果的质量。一致性和减少返工的核心精益原则依赖于短反馈循环。大多数复杂的开发需要来自不同领域的人才，如人的因素、卓越工程和质量保证。很少有人能在一个团队中找到所有这些才能，更不用说在任何一个特定的个人身上了。团队通常围绕能力领域进行组织：物以类聚。这有时被称为职能型组织。然而，跨团队边界协调这些功能是昂贵的，因为有效的通信发生在共享当前工作上下文的人之间——通常是团队成员。

一个复杂的产品可能需要团队掌握许多技能来开发完成的功能（参见“¶82完成的定义”）。当工作需要为每项所需技能增加一个人时，团队将因为变得过于庞大，而无法充分发挥作用。您可能不想在团队中扩展技能集，而是引入外部依赖。另一方面，您可以选择将工作交给团队，以便他们能够发展和学习所需的技能。但是学习需要时间。

局部学习可以成为局部优化，由一组专家开发实践和流程来优化他们的工作。专业化、局部实践和流程都可以成为组织效率的来源，但也会在团队边界产生问题。为了解决这些问题，组织可以定义“契约”，概述如何相互协作（例如，服务请求）。这样的契约可能指定组织愿意做的工作的性质以及响应请求的预期持续时间。任何需要该团队专业支持的人都必须遵循这些“契约”。然而，这可能会减缓整个产品的开发，尽管它提高了该部门的效率。同样，可能需要组织内的其他协调小组来管理这些跨部门契约，协商例外情况或确保各方都了解需要什么，并确保每个团队根据这些契约的义务履行其对其他团队和客户的义务。

新产品--或现有产品的新版本--都为它们的客户创造了一个新世界。因为你无法提前知道这个新世界会是什么样子，所以你必须随着产品的发展专注于学习和实验。团队必须从实际客户使用每个产品增量的经验中找到经验教训，而不是根据一些预先安排的计划。团队必须在产品开发过程中整合这些经验。每个人都认识到局部流动、自治和控制的优势，这些优势来自于在流程的一个步骤或一个职能领域内部的局部流动作为个人工作。然而，这样的工作结构使每个人（执行最后一步的人除外）远离最终用户和来自该边界上的交互的广泛见解。这可能导致局部功能次优，但整个产品开发过程的优化效果更好。

因此:

每个Scrum团队都应该包括交付完成功能所需的所有人才。

在最初创建团队时，关注技能集覆盖是件好事，但更重要的是，初始团队成员对“¶39愿景”有共同的热情，并且他们有学习新事物的记录。因为事情会随着时间的推移而变化，所以团队不太可能从一开始就预见到所有的长期技能需求。

团队成员现在有机会学习辅助技能。他们可以聚集在¶55产品待办列表项（PBIs）上（参见¶25 蜂群：单件连续流），这会帮助团队成员增加学习机会并优化了流程，以帮助快速完成功能。辅助技能的发展使团队更加灵活，因此任何成员都可以代替另一个不可用的成员。团队总是在进步，并且是自主的。

Scrum对于如何处理缺失的能力缄口不言。应当遵循常识；例如，向另一个团队寻求帮助，或者分包可能使团队感到意外的大型工作增量。如果球队偶尔需要这样的帮助，这是可以理解的。但是，如果团队发现他们经常依赖外部帮助，那么他们应该将其视为一种障碍，并采取措施（例如培训、重组或招聘）来纠正这种情况。

例如，一个软件程序员团队可能会发现构建了自己专业知识领域之外的产品，例如制药或航空航天。在团队中为每一个未被充分代表的能力指定一个人是很有诱惑力的，也许是通过咨询外部领域专家。然而，团队代表可能不知道他们自己有哪些不理解，甚至可能不知道该问领域专家什么问题。大多数领域专家将领域专业知识作为隐性知识，因此他们无法获得正确的见解来支持软件人员进行适当的实现。至关重要的是，团队成员要理解领域考虑对实现的影响，并对业务和解决方案空间都有全面的了解。在最近的一篇文章中，亚马逊的杰西·沃森指出，这两个因素“在一个脑袋内”13共存是至关重要的。最好让专家加入团队，并通过交叉培训拓宽知识。但请记住，小型团队：增加专家可能会使团队发展到团队合作几乎消失的地步。

这些团队很自然地表现得像“功能特性团队”（参见¶4 康威定律），因为大多数产品待办列表项（PBIs）都是符合功能特性的：产生收入的功能产品增量的可销售元素。如果跨职能团队开发产品，那么移交后自然会从¶41 价值流中消失：团队本身可以在没有外部支持或干预的情况下开发任何功能特性。涉及多个团队会在反馈循环中引入延迟，增加返工的浪费（无駄Muda），并在价值流中的开发阶段之间产生不一致（无稳Mura）。

发表在《哈佛商业评论》上的一项研究表明，两家公司，一家按职能性来组织，另一家按产品来组织，跨职能团队提供了这两种组织结构的最佳功能特征（参见《哈佛商业评论》46 [WL68]中的“组织选择：产品与功能》）。

¶42 基于集合的设计是一种技术，它使开发人员参与到可能与业务相关的许多学科和领域中，即使他们最终没有完成当前的产品。这样的实践拓宽了团队和企业的专业知识基础，并降低了团队由于需要掌握一些新学科而感到惊讶的可能性。

当团队整合新的经验教训时，就会有新的产品创意。变化将迅速进行（必须允许快速进行）。变化将是常态，而不是例外。这需要每个人都知道发生了什么事情的小型组织：可以接受变化，跨专业工作，定期交付价值，并且需要另一个术语：敏捷。

13. 杰西·沃森。“软件开发的难题”。

LinkedIn.com, https://www.linkedin.com/pulse/hard-thing-software   -development-jesse-watson， 2017年7月12日（2018年7月4日访问）。

游戏

组建几个小团队，他们将在游戏中竞争制作和飞行纸飞机。每个团队成员一次只能折一次，然后必须切换到另一架飞机上进行制作。飞机的折痕不能超过15个。它必须至少长15厘米，宽8厘米。它必须有至少2厘米宽的钝尖。要成为合格的优质产品，飞机必须在测试人员测试时水平飞行3米。测试人员只能测试每个飞机一次。

尝试这个游戏，并应用Scrum模式（提示：蜂群：单件连续流）来优化在一分钟Sprint中生产的高质量飞机的数量。

——译者：杨光

校对：Ma Xinjia