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

能从一开始就预见到所有的长期技能需求。

 

02如何培养跨职能团队

 

与其因为需要新的技能就去更换团队成员，不如在内部培养人才，并努力建立小而稳定的团队。随着时间的推移，对团队成员进行交叉培训，使他们的技能组合不断增长，以适应越来越多的能力领域（详见后续推出的Moderate Truck Number模式）。这将提高团队作为一个自主团队工作的能力。有了跨职能的团队，就更容易均匀分配工作（Scrum Pattern之一，将在单独的文章中介绍）。

 

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

 

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

 

例如，一个由软件程序员组成的团队可能会发现自己正在构建一个不属于自己专业领域的产品，如制药或航空航天。我们很想在团队中为每个弱势能力指定一个负责人，也许可以咨询外部领域专家。然而，团队代表可能不知道他们有多少不知道的东西，甚至可能不知道该向领域专家提出什么问题；反过来，大多数领域专家把领域专业知识当做隐性知识（译者注：已经成为专家潜意识的一部分），所以他们可能也没有办法意识到软件人员真正想要的洞见是什么（译者注：因为专家不会注意到他们觉得理所当然的事情，即隐性知识）。至关重要的是，团队成员要理解领域因素对实施的影响，并对业务和解决方案的空间都有全面的了解。在最近的一篇文章中，亚马逊的Jesse Watson指出，这两个因素"在一个头骨内"并存是至关重要的。[1] 最好是将专家带入团队，并通过交叉培训扩大知识面。但要记住保持小团队：向团队中增加专家可能会使团队合作减弱到几乎没有的地步。

 

这些团队自然会像 "特性团队（Feature Team）"（详见后续推出的康威定律模式）那样工作，因为大多数PBI都是以特性的形式存在的（Feature-Shaped）：产生收入的功能性产品增量中的可销售元素（marketable elements of revenue-generating functional product increment）。如果由跨职能团队来开发产品，那么交接动作自然会从价值流中消失：团队本身就可以开发任何特性，无需外部支持或干预。让多个团队参与进来，会造成反馈回路的延迟，增加返工的浪费（Muda），并在价值流的不同开发阶段之间产生不一致（Mura）。

 

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

 

基于集合的设计（Set-Based Design，Scrum Pattern之一，将在单独的文章中介绍）是一种技术，它可以让开发人员参与到许多可能与业务相关的学科和领域中，即使这些学科和领域最终可能没有用在当前产品