说到规模化敏捷，大家通常马上会想到市场上的各种主流框架。诚然，现成的框架能与企业现状较好结合的时候，基于框架的实施是省时省力的。然而，实践中我们经常会遇到的情形是，一方面，企业的情况千变万化，往往跟框架的假定相去甚远，有时候应用现有框架代价巨大；另一方面，框架在具体执行过程中缺乏规范化的实践和工具支撑，流程和实践难以落地。
因此，在华泰证券的规模化敏捷转型中，我们没有直接套用现有的主流框架，而是从单体敏捷团队出发，关注单体敏捷团队敏捷成熟度的提高，逐步演进到更大范围的敏捷规模化协作。在实践层面，借助 Jira 的丰富功能，将规模化敏捷的具体实践和流程落地在 Jira 上，形成有效的流程和工具相结合的规模化敏捷实践。本文以华泰证券规模化敏捷演进为例，分享Jira助力规模化敏捷的几种可行的落地实践。

1. 为什么要引入规模化

当敏捷转型引入 Scrum、Kanban、XP 等管理实践和工程实践时，往往面对的是10人以内的单个团队。对于传统金融企业，应用繁多，调用链长，且很多应用需要同时服务于投资组合内的多个产品。一个简单的需求交付，往往需要涉及几十人、几百人，甚至上千人的协作完成。如何解决如下的协作问题：
- 如何以共同的业务目标凝聚所有人的工作？
- 如何对齐所有团队的节奏，同步进度，管理依赖？
- 如何保持透明性，使产品研发的过程可见，使风险和障碍容易显现，并被移除？
- 如何不断演进自己以适应环境的变化？
这些问题正是敏捷规模化所要解决的问题。在我们的实际转型中，敏捷的规模化也不是一蹴而就的，而是随着敏捷转型的逐渐深入，组织结构和产品结构逐步演化的过程，也是管理实践、技术实践、工具、流程等多方面配套发展的过程。下面以华泰证券某个产品为例，结合 Atlassian 工具的落地，详细介绍一下由单一敏捷特性团队到多敏捷特性团队再到多领域规模化敏捷的演进过程。

2. 单一敏捷特性团队的建立

规模化的基本单元是敏捷特性团队。通常一个敏捷特性团队在5-9人之间，是一种长期稳定的、自组织的、跨职能团队，能够在一定交付范围内完成端到端价值交付。在华泰证券，敏捷特性团队基于 Scrum 框架运行。每个 Scrum 团队有明确的 PO、SM 和团队成员，并统一采用2周作为迭代周期。具体 Scrum 框架已得到了广泛应用，这里不再赘述。
image.png
图1 单一特性团队特征
每个敏捷特性团队的运作，使用 Atlassian 工具进行全流程支撑：
- 每个特性团队拥有一个 Jira 项目。在 Jira 中，每个 Jira 项目不代表实际的运行项目，而是代表一个敏捷特性团队，即 Jira 项目等于 Scrum 团队。
- 每个团队在 Jira 项目中建立唯一的产品 Backlog，团队PO通过 Jira 管理产品 Backlog，并结合 Confluence 来完善产品需求细节。
- 每个迭代开始之前，团队会在 Jira 中创建 Sprint，并根据 PO 定义的优先级和团队速率，决定下个迭代的目标和交付范围。所有的 Story 在 Jira 中拆分成1天左右的细粒度的子任务后，放入 Jira 的 Sprint 中进行管理。
- 每日站会根据可视化的 Jira Sprint 看板，所有团队成员更新 Sprint 看板，同步和对齐当前 Sprint 状态。Jira 提供的燃尽图可以让团队第一时间了解 Sprint 当前进度。
- 此外，Jira 和 Confluence 的结合运用流畅地支持了版本管理、缺陷跟踪、迭代回顾等一系列 Scrum 活动的开展。
image.png
图2 Scrum 在 Atlassian 中落地示例
敏捷特性团队作为敏捷最小交付单元，是任何形式规模化敏捷实施的基本单元。值得一提的是，敏捷团队的成熟度是决定规模化协作顺畅成功的重要基础。因此，华泰证券通过内外部敏捷教练的辅导赋能、敏捷成熟度模型的建立指引和实践社区的文化实践分享等多方面来逐步提高敏捷团队的成熟度。

