一文搞懂Scrum Pattern︱敏捷软件开发

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

 

01为什么需要跨职能团队

 

Scrum团队如果不能自主工作，就是因为它不具备完成复杂任务网络所需的所有技能。如果依赖团队外部人员的技能，团队就不能真正“拥有”手头的工作。这样团队对工作的完成时间就没那么有掌控力了，并且最终工作的质量也会受到影响。一致性（Consistency）和减少返工（Reduced Rework）这两项核心精益原则依赖于短的反馈回路。大多数复杂的开发工作都需要有来自不同领域（如人类工程学、工程卓越和质量保证等）的众多人才。很少有人能在一个团队中找到所有这些人才，更不用说在任何一个人身上找到所有这些技能。团队通常围绕着能力领域进行组织，正所谓物以类聚，人以群分。这有时被称为职能型组织（Functional Organization）。然而，跨越团队边界协调这些职能的成本很高，因为只有在那些共享当前工作背景的人之间才能存在有效沟通 -- 这通常只有同一个团队的成员才能做到。

 

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

 

局部学习可以导致局部优化，也就是说专家会发展出优化他们工作的实践和流程。专业化（Specialization）、局部实践（Local Practices）和流程（Processes）都可以成为一个组织的效率来源，但也会在团队的边界处产生问题。为了解决这些问题，这个组织可以定义 "合同"，说明如何与对方合作（例如，服务请求）。这样的合同可以规定这个组织愿意做什么性质的工作，以及对请求的预期响应时间。任何需要该团队专业技能的人都必须使用这些合同与他们打交道。然而，这可能会减缓整个产品的开发，即使它提高了局部部门的效率。同时，可能需要在组织内设立额外的协调小组来管理这些边界合同、协商例外情况或确保所有各方了解所需的内容，并确保每个团队根据这些合同的义务，履行对其他团队以及对客户的义务。

 

新产品或现有产品的新版本，目的都是要为客户创造一个新世界。因为你无法事先知道这个新世界会是什么样子，所以你必须在产品开发过程中专注于学习和试验。团队必须从客户使用产品的经验中吸取教训，而不是单纯按预先安排的计划行事。而且，团队必须在整个产品开发过程中整合这些经验。每个人都认识到在流程的某一步骤或某一职能领域内作为个体工作所带来的局部流动、自主和控制的优势。然而，这样的工作结构使每个人（除了做最后一步的人）离最终用户更远，从而失去与最终用户进行互动才能获得的广泛洞察力。（从全局考虑问题）可能导致局部职能未必达到最优，但整个产品开发流程的优化程度会更高。

 

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

 

在团队创建初期，关注技能的覆盖度是很好的，但更重要的是，团队成员要对愿景有共同的热情，并愿意学习新鲜事物。因为事情会随着时间的推移而变化，团队不可