SAFe敏捷发布火车ART案例分析-汽车公司里面的百人级团队

“Nothing beats an Agile Team， except a team of Agile Teams” 

---SAFe

      本案例来自于某汽车公司里一个百人级团队，该团队所开发功能是完全面向车主的，追求最佳用户体验。

01—转型前面临困难

    在该团队启用SAFe ART之前，多个10来人团队已经进行了小团队Scrum尝试，取得了不错的效果，但也发现在更大规模协调上存在困难，突出痛点是关联需求往往拖期，识别到的明显困难是小团队之间存在相互依赖，而PO与小团队存在多对多关系，也就是说有些小团队对应的PO不止1位，而有些PO所对应的小团队不是都只有1个。

02—转型策略选择

      该公司考察了多个规模化敏捷方法之后，决定参考SAFe，按照SAFe的敏捷发布火车（Agile Release Train-ART）来组织其多个小团队到百人级团队。其中选择SAFe的一个原因是SAFe在规模化方法调查当中一直排名第一，而且明显领先第二名。

03—敏捷发布火车ART理论简介

      敏捷发布火车（ART）来自于SAFe，本章内容来源于SAFe官网（点击原文链接可以访问SAFe官网上ART详细介绍）。ART是长期存在的敏捷团队，与其他利益相关者一起，增量式地开发、交付和运营（如果适用）同属一个价值流的一个或多个解决方案。敏捷发布火车使团队能够对齐共同完成业务和技术任务。ART是一个虚拟组织（通常为 50 – 125 人），共同计划、承诺、开发和部署。ART 围绕企业的重要价值流进行组建，其存在只是通过持续建设为最终用户送去收益的解决方案而实现承诺的价值。ART是跨职能的，具有定义、实施、测试、部署、发布和运营（在适用的情况下）解决方案所需的所有能力（包括软件、硬件、固件和其它功能）。ART 提供连续的价值流，如下图所示。 

图1ART价值流示意图-引自 SAFe官网

如果原来的组织结构是按职能划分，那么ART的组建需要从各职能部门/科室当中寻找所需能力，如下图所示。

图2 从职能组织ART-引自SAFe官网

ART组建后，得到一个团队之团队（Team of Teams）结构，示意图如下。

图3 团队之团队示意图

在一线团队组织上，SAFe鼓励首选按特性团队来划分，也允许划分出公共的组件团队。团队一词在不同语境下有不同规模，下文用小队来指明一线团队，就是上图中的Team。

在迭代开发，SAFe ART有个很有特色的做法是ART上各个小队迭代同步进行，如下图所示。

图4-ART各小队同步进行-图片来自于SAFe官网

也就是说，同一个ART上所有小队同时启动迭代，同时结束迭代，可以形象地比喻在同一列火车上，每个小队可以类比到一节动车车厢。

04—本案例细节策略

RTE

本案例在Team of Teams上个参考了SAFe ART，识别安排了RTE（Release Train Engineer），RTE是敏捷发布火车的仆人式领导者和教练。RTE 的主要职责是促进 ART 活动和流程，并协助团队实现价值。RTE 与利益相关者沟通，升级障碍，帮助管理风险，并推动持续改进。

产品管理

本案例也参照SAFe识别安排了ART所需的产品管理，SAFe对产品管理的概要说明如下：产品管理负责定义和支持构建可取的、可行的并且可持续的产品，在产品市场生命周期内满足客户需求。SAFe本身没有定义产品管理只是一个人担当，还是一组人担当，这两种方式都可以。在本案例当中，对应的一位富有经验的产品总监担当了产品管理，他本身是所有PO的上级。

小队划分

在小队划分方面，采用了混合策略。对于直接面对最终用户的系统，主要按特性团队方式组建，而对于不直接面对最终用户的系统，主要按照公共组件团队方式划分小队。在实质上还是更多地根据IT系统现状情况划分了小队，而略有调整，有些IT系统对应单一业务领域，那么正好符合特性团队特征。在现状基础上参照SAFe ART模型进行适配，作为起始步骤，这是一个平滑稳妥的起步做法，但未必是长期做法，随着后续运作，值得观测并必要调整。

架构师

SAFe安排了ART架构师，并且说明了架构跑道（architectural-runway）。本案例参照SAFe安排了ART架构师，同时建立了架构组，ART架构师为首，各小队的技术领导（Tech Lead）作为成员，召开每迭代例会来对齐技术方面事宜，其中一个关键活动是识别技术方面故事，这与最新SAFe里面架构师担当技术方面PO是一致的。

规划活动

