银行做规模化敏捷一定要用 SAFe 吗？
不一定。SAFe、LeSS、ADAPT 等框架各有侧重，应根据需求节奏、系统耦合、组织规模和组织文化选择，并通过试点验证。
Agilean 问答指南 / 规模化敏捷
银行规模化敏捷怎么做？ADAPT、SAFe、LeSS 怎么选？
简要回答
银行做规模化敏捷，通常先按业务领域组建与业务对齐的部落和跨职能小队，再统一需求分层、版本节奏和效能度量，从试点部落逐步推广到全行。三个常见框架的侧重点不同：SAFe 以敏捷发布火车（ART，一般 50–125 人）和通常 8–12 周的计划周期（PI）组织多团队协同；LeSS 坚持一个产品、一个 Product Owner、一个产品待办列表和所有团队共用的 Sprint；ADAPT 是 Agilean 面向金融产品部落（50–150 人）提出的框架，强调三层需求分解、“5+3”角色和版本与迭代双维管理。
作者：Agilean（爱捷软件）内容依据本站方法定义页、咨询服务页和公开案例整理
框架对比
ADAPT、SAFe、LeSS 对比
| 对比项 | ADAPT | SAFe | LeSS |
|---|---|---|---|
| 提出方 | Agilean | Scaled Agile, Inc. | Craig Larman 与 Bas Vodde |
| 基本单元 | 产品部落 50–150 人；研发小队一般不超过 12 人 | 敏捷发布火车（ART），一般 50–125 人 | LeSS：最多约 8 个团队（每队约 8 人）；LeSS Huge：一个产品可达数千人 |
| 计划节奏 | 迭代严格串行；系统版本单独管理，支持一个迭代多个版本、多个迭代一个版本 | PI 通常 8–12 周，常见为 4–5 个开发迭代加 1 个创新与计划迭代 | 所有团队共用一个 Sprint，每个 Sprint 产出一个潜在可交付的产品增量 |
| 需求结构 | 需求—系统任务—个人任务三层；系统任务建议不超过 10 人天，个人任务不超过 3 人天 | 史诗（Epic）、特性（Feature）、故事（Story）等多层待办，并有组合层配置 | 一个产品待办列表（Product Backlog），所有团队共享 |
| 关键角色 | “5+3”：部落长、业务负责人、测试分会长、架构师、版本经理；产品经理、小队长、研发小队成员 | ART 层有发布火车工程师（RTE）、产品管理、系统架构师、业务负责人等 | 一个 Product Owner；多个完整的跨职能团队，不设单一专业团队 |
| 版本管理 | 版本与迭代双维管理，设版本经理 | 以 PI 节奏同步，各 ART 建立适合自身的发布流程 | 每个 Sprint 产出潜在可交付增量 |
| 设计取向 | 针对金融部落多数需求 2–4 周上线、系统高度耦合、生产环境通常只有一个最新版本的特点设计 | 为大型企业提供从团队到 ART、解决方案和组合层的完整配置 | 有意保持简单，把单团队 Scrum 扩展到整个产品，引导所有团队关注整体产品 |
SAFe、LeSS 的描述依据其官方网站（见下方“公开资料”），以官方最新版本为准；ADAPT 的描述依据 ADAPT V1.0 原文。ADAPT 原文认为 SAFe、LeSS 有较强的电信行业背景，这是 ADAPT 作者的设计出发点，并非对其他框架的优劣评判。
怎么选
选择框架时看哪四个因素
- 需求节奏：多数需求需要 2–4 周上线，还是可以按 8–12 周的计划周期组织。
- 系统耦合：一个业务功能需要多少系统、多少团队协作完成，是否需要强版本管理。
- 组织规模：一个部落或产品的人数，是几个团队还是数百上千人。
- 组织文化：PO、Scrum Master 等外来角色在本组织是否容易落地，是否需要沿用或重命名现有岗位与术语。
推进步骤
银行规模化敏捷六步走
- 01
选好第一个试点
优先选择需求可控性高、产品人员参与意愿高、测试已与研发合署的团队，例如宁波银行的首个规模化敏捷试点。
- 02
设计部落与小队
按业务领域划分端到端小队，部落可以是虚拟组织，不必先改变现有组织架构；明确部落级与小队级角色职责。
- 03
统一需求分层与版本节奏
建立需求、系统任务、个人任务三层体系，用版本火车和迭代日历把需求准备、开发测试、回归和投产串起来。
- 04
双层看板与工具线上化
部落级需求看板和小队级系统任务看板同时运行，把需求、任务、版本流程放到研发管理工具中。
- 05
建立多快好赞度量基线
在部落、小队和角色层面衡量交付时效、吞吐量、质量和满意度，用数据验证试点效果。
- 06
分阶段推广
先试点、再推广，培养内部教练与效能行会，让机制在更多部落中自运转。
适用条件
适用条件与注意事项
更适合考虑 ADAPT 的情况
- 银行等金融机构在科技侧建立与业务对齐的产品部落，需要让部落顺畅运行
- 业务功能需要多系统、跨团队紧密协作完成，同时必须平衡速度与生产质量
- 已有小团队敏捷实践，扩展到百人或千人规模后需求、版本和角色协同出现问题
可以优先评估 SAFe 或 LeSS 的情况
- 需要完整的组合层治理和成熟的认证培训生态时，可评估 SAFe。
- 希望尽量少增加角色和流程、以单一产品为中心组织多个特性团队时，可评估 LeSS。
- 无论选择哪个框架，都应结合组织成熟度决定流程重度，并保留试点验证环节。
公开案例
相关公开客户案例
数字均摘自对应案例页原文，点击可查看完整案例。长沙银行研发交付时效优化 30%，研发吞吐量提升 35%
分两个阶段：第一阶段试点，第二阶段推广，推广阶段用时六个月；依托“多快好赞”度量体系，用需求分段时效、月度吞吐量等指标建立研发管理闭环。
查看案例 →宁波银行试点团队需求交付时效提升 21%引入 ADAPT 产品部落制与版本火车，划分 5 个端到端小队，并建立需求准入、分支策略、环境管理、自动化测试等实践细则。
查看案例 →上海银行规模化敏捷覆盖超 4500 人（含约 1000 名行员），36 个交付部落、267 个小队规模化敏捷历程分为萌芽探索、试点成型、全面覆盖三个阶段。
查看案例 →华润银行需求交付前置时间缩短 20% 以上以线上贷款产品为突破口，重组团队作战阵形与沟通机制。
查看案例 →某东部农商银行在手机银行财富板块打造敏捷样板间推动业务、产品、研发跨职能融合与协作。
查看案例 →延伸阅读
相关方法论、咨询服务与延伸阅读
相关咨询与培训
- 敏捷研发组织建设跨职能部落小队设计与敏捷导入
- 研发效能度量体系建设部落小队效能指标与数据口径
相关工具
- 知微效能度量中心内建“多快好赞”指标体系
相关方法论
- ADAPT 规模化敏捷框架产品部落敏捷研发章程，面向金融等复杂组织的百人级产品部落。
- RISE 版本迭代节奏版本与迭代解耦、需求澄清前置，破解复杂业务下双周迭代的“小瀑布”。
- DEF 研发绩效指标框架（多快好赞）以“多快好赞”四组相互制衡的指标衡量产能、响应能力、交付质量和业务满意度。
公开资料
- Agile Release Train（Scaled Agile Framework 官方站点）ART 规模、角色与 PI 节奏的官方说明
- What is LeSS?（less.works）LeSS 与 LeSS Huge 的官方说明
常见问题
常见问题
建立部落需要调整组织架构吗？
在 ADAPT 中，部落可以是与业务对齐的虚拟组织，建立在现有需求、产品、开发、测试职能部门之上，不必先改变组织架构。
第一个规模化敏捷试点团队怎么选？
宁波银行的公开案例中，首个试点选择了需求可控性高、产品人员参与意愿高、测试人员已进入研发团队合署办公的团队，以降低导入阻力。
规模化敏捷多久能看到效果？
视范围而定。宁波银行试点推行一年，试点团队需求交付时效提升 21%；长沙银行分两个阶段推进，第一阶段试点，第二阶段推广，推广阶段用时六个月，研发交付时效优化 30%、研发吞吐量提升 35%。
如何衡量规模化敏捷的效果？
ADAPT 按“多快好赞”度量：部落层面看需求从提出到上线的时长、单位时间完成的需求数、人均生产缺陷数和业务满意度；小队层面看系统任务的交付时效、数量、质量和产品经理评价。
想结合你们组织的实际情况讨论这个问题？可以从一个具体的业务或研发场景开始。