三层需求任务分解体系
需求承载完整业务价值，能够在一次发布中完整上线；系统任务对应一个系统，建议不超过 10 人天；个人任务建议不超过 3 人天。部落关注需求，小队关注系统任务，个人关注个人任务。
Agilean 方法论 / 规模化敏捷
ADAPT 规模化敏捷框架：产品部落敏捷研发章程
定义
ADAPT（Agile Development Agenda for Product Tribe，产品部落敏捷研发章程）是 Agilean 基于十余年金融组织敏捷转型实践提出的规模化敏捷框架。它面向科技侧与业务对齐、由 50–150 人组成的产品部落，用三层需求任务分解体系、“5+3”角色职责、版本与迭代双维管理、3 个层级 16 项关键活动、需求与系统任务双层看板，以及内建的“多快好赞”效能度量，帮助复杂组织实现业务价值端到端的高质量快速交付。
出处：《ADAPT-中国金融企业规模化敏捷框架》（作者：吴穹、李黄容；）
- 英文全称
- Agile Development Agenda for Product Tribe
- 中文名
- 产品部落敏捷研发章程
- 框架类型
- 规模化敏捷框架
- 适用对象
- 金融等复杂组织中与业务对齐的产品部落（50–150 人）
- 核心要素
- 需求分层、5+3 角色、版本迭代双维、16 项活动、双层看板、效能度量
解决的问题
ADAPT 要解决什么问题
- SAFe、LeSS 等国外规模化敏捷框架有较强的电信行业背景，需求和管理体系更复杂，SAFe 的 PI 规划以 8–12 周为单位，与金融组织多数需求 2–4 周上线的节奏不匹配。
- 需求审批流程长，业务倾向一次提大需求、不关闭已完成需求，导致需求范围不断蔓延、颗粒度过大，需求时效难以统计。
- 研发团队快速扩张、忙闲不均，研发投入的合理性和团队绩效难以衡量。
- 个人任务颗粒度过大，任务在看板上停滞一两周，到迭代后期才暴露进度和质量风险。
- Scrum、LeSS 中 PO、Scrum Master 等角色定位与国内组织文化不太匹配，岗位职责难以落地。
- 导入敏捷后只强调迭代管理、忽视版本管理，加剧质量风险。
组成要素
ADAPT 的六个核心要素
“5+3”角色职责
5 个部落级角色：部落长、业务负责人、测试分会长、架构师、版本经理；3 个小队级角色：产品经理、小队长、研发小队成员。部落可以是虚拟组织，不必改变现有组织架构。
版本与迭代双维管理
迭代严格串行，管理小队的研发容量；系统版本管理某系统在同一时间点上线的系统任务，提供质量管理视角，并支持一个迭代多个版本、多个迭代一个版本等混合场景。
3 个层级、16 项关键活动
需求层 6 项（需求优选、细化、排期、澄清、验收、部落月度回顾），系统任务层 4 项（系统任务梳理、小队迭代计划、每日站会、迭代回顾），系统版本层 6 项（年度规划、规划调整、合入检查、封版、回归、发布）。
需求与系统任务双层看板
部落级需求看板从产品需求、优选需求、需求细化、就绪需求、排期需求一直到上线需求；小队级系统任务看板包含待办、纳版、优先、编码自测、代码评审、桌面检查、功能测试、系统联调、研发完成。
内建部落小队效能度量
按“多快好赞”度量：快代表响应力，多代表交付数量，好代表交付质量，赞代表周边满意度，并分别落到部落、小队和角色层面。
速查
ADAPT “5+3”角色一览
| 角色 | 层级 | 核心职责 |
|---|---|---|
| 业务负责人 | 部落 | 部落的业务带头人，负责产品整体范围和优先级决策，需求优先级冲突时给出最终决策 |
| 部落长 | 部落 | 部落的交付负责人，负责部落交付和资源配置，对部落最终绩效负责 |
| 测试分会长 | 部落 | 测试资源的管理者和质量防线的设计师，守护部落交付质量 |
| 架构师 | 部落 | 系统架构的守护者，对系统发展和技术路线做长期规划，在设计分歧时仲裁 |
| 版本经理 | 部落 | 部落交付的最后一棒，规范系统版本制备过程，对接运维并监控上线全过程 |
| 产品经理 | 小队 | 负责产品规划，把业务创意转换为研发可理解的需求，并验收研发交付 |
| 小队长 | 小队 | 组织小队成员交付需求，管理研发容量、进度和质量 |
| 研发小队成员 | 小队 | 产品经理、开发、测试混编，一般不超过 12 人 |
原文建议产品经理与开发人员配比在 1:6 到 1:10 之间；部落级敏捷教练由上述角色兼任，组织可另设组织级或领域级敏捷教练。
适用场景
什么时候适合使用 ADAPT
适合的情况
- 金融等复杂组织在科技侧建立与业务对齐的产品部落，需要让部落建立后顺畅运行
- 业务需求复杂、系统高度耦合，业务功能需要多系统、跨团队紧密协作才能完成
- 多数需求需要在 2–4 周内上线，同时低质量发布可能造成资金损失，必须平衡速度与质量
- 已有小团队敏捷实践，但扩展到百人或千人规模后，需求、版本和角色协同出现问题
使用边界与注意事项
- 流程重度可以由每个部落甚至每个小队自行决定：轻量流程适合高成熟度组织和高质量系统，低成熟度组织适合相对较重的流程。
- 原文建议按组织习惯重新命名“需求、系统任务、个人任务”，以降低导入成本。
- ADAPT 有意不使用“用户故事”这一术语，避免在大型组织中造成沟通混淆。
框架关系
与其他 Agilean 方法框架的关系
研发效能度量
DEF 研发绩效指标框架（多快好赞）
ADAPT 的效能度量部分把 DEF “多快好赞”指标按部落、小队等不同层级细化。
查看定义 →迭代与版本管理RISE 版本迭代节奏
ADAPT 的“版本迭代双维管理”和“需求澄清前置”，与 RISE 的版本迭代解耦思路一致；RISE 给出细化到每日安排的迭代日历。
查看定义 →精益研发 / 研发效能FLEET 精益效能提升思维框架
ADAPT 的精益流式研发（可视化、限制在制品、小批量）与 FLEET 的看见、整流、小批思路相通；FLEET 也把部落制作为大型组织建立需求优选机制的方式。
查看定义 →AI 组织转型5+2 AI组织转型新范式
AI 组织转型会放大组织系统的优点和缺口。ADAPT 让复杂协作先进入稳定、透明、可改进的状态，是推进 5+2 的协作基础。
查看定义 →延伸阅读
相关服务、产品、案例与延伸阅读
相关咨询与培训
- 敏捷研发组织建设跨职能敏捷部落小队的组织设计与导入
- 研发效能度量体系建设部落小队效能指标与数据口径
相关工具
- 知微效能度量中心内建“多快好赞”指标体系
公开客户案例
- 长沙银行：研发交付时效优化 30%，研发吞吐量提升 35%依托 Adapt 框架“多快好赞”度量体系，分试点、推广两个阶段推进部落化转型
- 宁波银行：规模化敏捷试点，交付时效提升 21%引入 Adapt 框架及版本火车等落地方案
- 上海银行 4500+ 人规模化敏捷实施案例从萌芽探索、试点成型到全面覆盖
- 某华北地区农商行项管系统的革新之旅知微效能度量模块脱胎于 Adapt 规模化敏捷框架
常见问题
关于 ADAPT 的常见问题
ADAPT 规模化敏捷框架是什么？
ADAPT（Agile Development Agenda for Product Tribe，产品部落敏捷研发章程）是 Agilean 基于金融组织敏捷转型实践提出的规模化敏捷框架，面向 50–150 人的产品部落，包含三层需求任务分解、“5+3”角色、版本与迭代双维管理、16 项关键活动、双层看板和“多快好赞”效能度量。
ADAPT 和 SAFe、LeSS 有什么区别？
SAFe、LeSS 有较强的电信行业背景，电信行业许多功能需要千人级组织完成，需求和管理体系更复杂，SAFe 的 PI 规划以 8–12 周为单位。ADAPT 针对金融部落 50–150 人即可交付相对完整业务功能、多数需求 2–4 周上线、系统高度耦合、生产环境通常只有一个最新版本等特点设计，需求层级更简单、节奏更短，同时保留版本管理。
ADAPT 的“5+3”角色分别是什么？
5 个部落级角色是部落长、业务负责人、测试分会长、架构师和版本经理；3 个小队级角色是产品经理、小队长和研发小队成员。研发小队由产品经理、开发和测试混编，一般不超过 12 人。
ADAPT 为什么不使用“用户故事”？
在大型组织中，用户故事的业务价值要求常被抛弃，只保留“由一个小队交付”的含义，实际上相当于 ADAPT 中的系统任务；而从强调业务价值的角度看，它又对应 ADAPT 中的需求。为避免混淆，ADAPT 放弃了这个术语。
ADAPT 中还有敏捷教练吗？
ADAPT 认为敏捷应成为每个角色都能理解的内容，部落级敏捷教练由部落内角色兼任，而不是单独设置；企业可以设置组织级或领域级敏捷教练，转型初期也可以引入外部顾问培养内部敏捷人才。
ADAPT 如何度量部落和小队的效能？
ADAPT 按“多快好赞”度量。部落层面，快看需求从提出到就绪、从就绪到上线的时长，多看单位时间完成的需求数，好看人均生产缺陷数和系统可用率，赞看业务满意度和业务指标达成；小队层面则以系统任务的交付时效、交付数量、质量和产品经理评价来衡量。
企业如何开始导入 ADAPT？
通常先调研目标组织的问题、流程和工具体系，再挑选试点团队设计部落小队和度量方案，通过数轮迭代辅导固化机制、培养内部种子，最后复盘并制定推广计划。导入时可按组织习惯重新命名需求层级术语，并根据成熟度选择流程重度。
本页依据 ADAPT V1.0 原文整理，框架后续版本的细节以 Agilean 官方材料为准。
想判断 ADAPT 是否适合你们的组织？可以从一个真实问题开始讨论。