Atlassian Heroes | 通过 Jira Software+Agile Hive 实现大规模敏捷转型实践

Q1：请介绍您在哪里工作、您的角色以及您所在的团队。

大家好，我是杨晨，目前就职于一家智能汽车科技公司的前瞻研发部门，主要负责研发体系效能提升。

我所在的部门目前在开发基于新一代电子电气架构的智能计算平台，它是一款集智能座舱，自动驾驶以及车身控制等为一体的超级运算平台（参考 BOSCH 电子电器架构演进图-车载电脑一级），是一款面向下一代智能汽车的前瞻性产品（以下简称智慧大脑）。

Q2：您所在的行业或团队有什么样的特点？

在我们行业或者团队有以下几个特点：

1. 团队技术栈复杂。由于智慧大脑是一整套嵌入式软硬件开发的解决方案，涉及硬件设计开发，基础软件开发，上层应用软件开发等，团队之间技术栈差异非常大，甚至于一个团队内部都是一个萝卜一个坑，很难达到敏捷高绩效团队所推崇的T型人才。比如智能座舱中负责音频开发的和负责视频开发的都是不同的领域的专家。

2. 不同领域/团队之间协同紧密。由于智慧大脑集成了车上大量的运算处理，往往一个简单的功能需要涉及多个领域协作完成。比如简单的车道识别功能，需要车身摄像头采集的视频数据，需要自动驾驶域处理视频数据，做出决策并回传智能座舱域进行用户信息展示和交互。

3. 汽车行业需求严谨，需求层次复杂。汽车行业的一个特点是主机厂 OEM 定义需求，供应商如 Tier1, Tier2 等严格按照 OEM 要求提供相应的需求开发交付，所以需求非常严谨，层次也非常复杂。汽车行业的需求往往需要通过专业的需求管理工具进行管理。

Q3：使用 Jira Software 和 Agile Hive 工具时会遇到什么样的挑战或问题？

在引入 Agile Hive 之前，最初的设计已不能满足团队的使用需要，主要的问题点在于：

1. 团队规模以及结构和 Jira 配置不匹配。由于团队已经达到近 300 人，并且根据专业不同分成了5大域（智能座舱，自动驾驶，车身控制，基础软件，硬件研发），每个领域又细分多个子团队。这么多团队都配置在一个 Jira 项目中，仅仅通过不同的看板过滤器加以隔离，不管是权限配置还是团队数据分层展示都很难操作。

2. 复杂的需求层次和单一项目 Backlog 之间的矛盾。在团队的实际应用过程中，我们发现一条原始需求经过系统到软件的拆分，到不同域之间拆分，再到不同团队的不同的团队成员，至少要3层以上结构。仅仅使用 Jira 原生的 Epic->Story->子任务的层级结构非常勉强。在一个项目的 Backlog 中维护起来，颗粒度不均匀，维度各异，通过单一 Backlog 根本没法了解到产品的全景，以及对单一 Backlog 进行有效优先级排序。

Q4：请分享您在应用 Jira Software 及 Agile hive 插件在大规模敏捷方面的实践经验

应用准备

在引入工具之初，我们需要做几方面的工作需要谨慎对待以做到事半功倍。

1. 产品团队组织结构梳理。根据走访调研，我们和各团队负责人对齐了L1/L2/L3三层团队组织结构，分别对应了整个产品系统/各个域/各域下辖子团队。

2. 需求到任务的层级梳理。结合团队需求逻辑层次，我们设计了4层需求模型，特性组（Feature Group)->特性(Feature)->域子特性(Sub-Feature)->任务(Task)。特性组是为了把零散的特性组织起来，而域子特性是只是某域针对某特性需要完成的工作，并不是完整可交付的需求。任务是一个人可以独立完成的颗粒度。大致如下图所示，考虑到并非所有的需求都是特性（Feature)，还引入了使能（Enabler）。

