共计 3560 个字符，预计需要花费 9 分钟才能阅读完成。
作为一个整体，团队应该蕴含交付产品所需的所有人才。
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 中生产的优质飞机的数量。
参考资料：
- Jesse Watson.“The Hard Thing aboutSoftware Development.”LinkedIn.com, https://www.linkedin.com/puls…, 12 July 2017 (accessed 4 July 2018).
- Arthur H. Walker and Jay W.Lorsch.“OrganizationalChoice: Product vs. Function.”In Harvard Business Review 46(6), 1968, pp. 129-138. https://hbr.org/1968/11/organ… (accessed 8 November 2017).
起源：徐东伟麻利教练
作者：徐东伟
申明：文章取得作者受权在 IDCF 社区公众号（devopshub）转发。优质内容共享给思否平台的技术伙伴，如原作者有其余思考请分割小编删除，致谢。
玩乐高，学麻利，规模化麻利联合作战沙盘之「乌托邦打算」，12 月 25-26 日登陆深圳，将“多团队麻利协同”基因内化在研发流程中，为规模化晋升研发效力保驾护航！!🏰⛴公众号回复“乌托邦”可加入
