敏捷中的跨职能 vs 自组织 vs 功能 vs 组件团队
(翻译自 : Cross-functional vs Self-organizing vs Feature vs Component Teams in Agile)
传统上，一个项目是围绕 组件团队 （即 UX、Dev、Business、Tester 等）组织的，任何需要一系列组件专业知识的发布都需要涉及多个组件团队。通常，不同的团队会有不同的优先级，这不可避免地会导致产品发布周期的瓶颈。
根据维基百科，跨职能团队是一群具有不同职能专业知识的人，他们朝着共同的目标努力。提高团队质量的最佳方法之一是使其具有跨职能。跨职能团队拥有将想法转化为工作产品的所有必要技能。
“跨职能团队拥有完成工作所需的 所有能力，而不依赖于不属于团队的其他人”——Scrum 指南
与组件团队方法相比， 跨职能团队 是由来自公司不同职能领域的人员组成的小组。— 它不仅应该由技术专家（后端、前端开发人员、QA 工程师等）组成，还应该由业务分析师、市场营销和用户体验专家或任何积极参与项目的人员组成。
传统团队 vs 敏捷团队
“一个 自组织团队 由一组必须管理自己的知识工作者组成。他们必须拥有自主权”—— 彼得·德鲁克。
Scrum 指南指出“Scrum 团队由产品负责人、开发团队和 Scrum Master 组成。他们是：
“ Scrum 团队 是 自组织 和 跨职能的” — Scrum 指南：
组件团队与功能团队
传统的方法是将产品或多或少地在逻辑上和有意义地分解成组件，并将组件团队分配给它们。但是，这些组件与客户的观点完全无关。
与技术堆栈团队相反，特性团队方法现在几乎是普遍接受的组织团队的方式，特别是在持续交付方法中，它强调解决用户需求的特性（即系统的垂直切片），这通常可以加速重视任何功能或工作软件的交付，并缩短来自真实用户的反馈循环。功能团队将拥有执行必要任务级工作以完成工作的所有技能。特别是，假设一个三层架构，团队成员将从事与这个故事的 GUI、中间层和数据库部分相关的任务。
组件组织的一大缺点是显而易见的：它减慢了价值流动。大多数系统功能创建依赖关系，需要组件团队之间的合作来构建、部署和最终发布。团队花费大量时间讨论团队之间的依赖关系和跨组件测试行为，而不是能够交付最终用户价值。
posted on 2022-02-15 13:22 Lynch_Warren 阅读(266) 评论(1) 编辑 收藏 举报
