Feature Team 快速响应团队摆脱冗长研发体制

1. 背景

在研发过程中你的团队是否遇到了这样的问题：

• 团队不断扩大，研发团队忙的不可开交，而客户仍然抱怨“想要的功能怎么还没做"
• 总是被突然的需求打乱开发计划，加班加点，到处协调资源
• 产品/功能做了不少，而用户量，活跃量缺增长缓慢

那么，你需要了解下 Feature Team，它在研发过程提供了新的方式，确保产品快速响应市场，又不会被公司冗长的开发体制束缚

2. 什么是 Feature Team

2.1 基本概念

Feature Team ：A feature team, is a long-lived, cross-functional, cross-component team that completes many end-to-end customer features—one by one.

Feature Team 有些资料翻译成 功能团队，或者特性团队。Feature Team 是一个长期存在的，跨功能的，跨组件的团队，他们一个接一个地完成许多端到端的客户功能。

image.png

Feature Team 有以下特征：

• 长期存在的，团队成员待在一起，使得能够保持团结和高效率工作；随着时间推移，他们交付一个接一个的功能特性。
• 跨功能和跨组件
• 同一开发团队的成员位于相同的物理位置，可以进行团队成员之间的面对面协作。
• 围绕同一个完整的以客户为中心的功能特性，由多职能混合的多技能（比如分析，编程，测试等）成员组成。
• 一般由技能专家组成
• 在敏捷中，通常7±2人

2.2 Feature Team 是全功能的跨组件组织

image.png

对Feature Team下文简称FT团队，一个完整的 FT团队包含了完成用户价值功能的专业成员，他们集中在一起，共同承担责任和目标（有些组织里有共同的OKR）。

优势

• 简化的计划
• 高效沟通
• 加快产品上市时间
• 以用户价值为中心交付完整的功能

挑战

• 组织结构的支持
• 成员面对改变的阻力
• 学习曲线长
• 更多工具的需要（比如CI）

影响

• 团队共同责任
• 促使团队产生更好的代码和质量更高的设计
• 减少浪费
• 促使团队学习

由于以“用户价值为中心”，考虑的不再是“交付就算完成了”，而要 “总是选择用户价值较大的”，“要尽快的实现产品/功能则能复用即复用”，“持续的快速交付使得重点关注已完成功能的稳定性，快速修复BUG”，促使团队产生更好的代码和质量更高的设计。

减少浪费，FT团队总是有限选择有价值的功能/特性，总是一个接一个的完成和交付功能/特性。传统的研发组织由多个团队分工合作，同一个迭代难免各个团队工作量饱和程度不一，而各个团队交付物的依赖增加了很多等待事件。

促使团队学习，FT 团队的设置要能完成完整的端到端的功能，对成员的技能提出更高的要求，为了减少了组件之间的依赖性，要求团队成员积极的学习更多的所需技能

3. 选择“职能团队”还是“功能团队”

选择团队结构要从业务出发

在创建敏捷团队时，我们应该做什么？

• 我们应该将产品的功能要素垂直拆分，以使得可以在几乎没有依赖性的情况下更快地交付价值？
• 我们应该将功能划分为一组可重复使用的组件，以确保稳定，高质量和可扩展的系统零件吗？

选择“职能团队”还是“功能团队”，要从业务出发。考虑公司业务的形式和划分组成，其次根据业务考虑组织结构形式。对业务的切分，下面从水平和垂直两个角度进行讨论。

水平切分

概念：水平切片倾向于按技术实现的方式进行分解，这些层和团队成员的技术技能非常匹配，比如：UI团队，前端团队，后端团队，每个团队负责他们各自的任务。

就像蛋糕有很多层，最底下是面包层，中间是奶油层，顶层是些点缀的小水果。这也就是传统的技术堆栈团队，专业线的职能团队的结构。

image.png

垂直切分

概念：将一个用户故事细分成较小的用户故事，这些单个较小的用户故事仍然可以正常工作，是可以演示的软件或是对用户有用的特定功能。

就像切蛋糕，竖着切（垂直切），每块蛋糕上都有草莓，奶油和面包。

image.png

水平切分，或者垂直是我们看待业务的角度。对比两种情形，我们看到FT团队的特点。

FT团队具有执行任务和完成工作的所有技能，比如：一个功能团队里包含了产品经理，app研发，后端研发人员。

image.png

组件团队

组件团队主要关注领域集中在系统的特定组件或一组组件上。他们利用自己的技术技能和兴趣，专注于构建可靠的组件，以提供可靠性，关注点分离，促进重用和改善可测试性。

传统的方法是将产品在逻辑上分解为组件（比如，UI设计，网页部分，java端），并为它们分配完成该组件的组件团队。但是，这些组件与客户的观点完全无关。

组件团队组织的最大缺点：它减慢了价值流。大多数情况下各个组件之间存在依赖关系，这些依赖关系要求各团队之间紧密合作以构建，部署并最终发布。团队花费大量时间讨论团队之间的依存关系以及跨组件测试行为，而不是能够交付最终用户价值。

image.png

FT团队

FT团队具有执行任务和完成工作的所有技能，比如：一个功能团队里包含了产品经理，app研发，后端研发人员。

FT团队方法已成为敏捷团队组织的公认方法，尤其是在持续交付方法中，它强调的是可以解决用户需求的功能，通常可以加速被重视的用户价值功能或软件的交付，并缩短来自真实用户的反馈循环。

4. 怎么过渡到FT团队

FT团队需要更多的工具支撑，CI 持续集成工具是基本保障，自动化测试和 TDD 通常也被使用。分支的合并过程中的冲突解决需要制定一个策略，多个 feature team 同时工作，对分支的管理和版本的发布提出很大的挑战。

从传统团队过度到FT团队时，不同的团队组织需要不同的策略。一般来说，逐渐过度是一种安全且缓慢的方法，即先从现有组织中建立第一个FT团队，待表现良好好，再创建第二支FT团队。这里的表现良好要根据组织自己的情况来看，它反映了组织对团队表现的满意。

5. 总结

FT团队提供在产品研发的一种快速响应市场的研发方式，选择FT团队还是组件团队，没有标准的解决方案，有些Scrum组织推荐使用混合模型，该模型包含了FT团队还是组件团队共存，专业线的组件团队看成大的资源池使用，不过它也包含两种模式的缺点。总之，我们需要根据自身的情况做出选择。