双披萨团队

双披萨团队是一个小型团队，完全支持特定业务能力的软件。这个术语流行起来是因为它用来描述亚马逊如何组织他们的软件人员。

这个名字暗示了这种团队最明显的方面，即他们的规模。这个名字来源于一个原则，即团队规模不应超过两块披萨能喂饱的人数。（虽然我们这里说的是美式披萨，但当我第一次在国外遇到它们时，它们似乎大得惊人。）保持团队规模小可以保持团队的凝聚力，形成紧密的合作关系。通常我听到这意味着这样的团队大约有 5-8 人，虽然我的经验表明上限大约在 15 人左右。

虽然这个名字只关注规模，但同样重要的是团队的重点。双披萨团队应该拥有所有必要的能力，以向其用户交付有价值的软件，并最大限度地减少与其他团队的交接和依赖关系。他们可以弄清楚客户的需求，并迅速将其转化为可用的软件，能够根据客户需求的变化进行实验和演变。

双披萨团队是 结果导向 而不是 活动导向。他们不按技能（数据库、测试、运维）进行组织，而是承担支持客户所需的所有责任。这最大限度地减少了功能流向客户的团队间交接，使他们能够缩短周期时间（将功能想法转化为生产环境中运行的代码所需的时间）。这种结果导向也意味着他们将代码部署到生产环境并监控其在那里的使用情况，他们对任何生产故障负有责任（通常意味着他们需要承担非工作时间支持的责任）——这一原则被称为“你构建它，你就运行它”。

专注于客户需求意味着团队是长期的，以业务能力为中心 的团队，只要该能力处于活动状态，他们就会支持该能力。与项目导向型团队不同——在软件“完成”后解散——他们认为自己是 长期产品 的推动者和增强者。这方面通常导致他们被称为产品团队。

双披萨团队需要支持其产品所需的广泛技能和责任，这意味着虽然这样的团队可以成为团队组织的主要方法，但它们需要一个构建良好的软件平台的支持。对于小型组织来说，这可以是一个商业平台，例如现代云服务。较大的组织将创建自己的内部平台，以便他们的双披萨团队更容易协作，而不会造成困难的交接。 团队拓扑 提供了一种很好的方法来思考支持双披萨团队所需的各种团队和交互（团队拓扑称之为流对齐团队）。

为了使以业务能力为中心的团队有效，他们需要利用彼此的能力。因此，团队需要向同行提供他们的能力，通常通过精心设计的 API。这种团队向同行提供服务的责任往往被忽视，如果它没有发生，就会导致信息孤岛硬化。

像这样围绕业务能力组织人员对组织软件的结构方式有深远的影响——由于 康威定律 的影响。双披萨团队构建的软件组件需要与其同行之间进行良好控制的交互，并在它们之间具有清晰的 API。这种想法导致了 微服务 的发展，但这并不是唯一的方法——单片运行时内的结构良好的组件通常是更好的路径。