两块披萨团队是什么
两块披萨团队是亚马逊的团队规模经验法则：团队小到用两块披萨就能喂饱，常见理解约 6-10 人。背后的原理是沟通路径随人数呈平方级增长，团队越大协调成本越高，小团队在决策速度、责任清晰度与自主性上更有优势。
怎么用才对
规模法则必须与授权配套：团队要能自主决定技术方案，并对端到端交付负责（谁构建谁运维），否则人少了但决策仍层层上报，规模缩小只换来更长的等待。拆分的依据应是业务能力或限界上下文，而不是单纯按人数切分，否则会把强耦合模块拆开，依赖调度反而变多。
基本信息
| 来源 | 亚马逊内部实践，经公开报道与书籍转述 |
|---|---|
| 规模 | 常见理解约 6-10 人 |
| 目的 | 降低沟通开销、提升自主与责任清晰度 |
| 前提 | 配套授权、清晰边界与端到端负责 |
典型使用场景
- 组建新业务线：按业务能力划出可独立交付的小团队
- 判断团队是否过大：会议开始以轮流汇报代替讨论时需要警惕
- 设计值班范围：让一个团队能独立承担自己系统的排障
- 评估跨团队依赖：依赖多于内部协作时考虑合并或重划边界
- 组织重组：把强耦合的模块放回同一个团队
- 设定团队职责：明确拥有哪些系统与哪些指标
规模化自查问题
规模化自查问题
团队会议是否需要轮流汇报而不是讨论？
是否有人长期只参加同步会、不产出交付物？
跨团队依赖的数量是否超过团队内部协作？
团队能否自主决定技术方案而不层层上报？
值班时能否只靠本团队知识完成排障？过大的信号
| 信号 | 说明 | 建议动作 |
|---|---|---|
| 轮流汇报 | 会议沦为信息广播 | 按业务能力拆分或减少同步会 |
| 长期挂名 | 有人参会但不产出 | 明确职责或调整归属 |
| 依赖外溢 | 跨团队协调多于内部协作 | 合并相关模块或重划边界 |
规模法则是启发而非铁律：强耦合系统硬拆成多个小团队，会带来更多协调成本，也可能让任何人都不再对整体负责。