敏捷中的跨职能 vs 自组织 vs 功能 vs 组件团队

传统上，一个项目是围绕 组件团队 （即 UX、Dev、Business、Tester 等）组织的，任何需要一系列组件专业知识的发布都需要涉及多个组件团队。通常，不同的团队会有不同的优先级，这不可避免地会导致产品发布周期的瓶颈。

根据维基百科，跨职能团队是一群具有不同职能专业知识的人，他们朝着共同的目标努力。提高团队质量的最佳方法之一是使其具有跨职能。跨职能团队拥有将想法转化为工作产品的所有必要技能。

“跨职能团队拥有完成工作所需的  所有能力，而不依赖于不属于团队的其他人”——Scrum 指南

与组件团队方法相比， 跨职能团队 是由来自公司不同职能领域的人员组成的小组。— 它不仅应该由技术专家（后端、前端开发人员、QA 工程师等）组成，还应该由业务分析师、市场营销和用户体验专家或任何积极参与项目的人员组成。

自 组织团队 是一个可以自主选择如何最好地完成工作的团队，而不是由团队外的其他人指导。与传统的管理原则不同，自组织授权的团队不是由高层指挥和控制的；相反，它们是从团队成员积极和集体参与所有 Scrum 实践和活动演变而来的。

传统团队 vs 敏捷团队

“一个 自组织团队 由一组必须管理自己的知识工作者组成。他们必须拥有自主权”—— 彼得·德鲁克。

Scrum 指南指出“Scrum 团队由产品负责人、开发团队和 Scrum Master 组成。他们是：

“ Scrum 团队 是 自组织 和 跨职能的” —  Scrum 指南：

组件团队与功能团队

传统的方法是将产品或多或少地在逻辑上和有意义地分解成组件，并将组件团队分配给它们。但是，这些组件与客户的观点完全无关。

与技术堆栈团队相反，特性团队方法现在几乎是普遍接受的组织团队的方式，特别是在持续交付方法中，它强调解决用户需求的特性（即系统的垂直切片），这通常可以加速重视任何功能或工作软件的交付，并缩短来自真实用户的反馈循环。功能团队将拥有执行必要任务级工作以完成工作的所有技能。特别是，假设一个三层架构，团队成员将从事与这个故事的 GUI、中间层和数据库部分相关的任务。

组件组织的一大缺点是显而易见的：它减慢了价值流动。大多数系统功能创建依赖关系，需要组件团队之间的合作来构建、部署和最终发布。团队花费大量时间讨论团队之间的依赖关系和跨组件测试行为，而不是能够交付最终用户价值。