3. 多特性团队规模化敏捷协作

3.1 多特性团队规模化架构

随着产品规模和复杂程度增加之后，产品团队的规模逐步扩大到几十人，而负责的系统也从原来的单一系统扩展到相关领域的多个系统。这时候，为确保团队的敏捷性，坚持小团队运作，团队需要进行拆分。团队拆分应基于以下几点：
- 拆分后的每个小团队具有完整的小规模敏捷特性团队特征
- 每个小团队可以独立在一定范围内进行端到端价值交付
- 小团队间共享团队间代码，并向无差别团队的方向努力
团队在拆分后，由于各子特性团队依旧工作在同样的产品/领域内，我们依然使用同一个 Jira 项目来管理多个子特性团队。
image.png
图3 多特性团队规模化架构
在各个子特性团队按照 Scrum 框架由 PO、SM 和团队成员组成的基础上，增设领域 PO 角色，这个角色通常是由产品/领域中经验最为丰富的 PO 来担任。领域 PO 负责领域内的用户调研和需求收集，持续梳理领域内唯一的领域 Backlog，拆分故事，探索细节，维护优先级，并对需求进行端到端的跟踪。

3.2 多特性团队规模化迭代运作

整体的单产品/领域多特性团队迭代运作框架见下图：
image.png
图4 多特性团队规模化迭代运作框架
单产品/领域由多个特性团队的运作机制，在 Scrum 基础上加入了跨团队对齐，协作，联合评审和回顾机制：
跨团队对齐：和 Scrum 框架略有不同，迭代计划会分为两个部分开展。迭代计划会第一部分，领域 PO 和团队内 PO 及团队代表一起对齐迭代目标，领域 PO 根据整体产品/领域需求优先级，和团队 PO 一起对齐各团队的迭代目标。迭代计划会第二部分，各团队内部迭代计划会，根据领域 PO 对于各团队目标，团队全体成员拆解和估算迭代任务，创建 Sprint 看板并启动 Sprint。值得一提的是，小特性团队在拆分后，各小团队在一段时期内可能对于负责系统/模块有所侧重。但长期来看，领域 PO 可以通过迭代需求分配来逐渐培养无差别团队的建立。
跨团队协作：在每个特性团队的每日站会的基础上，每周定期开展SOS的同步站会，具体同步迭代中组间依赖的进度。
回顾会：相似于迭代计划会，单产品/领域内多特性团队协作的回顾会通常也分为两个层次：
- Scrum 小组的迭代回顾会：这是源于经典 Scrum 框架的基本检视调整活动
- 领域内联合回顾会：重点回顾和改进组间合作和能力建设等领域内共性问题
各个回顾活动强调自下而上的问题发现，领导层致力于帮助团队解决问题。
3.3 规模化核心能力的Atlassian工具落地
规模化敏捷可能有无数的剖析视角，我们认为，从具体实践落地的角度，规模化敏捷最依赖于以下五种核心能力：目标对齐，节奏，同步，依赖解耦，持续改进。规模化演进的过程，就是对这五种核心能力的持续改进的过程。
image.png
图 5 规模化敏捷的核心能力
下面具体介绍下，在单产品/领域多特性团队的规模化场景下，这五种核心能力基于 Atlassian 工具的落地实践：
目标对齐：产品内所有特性团队共同拥有唯一的一个 Jira 项目，一个产品 Backlog，并由领域 PO 在 Jira Backlog 中统一决定优先级，各团队按照统一优先级在 Jira 中建立迭代计划。领域 PO 在 Jira 中创建 Epic 看板，对领域内需求进行端到端跟踪。
image.png
图6 Jira Epic 看板示例
节奏：各特性团队使用同一个 Jira 项目，分别创建自己团队的 Sprint 来管理团队迭代，所有团队的迭代开始和结束时间对齐。
image.png
图7 统一 Jira 项目，多个 Sprint，相同节奏
不同特性团队的 Sprint 看板可以在 Jira 中整体展现。有些团队也可以通过建立不同团队面板来精细化管理特性团队的 Sprint，如下图：
image.png
图8 统一 Jira 项目，多个看板管理多个 Sprint
同步：组内每日站会通过 Jira Sprint 看板进行同步。每周定期开展的 SOS 站会通过图6中的 Epic 看板进行同步。所有团队成员需在 Jira 上及时更新状态，通过 Jira 可以实时显示团队和领域的燃尽图，展示迭代进度。
image.png
图9 Jira 燃尽图示例
依赖管理：特性团队间存在的组间依赖，通常在 Story 上建立依赖，并在 Jira 中通过建立链接依赖关系来进行管理。通过视图可以看到 Epic 下相关 Story 的开发进度和计划。
image.png
图10 Jira Epic 下 Story 状态视图
持续改进：各级回顾产生的改进事项均会记录在 Confluence 中，并在下一次会议中检查结果。Confluence 可以自动将多次会议行动事项合并在一个页面中，便于事项跟踪。
image.png
图11 Jira 回顾会示例