3. 插件工具的横向对比。在确定了我们的需求之后，就是工具的选型工作。我们在Atlassian市场中找了多款工具，比如Agile Hive、BigPicture、Portfolio、Easy Agile等。然后在团队试用后，从功能完整度（大规模敏捷场景的支持）、易用性、价格、技术支持等多方面考虑并加权评分后，选定了Agile Hive.

应用配置

应用的配置相对来说比较简单，主要围绕项目团队结构以及需求层级两个维度开展。

在团队层级上，我们在最顶层加了一层 Level 0,为的是区分前瞻和其他兄弟部门，Level 1 相当于 SAFe 的 Portfolio 一层，也是产品 Backlog 的最高级别；Level 2 相当于 SAFe Program ART 一层，对应各个域以及实现 Level 2 需求的创建和 Level 1 需求的关联；Level 3 是团队一层，每个团队大概 5~9 个人左右，实现 Level 3 任务的创建和 Level 2 需求的关联。

注意：每个实体都是一个完整的项目，可以独立配置自己的看板，成员权限等。（示意图如下）

最终形成的用户界面如下图所示。

项目团队结构设置后，我们看下需求如何层层分解和分配。

我们以 V2X 为例。在 V2X 需求中，车辆可以从其他行驶中的车辆，交通信号灯，天气报告网络，甚至从骑自行车的人和行人那里接收无线传输，以更好地了解周围的世界并与之互动。这样的一条需求是需要跨多个域实现，是一条系统级需求。所以我们在 Level 1 的项目中创建了一个条目，并指派到需要承接该需求的域（Cockpit, Vehicle）。

创建后我们可以在 L1 层项目看板中看到该需求，类型为特性（Feature）。

我们来到 Cockpit Level 2 的项目看板，就可以在左侧的 Panel 中看到从 Level 1 指派的需求，并可以创建 Level 2 的域子特性（sub-Feature）并与 Level 1 的 V2X 建立关联，以此来实现需求的从 Level 1 到 Level 2 的分解。

熟悉 Jira 配置的朋友应该知道，这里的面板就是把原生的 Epic Panel 做了重命名，并且 Agile Hive 提供了配置，可以在这里只展示 Level 1 项目中分配给自己域的需求（Feature）。

同理，从 Level 2 到 Level 3 的分解依然采用类似的配置，以实现将 Level 2 拆分的需求（Sub-Feature）指派给 Level 3 的团队，进行进一步分解到任务。通过这样的方式，来实现多层需求的拆解和分配，可以清晰地了解需求的全貌，也可以保障需求的可追溯性，为后续实现 PI 规划，版本规划奠定了良好的基础。

Q5：回想一下，您在实践过程中有哪些重要经验可以帮助其他人员或团队实现大规模敏捷的应用。

大规模敏捷应用的基础是正确的小团队敏捷落地。如果团队敏捷基础不牢固，在转向大规模敏捷的过程后，往往发现上层问题很多。

因地制宜，选择适合团队的大规模敏捷框架。目前市面上大规模敏捷框架很多，SAFe、LeSS、S@S, Spotify 等，我们首先要问的是，我们的产品规模需不需要大规模敏捷框架，然后再充分了解不同框架的特点后按需选择或者定制自己的框架。

Q6：您能给一个新的 Jira 管理员或新使用 Jira Software 及 Agile Hive 插件实现大规模敏捷的人员一些建议吗？

做好前期调研和方案的设计，方可事半功倍。这里需要注意的项目团队组织结构，需求分解层级这两条线，这些配置上的需求决定了我们的最终的工具选型。

团队认知对齐，避免陷入混乱。需要针对不同层级的使用对象进行不同的培训设计，比如不同层级需求负责人如CPO/PO，不同层级的项目管理人员（RTE/SM)。

分批推进，降低冲击。在工具切换的过程中，我们采用了2/4/4的推进节奏，也即第一批试点团队，主要是踩坑排雷，总结经验；第二批推广是在积累一定信心后覆盖到核心团队；第三批推广收尾主要针对前期偏保守的团队。

总之，不管是大规模敏捷应用，还是工具导入都不是一蹴而就，需要相关的管理人员，各领域专家保持着开放的态度，目标一致，层层推进。