这是鼎叔的第七十三篇原创文章。行业大牛和刚毕业的小白，都可以进来聊聊。

欢迎关注本专栏和微信公众号《敏捷测试转型》，星标收藏，大量原创思考文章陆续推出。

之前的敏捷实践介绍文章，都是以单个团队（独立交付特性的敏捷团队）的视角来描述过程的，这样的团队人数通常是 5-9 人，建议最多不超过 15 人。但实际上，知名公司敏捷转型往往涉及大部门的所有员工，甚至跨多个部门一起进行敏捷开发，相关全职人力动辄 50 人以上，甚至高达数百人。因此我们有必要引入大规模敏捷实践框架，对于多个特性团队（8 个以上，甚至数十个团队）联合研发，该如何协调，交付更高层次的价值呢？

下面基于行业普及率很高的大规模敏捷框架-SAFe，简单介绍一些基础知识。

PART1 SAFe 核心知识简介

SAFe（Scaled Agile Framework）是应用于大型企业的精益敏捷实践框架，已在众多世界 500 强公司中实施并获得成功，能够大幅提升生产率、质量和员工满意度，实现企业范围的可见性。目前该框架已经迭代到 6.0 版本。

之前介绍的 Scrum 主要从一线特性团队的视角来阐述具体的工作流程和原则，SAFe 对更高层次的大团队视角进行了拓展，包括项目集层面，和项目组合层面。SAFe 的知识理论来源很丰富，包括精益，敏捷，DevOps 实践，系统思考领域等。

下面是 SAFe 的实施路线图，为实施 SAFe 变革的领导者提供行动指引。

项目集层面

项目集团队，管理一定数量的敏捷小团队，完成更大的企业目标，向客户交付完整的大型产品、系统或服务套件。相对于小团队敏捷，项目集面临更多的组织挑战，包括：愿景和路线图的维护，管理多团队的发布节奏，保障定期集成的质量，清除小团队无法控制的阻碍，面向终端用户部署整个系统。

在项目集团队中，单个的敏捷小团队可以区分为特性团队（对特性独立交付负责），组件团队（专门提供某一类架构能力，支撑特性团队的专项团队），此外项目集团队还要设立一个系统团队，和一个发布管理团队。前者负责项目集全局的系统测试，系统持续集成和开发基础设施。后者负责发布治理权限，面向终端用户交付高质量的解决方案。

为了确保多个团队交付功能的同步，项目集定义了 ART（版本发布火车机制），以固定的时间频率（通常是 2-3 个月左右）完成一个可发布的增量内容（PI）。多个敏捷小团队在每个 PI 周期之初都要进行一次联合会议，制定 PI 的发布计划，澄清各团队彼此的依赖关系和风险，并记录行动措施，更新整个项目集团队的路线图。

项目组合层面

对于更高的企业视角，驱动的技术团队动辄数百人甚至上千人，那就需要定义产品主题（或者称投资主题），即能带来差异化市场竞争力的产品/服务价值主张。对此进行决策的是项目组合管理团队，通常由 BU 层面的决策者在每年的预算时作出。除了投资主题，管理团队还需要确认技术层面的架构跑道，它包括现有或计划中的基础设施，满足目前需求而不必过分重构，同时也包含系统级的非功能性需求（如性能，安全，可靠性，行业标准，系统设计约束等）。

明确了投资主题，就从中提取出史诗故事（或者称为篇章，Epic），它是大规模的开发行动，实现投资主题价值。同理，也要从架构跑道中提取出架构实现的史诗故事。

简单理解就是：单个独立小团队的迭代发布是以具体特性驱动，拆解为用户故事进行开发；而项目集增量发布是以史诗故事（Epic，投资主题中抽象出的价值）驱动，拆解为特性给到单个团队进行开发；项目组合发布是以投资主题和架构跑道驱动，拆解为史诗故事给到项目集团队进行开发。

PART2 测试启发

一，提供项目集层面的专项测试资源。

对于项目集运作的大型产品或者产品集，除了安排在每个特性团队的专职测试人员，还需要考虑安排合适的专项系统测试人员，负责大型系统层面的质量保障，以期达到交付标准。比如系统级的复杂性能测试，安全渗透测试，升级测试和兼容测试等等。此外还需要指定持续交付测试的负责人，确保每日测试的自动化测试结果是健康的和完整的，出现风险能及时介入分析。

二，在 ART 版本发布火车的流程中建立特性合入的质量标准。