4. 多领域规模化敏捷协作

4.1 多领域规模化架构

在单产品/领域多特性团队的基础上，产品团队进一步发展，形成多个领域，每个领域中包含多个特性团队，共同负责一个大型产品的多领域规模化敏捷协作架构。多领域规模化团队的组织架构通常如下图：
image.png
图12 多领域规模化组织架构
总体上多领域协作由各子领域团队协作组成，之上增设首席 PO、首席架构和首席 SM 这“三驾马车”角色：
首席 PO 负责构建和传达产品愿景，整体产品规划和设计，完成需求分析并对产品需求进行优先级排序，定义路线图和决定发布计划。
首席架构整体负责架构愿景和高层架构设计，制定架构标准和规范，配合领域 PO 开展产品方案设计，熟悉各子系统的架构设计并对审计进行评审。
首席 SM 整体负责产品的交付，交付的度量和跟踪，协调和组织产品层各种活动，辅导各研发小组的迭代运作，并在产品级识别改进机会和实施改进。
在 Jira 管理中，各个领域按照上节所述的 Jira 运作方式，创建不同领域的 Jira 项目进行管理。首席 PO 使用独立的 Jira 项目管理所涉及的业务需求。

4.2 统一需求模型

随着规模化的扩大，参与团队增多，这时团队间需要建立统一的需求模型，以便团队在各个层级统一工作层级和对齐标准。我们在 Jira 中建立了“业务需求-Epic-Story-子任务”的四层需求模型：
image.png
图13 需求模型
业务需求：来自于业务的需求。在通过 OA 中需求流程后，开发自动同步机制，自动将业务需求在 Jira 中创建。定制化设计业务需求 Jira 工作流，使工作流便于业务和研发对于需求的状态跟踪。业务需求的规模一般限制为研发可在1个月之内完成，最多不超过2个月。更大的业务需求需要进行拆分为多个业务需求以满足此限制。首席 PO 主导业务需求的澄清，产生 PRD 文档。首席架构师主导业务需求的整体架构设计。
Epic：业务需求拆分到每个需求领域所承担的部分。每个 Epic 属于一个需求领域，作为最小上线单元，可能需要跨多个迭代完成。领域 PO 主导 Epic 的优先级排序和 Epic 拆解为 Story。领域架构主导 Epic 的概要设计，Epic 的概要设计需要主架构师审核后才能进入开发。
Story：从 Epic 拆分而来，粒度限制为团队在一个迭代内完成开发测试工作。
子任务：由 Story 拆分而来，规模1天左右，不超过2天，用于精细管理迭代中任务进度。
需求模型的建立，使首席 PO、领域 PO 和团队 PO 可以分别工作在不同层次，便于各层次建立相应的优先级排序，自上而下对齐产品目标。在 Jira 中需求模型的定义基础上，可以建立相应的组织级度量指标，如业务需求层次的端到端业务需求交付周期、业务需求开发周期，Epic 层次的上线频率、上线周期，Story 层次的迭代完成率、迭代速率等。这些指标可以帮助团队用数据进行持续改进，为研发管理提供决策依据。

