在Scrum团队中管理知识分布
我们是一个产品团队，提供DevOps工具供组织内部使用。产品团队的工作通常包括安装、配置、测试、集成和部署DevOps工具。直到最近，我们还是一个小团队(游戏邦注:只有4名开发者)。现在我们已经增加到8个开发者。当我们还是一个小团队时，我们决定成为“多面手也就是说，每个人都可以使用任何DevOps工具。现在我们是8个开发者，我们很难继续采用多面手的概念。
在整个团队中有什么已知的知识管理策略吗?
一种选择可能是更好地定义作为“DevOps工具”一部分的产品。一个产品可能由多个工具组成，但是您可以将这些工具组织成独立的产品，并围绕支持该产品组建团队。
另一个选择可能是围绕价值流进行组织。每个团队可能使用多种工具，但将为这些工具的特定终端用户或客户提供服务。如果客户不使用某个工具，他们可能永远都不需要在开发过程中使用该工具。他们可以非常熟悉使用这些工具的人，并为特定的用户优化他们的工作。
也许还有其他选择，但我不确定你是否可以完全分开。例如，如果您的工具在一个公共平台上，那么就分离出一个平台团队，让其他团队专注于单个工具、工具小组或价值流。
我推荐团队拓扑．从表面上看，将员工重组为更好的团队似乎可以满足您的需求，但如果您的环境和体系结构不支持，拆分为更小的团队可能会引入跨团队依赖，从而引入管理复杂性。
开发人员需要具备多少通才?你对此有什么感觉吗?在团队工作流程受到阻碍之前，需要交叉技能的程度有多大?
记住，保持一系列的技能可能是昂贵的，而成为一个多面手的成本则不是一定有道理的。通常，开发人员拥有一两个附加规程就足够了。理想情况下，这将允许他们在核心学科边界协助和平滑工作流程，当瓶颈或饥饿似乎可能发生时。
例如，在您描述的工作流中:
安装、配置、测试、集成和部署
测试专家可能只在配置和/或集成方面获得t型辅助技能。