大型研发团队敏捷实践落地 - 基于SAFe的大规模敏捷协作

随着敏捷开发的普及，各类敏捷管理⽅法已被业界充分实践。但是在数百人或千人级别的研发团队进行协作时，简单的复制小团队的敏捷方法却会遇到诸多问题。SAFe 作为⽀持⼤型研发团队敏捷落地的一种方式，重新定义了可扩展的敏捷框架模型，同时也降低⼤型团队管理的复杂性。给大家分享在 ONES 发展过程中，我们的产品研发团队对于敏捷和 SAFe 的应用。

当我们是几个人的小团队时，用简单的物理看板就解决了大部分的管理协作问题，然后团队人数继续增长，我们引入了 Scrum，一直保持着多个 Scrum Team + 矩阵式架构的模式。

 

但是团队规模还在继续增长，简单复制 Scrum Team 的模式也不可避免的出现了一些弊端：

• 部门内，组员不清楚整体的大目标，容易出现局部改进；而从决策者角度，需要保证业务价值最大
• 部门间，因角度不同，各个部门对同一问题很容易出现分歧
• 团队规模增长，不能再简单地拍脑袋做产品改进，迫切需要数据支撑，但是缺少度量的手段和方法，导致改进没有方向

 

基于以上这些问题，我们团队梳理出了大型团队的管理需求：

• 各个敏捷小组需要定期的沟通整体业务目标
• 业务、产品、技术等各类任务需要统一制定优先级标准，业务效率优先，兼顾职能效率
• 有效的量化方法

 

为了满足这些需求，我们团队做了五件事：

 

引入 PI（项目群增量）会议和 PI 回顾会议

所谓的 PI 会议，其实就是包括4个角色的人参与的，每个月或者每个季度召开的会议。开这个会的主要目的有两个，一是确定出统一的优先级，二是解决部门间对齐和沟通问题。

 

参加会议的4个角色包括：

• BO：最终负责人，可以简单理解为 PO 的直接上级，他不是管一个两个迭代，而是在多个迭代一起去做的时候，关注业务目标问题
• 所有小组的 PO（产品负责人）
• SA 小组，也就是架构小组，他们主要是负责表达技术的改进需求
• 利益相关者，主要是指外部的业务部门或是客户

为什么是这4个角色呢？一是因为这4个角色加起来可以涵盖我们平时做规划时的所有角度，二来也可以解决部门间的沟通问题。

在确定优先级时，我们采用的是 SAFe 框架里的 WSFJ（加权最短作业优先）

 

WSFJ 的衡量方法，分子是产出，分母是成本，但是官方维度和国内的国情不太一样，我们在采用的时候，从我们的角度稍微地改进了一下。

对于产出部分，我们定了两个指标，一个是延迟成本，另一个是产品/技术价值/故事点。

举个栗子解释一下什么是延迟成本，假设一个需求，现在把它做了，我们服务到的客户可以为我们赚50万，如果我下个月再做，有一部分客户会流失，有一部分客户可以等，那下个月再做出来的收益是20万，这中间的差距30万就是延迟成本。

 

在做 WSFJ 还有几点需要注意的事项：

• 在做估算的时候应该要根据实际情况调整加权计算内容
• 工作项的规模相差的不应该太大，不能一个需求是一两周可以做完的，而另一个需求是三个月才能做完
• 对于一些无法直接量化的内容，可以采用「敏捷估算」的方法确定数值

 

「敏捷估算」是基于Delphi估算的一种估算方法，可以简单地理解为，通过一次又一次的沟通，最后达到一个相对大家统一认可的结果。

 

引入 PI（项目群增量）回顾会议，获取反馈

在我们引入一个计划会议的同时还引入了一个回顾会议，目的是为了总结计划的执行情况。PI 回顾会议类似于敏捷中的迭代回顾，需要演示已完成的功能、收集反馈并将问题加入到 Backlog 中在下一次 PI 会议讨论。

 

加入新角色，调整组织架构

刚开始提到过，我们团队之前是矩阵式的一个架构，可以从图中看到，有一组、二组、三组，每一个小组都是一个五脏俱全的迭代小组，也会有一些职能组。

 

新的组织架构里，出现了新的4个角色。业务负责人（BO）是前面提到的，管理着所有的 PO；流程管理（RTE），负责搭起所有的流程；产品管理(PMgmt)类似于产品总监，负责所有产品的规划；系统架构(SA)类似于技术总监，负责的是性能上的、大的结构上面的改进。这种架构的改变，实质上是由矩阵式的结构变成了树状的发散结构。

 

 

度量，需要使用工具结构化数据

在度量方法上，我们采用工具结构化地存储工作数据，然后像运营一样去观察，然后想改进办法去执行，执行完再观察，形成一个闭环。

 

 

经过我们的实践总结，ONES 主要关注的度量维度是:端到端数据，比如客户满意度（业务部门满意度）、特性前置时间、软件发布质量。

 

 

DevOps 自动化

DevOps的概念非常大，我们目前着重的是自动化建设。我们有两个原则，第一是能够尽早发现问题，这也是我们在选择很多东西时所秉承的原则，它也能降低复杂度；第二是流程固化到工具里，让工具、软件建构工作复杂度。

 

 

关于自动化测试，一个非常重要的，也是 ONES 受益非常大的一个实践——质量内建。质量内建要求我们做好软件开发每个环节，尽早预防，以降低缺陷出现后的修复成本，要减少对创可贴式的补丁（hotfix）的依赖。

ONES 内部的质量内建坚持两个准则，一是自动化测试，从接口测试入手，二是坚持自动化用例执行率100%才算完成。

 

注：本文中 WSFJ 属性估算等功能截图来自 ONES-企业级研发管理工具