4.3 多领域规模化迭代运作

多领域敏捷协作的整体框架见下图：
image.png
图14 多领域规模化迭代运作机制
单个大型产品多领域的迭代运作机制，是并行的单领域的多个特性团队运作机制+产品层的对齐机制：
产品层对齐机制：由于业务需求会在研发过程中不断通过不同渠道涌现出来，首席 PO 对于业务需求管理采用持续性过程。首席 PO 持续深入分析业务需求，根据业务需求判断优先级，将高优先级需求整理成为产品需求，并识别需求相关领域。基于业务价值并考虑相关需求领域依赖，首席 PO 和领域 PO 按需开展需求梳理会，将业务需求拆解为相关领域 Epic，并初步对需求优先级排序达成共识。
迭代开始之前的第二周，首席 PO、各领域 PO 和领域 SM 开展跨领域需求对齐会，主要针对跨领域需求当前优先级，确定业务需求在各领域下个迭代的交付范围。
迭代开始前一周，团队 PO 结合产品级需求和团队级需求，确定各特性团队迭代初步范围，并开展需求讲解会，团队内详细讲解需求细节。
单领域多团队运作机制：这里同第三节内容，不在赘述。

4.4 规模化核心能力的 Atlassian 工具落地

针对规模化敏捷五种核心能力，在多领域的规模化场景下，介绍一下在 Atlassian 工具上的落地：
目标对齐：在 Jira 中，业务需求通过统一的backlog管理优先级，依据 Jira 需求模型层层分解，在 Jira 中创建两层看板进行管理。首席 PO 会创建业务需求看板。在业务需求看板上，需求通过架构设计、需求梳理确认、排期等不同的状态来管理业务需求的生命周期。
image.png
图15 Jira 产品需求看板
业务需求通过需求梳理会达成共识后，在各领域 Jira 项目中生成关联的 Epic，并由领域 PO 和团队 PO 进一步将 Epic 拆分为 Story。在迭代计划会上，各研发团队将 Story 拆分成具体实现的子任务，创建迭代 Sprint 看板并启动 Sprint。具体操作过程见下图：
image.png
图16 Jira支持下的需求拆分及关联关系
节奏与同步：产品层所有敏捷特性团队采用同步的两周迭代，在 Jira 中创建 Sprint 开展迭代交付。除了单领域协作中的同步站会，产品层每周二、四开展同步会议。通过 Jira 创建领域 Epic 看板，在产品层同步会中使用领域 Epic 看板管理开展同步。
image.png
图17 领域 Epic 看板
依赖解耦：在之前的单领域多团队协作时，特性团队间的依赖是在 Story 层面进行管理。而在多领域协作中，领域间的依赖在 Epic 层次上管理。
为协助各级 PO 更加高效的完成需求领域拆分和依赖管理，我们在 Jira 上二次开发需求矩阵功能。领域 PO 和领域架构能够针对当前 Jira 上的业务需求，在需求矩阵功能中，高效拆分需求到各相关联领域 Epic。领域 PO 也可以在需求矩阵中完成 Epic 到 Story 的拆分和对齐。
image.png
图18 需求矩阵示例
持续改进：除了多级回顾会议等常规回顾方式，基于 Jira 需求模型的组织级度量指标的建立，给各层级回顾提供了有效的数据基础。同时，在产品级层面，关注价值的端到端交付效率，Jira 提供了需求看板累计流图功能来帮助产品层分析价值交付中的瓶颈。
image.png
图19 Jira 累计流图示例

5. 最后

根据组织结构、项目特性和团队敏捷成熟度等因素，不拘泥于当前业界的主流框架，关注敏捷规模化的五个核心能力逐步演进实践，持续探索协作效率和质量提升之道，是我们进行敏捷规模化的出发点。Jira 的可扩展性和强大可配置能力，灵活助力规模化敏捷的各种应用场景，帮助我们在探索的道路上可以高效地落地规模化敏捷的各种实践。我们希望在敏捷规模化中所做的这些探索能够对你有参考价值，同时也欢迎跟我们一起探讨规模化敏捷开发的实践。