团队拓扑快速参考图


由 Matthew Skelton 和 Manuel Pais撰写的《团队拓扑——组织业务和技术团队以实现快速流动》一书将帮助您设计团队组织结构,从而帮助您变得更加敏捷。
这本书分为三个部分:

  • 第一部分侧重于作为交付手段的团队。
  • 第二部分解释了适用于流程的团队拓扑结构,
  • 第三部分阐述了不断发展的团队交互以实现创新和快速交付。

这本书解释了团队拓扑背后的七个核心思想:
  • 康威定律

“设计系统的组织……被限制生产设计,这些设计是这些组织的通信结构的副本。” 康威定律告诉我们,一个组织的结构和团队之间的实际沟通路径坚持所构建的系统的最终架构
团队第一。从团队开始进行有效的软件交付。有多个方面需要考虑和培养:团队规模、团队寿命、团队关系和团队认知。组织分组应该遵循邓巴的数字,从大约 5-8 人开始,然后增加到大约 15 人,然后是 50,然后是 150,然后是 500,依此类推。 ç OGN itive载:“在工作记忆中使用的脑力劳动的总量。” 限制团队责任以匹配最大的团队认知负荷。解释了以下三种不同类型的认知负荷:
  1. 内在认知负荷——与问题空间的基本任务的各个方面有关
  2. 外部认知负荷——与完成任务的环境有关
  3. 日耳曼认知负荷- 涉及需要特别注意学习或高性能的任务方面。

  • 四种基本拓扑

解释了四种基本的团队拓扑,包括预期的行为和能力:
  1. Stream-Aligned Team:与业务变更的主要流程保持一致的团队,具有跨职能的技能组合和交付显着增量的能力,而无需等待另一个团队(有些人将这些团队称为“产品或功能团队”,但谈论的是流更有意义)
  2. 平台团队:在底层平台上工作的团队,支持交付中的流对齐团队。该平台简化了其他复杂的技术并减少了使用它的团队的认知负担(一个好的平台“足够大”)
  3. 支持团队:作为过渡或学习期的一部分,协助其他团队采用和修改软件的团队
  4. 复杂子系统团队:一个团队,对一个过于复杂而无法由普通流对齐团队或平台团队处理的子系统有特殊职责。可选,仅在真正需要时使用。

 
  • 团队互动模式

4 种基本团队拓扑的主要交互模式是:
  1. 协作:与另一个团队密切合作
  2. X-as-a 服务:以最少的协作消费或提供某些东西
  3. 促进:帮助(或被)另一个团队清除障碍

 
  • 组织感知

期望适应和发展您的组织结构。
 
  • 拓扑演化

当组织应对新挑战时,组织应该期望在任何给定时间看到不同类型团队之间的不同类型的交互
 
  • 团队 API

与团队的整个交互的描述:代码、版本控制、wiki 和文档、实践和原则、沟通、工作信息和其他。

下载:QRC (Team Topologies, 200525) v1.0
QRC 也可在 Team Topologies 网站上获得:https : //teamtopologies.com/community