在季度级规划上，SAFe PI（Program Increment，典型4+1迭代共10周）planning是SAFe特色的实践，其特征是全ART所有人一起开会，花费约2天时间对未来10周进行计划，由于人数众多，要在现场面对面交流的话，就需要百人级的会议室，这活动也有Big Room Planning的形象称谓。不过本案例并没有模仿SAFe的PI，原因是其发布频度已经是每月1大1小2个版本，更加注重半个月时间尺度上的响应，而不是在10周（2个月多）尺度上的可预见性。

SAFe PI planning有个重要产出是program board，如下示意图。

图5-ART Program board-图片来自于SAFe官网

上图展现了小队之间的相互依赖关系，注意上图中甚至有同一个迭代之内的依赖关系。虽然本案例没有举行PI planning会议，但也必须解决小队之间依赖关系的识别和管理。本案例就采用了迭代计划来解决依赖识别和管理，在产品总监统一协调下，开展迭代级的依赖关系识别和跟进，在工具上各小队把待办项放到一起，再识别依赖，再可视化跟进。

05—本案例主要具体措施

以上策略确定之后，来看主要的具体措施。

支持RTE和Scrum Master

RTE显然是ART运作的关键，笔者在这个案例当中与内部RTE结对工作，尤其是在前期，笔者也算是兼职的RTE。对于RTE和Scrum Master的辅导，采用了经典的3A方式。3A分3步：

第1步-Act，教练直接在一线动手做，让被辅导者观摩学习；

第2步-Assist，被辅导者在一线执行，教练在旁边提供辅助，事后与被辅导者一起复盘；

第3步-Answer，被辅导者独立运作，把遇到的问题提给教练，教练与他一起寻求解决方案。对于Scrum Master的辅导，主要是支持内部RTE担当，是3A方式的典型应用。

支持产品总监和PO

同样地，产品总监也是ART运作的关键。本案例的特殊情况是该产品总监不是100%时间在这个部落上，他同时看顾3个部落，还有兼顾其它事务，因此本案例对于产品总监和PO的支持，关键的地方有2大要点：

• 1，在前期对齐产品管理方面的规则和工具。具体上结合先锋PO试点情况，得到产品方面改进的初步方案和首批样例，然后沟通对齐，在全部落采用相同做法； 

• 2，运行中回顾，持续发现不足和持续改进机会，回顾的时间跨度上参照了SAFe的PI长度，约每2个月进行一次产品总监和PO全员参加的部落级回顾。

支持架构师

对于架构师的支持，本案例重点在于如何对接来自于业务和技术两方面的待办事项，协调业务方PO和技术方架构师建立统一Backlog，并且协调产能容量分配和业务-技术优先级。

建立ART统一Backlog

本案例选用了JIRA作为工具，采用单个JIRA项目对应一个ART，以Epic-Story|Task两级来建立了Backlog，Epic对应SAFe中Feature，Story是来自于业务的用户故事，Task是来自于技术的任务，两者平级，一起放在Backlog。

利用JIRA原生的component字段来标注细分的模块，细分的标准是该模块只归属于1个小队，无论小队后续如何调整，Component该字段支持灵活的多选，这样特别适合在ART层面识别多个小队协同的Epic。利用JIRA关联功能，能够方便地建立任何两两的依赖关系。

建立Epic-Story看板

原生JIRA不能够生成如上面Program Board那么形象的依赖线，补偿办法是建立Epic-Story看板，利用依赖识别JQL（需要扩展JIRA）在面板里面利用颜色把有依赖的卡片显示出来，再通过卡片情况右侧栏显示依赖关系。这个方案不如示意图那么直观，但也足够用了。另外的补充手段有利用筛选器在仪表板或者Confluence当中显示依赖列表。

建立各小队Scrum面板

识别小队负责的模块，有些小队会负责多个模块，根据这些模块制作筛选器，然后在这些筛选器基础上建立Scrum面板，这些小队面板给到各个小队。同时也建立不区分模块的Scrum面板，这块面板能够看到全部小队的卡片，这是总览迭代全局的面板。

建立ART统一迭代

由于ART火车要齐头并进，案例A中由RTE统一管理了迭代，也就是说同一迭代时间段内，该ART只有一个迭代，所有小队都使用统一迭代。

在JIRA当中，这样操作有个麻烦，首个卡片纳入迭代时，在小队Scrum面板的backlog界面上找不到那统一迭代，得要编辑首个卡片的迭代才能把该统一迭代带到backlog界面。

案例结语

百人级团队的敏捷转型涉及面很宽，以上是本案例的要点，欢迎留言和提问。