组件团队：每个团队负责一个系统组件。例如，有一个团队负责前台，一个团队负责后台，还有一个团队负责数据库。这三个团队独立运作，这经常导致团队之间的相互依赖。
这些团队不是为最终用户提供价值，而是花了很多时间来讨论依赖关系和测试各组件的行为。从买方的角度来看，这些要素完全不重要。
组件团队也意味着很多正在进行的工作（WIP）项目正在同时进行。在排队理论中，我们有利特尔定律，证明了增加WIP的平均数量将增加每个工作项目完成的平均时间（前置时间）。作为一个组件团队工作会增加交付的时间。
功能团队：每个团队都有足够的信心完成一个端到端的故事。当然，团队的核心目的应该始终是提供客户价值；而不仅仅是分配责任和资源。
一开始可能会显得很艰难，因为每个团队成员都应该对各种组件有一定的了解。然而，随着他们在故事中的工作，他们会接触到各种组件，并获得了解它们的经验，直到他们有足够的信心来做一个有各种组件的故事
有一个普遍的误解，认为功能团队的每个成员都必须熟悉整个系统。事实上，并非如此，因为整个团队都需要实现整个以客户为中心的功能。当需求与团队技能不一致时，学习就会被 "强迫"，从而打破过度专业化的约束。
功能团队的每个成员都会随着时间的推移逐渐增加他们的专业技能，直到形成一个完整的多学科专家团队，他们都可以同时从事多个项目的工作。
想象一下，是这样的：
- 组件团队类似于水平切割蛋糕，每片蛋糕只由一层组成（例如，只有蛋糕、奶油或配料）。
- 另一方面，功能团队类似于垂直切蛋糕，每片蛋糕有多层，而不是只有一层。
应该如何重组你的团队？
如果你想要一个能从概念到实施都能承担客户要求的团队，那么功能团队无疑是一个更好的选择。但你应该如何开始一个？
遵循Shu-Ha-Ri原则，建议从小型产品开始，由一个团队负责，并将敏捷性的立场和原则内化。
然后，通过垂直组件团队，你可以承担更大的产品，并逐渐发展成功能团队。