在 ART 指定的集成时间之前，特性团队的版本如果没有达到代码合入主线的质量标准，版本发布火车过时不候，只能在下次 ART 集成时提交了。因此，项目集要对各特性团队确认统一的合入质量标准，并在合入前确认特性测试通过的结果。合入后需要进行各项系统测试，确保合入后的整体质量达到能够系统发布的质量标准。

三、每个 PSI 开始的联合会议上，尽可能确认各特性间测试依赖关系和策略执行风险。

几个月一次的多个特性团队联合会议，是非常难得的一次碰头脑暴的机会，各特性测试负责人和系统测试负责人、主管和测试架构师，都需要利用这次机会好好梳理，搜集系统测试需要掌握的产品和技术知识。例如：

不同的特性测试是否有先后依赖关系，测试次序是否要调整？自动化用例建设是否也需要调整次序？

测试设备和环境是否充足，是否影响并行的特性测试，如果影响应该如何协调？

对于列出的风险，是否已有初步对策？如果没有，谁需要保持观察和优先响应？

对于项目集团队决策的 ART 合入和特性发布计划，及产品路线图，从质量角度看，是否有信心按时完成？

四、评估项目集的测试技术债（技术需求）优先级

和特性评估类似，要综合考虑实现工作量和延迟成本，延迟成本越大，工作量越小，优先级应该越高。

测试技术需求的延迟成本和下列几个因素有关：

商业价值。需求实现能降低多大的公司运营成本？包括能减少多少的测试总投入成本。提高多少用户的体验满意度？
时间价值。实现价值如何随着时间推移而衰减，衰减越快说明优先级权重越高。比如现阶段实现的自动化能力能大幅提高测试效率，但是后期的使用率就可能迅速减少了，那就应该提高优先权重。
让未来的风险降低或者提升新的价值机会。比如越能预警发布质量事故的工具需求，这块权重就越大。

PART3 大规模敏捷的更多思考

1 敏捷企业必学的 OKR 系统，是一个建立明确目标和可衡量成果的协作性框架，因此，OKR 非常适合支持 SAFe 中的核心价值，即投资组合战略的敏捷交付，保持其中的 ART 和敏捷团队工作之间的透明性和一致性。此外，OKR 还可应用于衡量组织改进活动，包括 SAFe 转型的预期成果。

2 最小的独立团队是自组织的特性团队，开发人数 5-9 人，交付物是特性及其用户故事（包括非功能故事），其拆分估算的最小工作单位是任务。

大一些的团队是项目集团队（多个特性团队的集合），交付物是产品的史诗故事，及其特性组合，拥有逐步实现产品愿景的特性发布计划。

最大规模的是项目组合/企业级敏捷团队，按投资主题和架构跑道进行规划，周期一年以上，按篇章（史诗故事）进行交付内容的拆解。

总结一下敏捷团队交付物的大小，从小到大依次是：任务（不能独立交付），用户故事，特性故事，篇章（史诗故事），投资主题或架构跑道。

3 SAFe 组织实践的里程碑是 PI（增量发布），通常每十周可以完成一个 PI 里程碑。

SAFe 变革团队要力争在 3 个月拿出一期业务交付成果，否则可能因为管理层的耐心不足而导致变革中止。按照上面交付物大小的梳理，单个用户故事不要跨迭代交付，单个特性不要跨 PI 交付。

记住：企业高管层引入 SAFe 这类大规模敏捷框架，并不是为了让各个部门更加灵活敏捷，而是要看到交付的价值是否更快更好。团队规模越大，变革的成本越高，务必以终为始，看到上市效率和口碑的提升。

4 SAFe 变革要系统组织团队，让不同特性团队的集成能够快速整合，因此要在组织中设立一个敏捷变革中心，自上而下驱动子团队变革。

一线 scrum 团队可以区分为四类，特性开发团队，组件开发团队，平台系统团队，赋能（专家/教练/管理）团队。后者的成员可能会为多个前者团队对接服务。

5 在一线 Scrum 小团队中适用的敏捷变化措施，一下子拿到大规模团队，借助高管的支持来实施，可能会导致意料之外的负面评价。

比如鼎叔之前文章提到的 “故事点估算实践”，对于一线开发小团队来说是个很好的集体沟通和反思的措施，有利于澄清技术复杂度信息。如果贸然推广到所有团队，让彼此能看到各个团队的故事点，很多人会觉得这是个愚蠢的数据晾晒，不同团队当然估算结果不同，晾晒出来就可能被管理者强制（暗示）拉通。虽然推广它的初衷是不用于绩效和团队 PK，但是一线人员不会这么想，在反对情绪下也不会耐心听解释或自我尝试。

因此，敏捷改进从小团队传播到大团队，还是得借助口碑的力量，谨慎利用权力，优先发挥一线团队的自主性。