Jira Software + Structure 实现大规模跨团队项目管理实践

跨团队项目开发普遍存在于各大互联网公司，而且随着业务的快速变化，项目复杂度也在不断增加。如果团队业务梳理不及时，这种状况还会不断加剧，项目管理工作直接面临巨大挑战。通常可能会遇到如下问题：

.缺乏项目整体视图；

.无法及时获取项目最新状态信息；

.具体开发人员没有清晰的待办列表；

.度量数据不及时、不准确。

解决上述问题的方法有很多，本文作者李干结合多年对 Jira 和 Structure 的使用经验，向大家介绍一种高效可行的方案。

关于 Jira ，相信大多数 IT 从业者应该都不陌生，它是一种项目与事务跟踪工具。其特点是灵活，可以自定义字段及流程，常用来进行 bug 、审批及项目管理。其中 Jira Software 比较适合敏捷项目管理，其内置的 Scrum 、看板模式本身就是敏捷软件开发的主流框架。

关于 Structure ，它的全名是 Structure for Jira - Projects at Scale ，顾名思义，可以用来维护层级结构，特别对于复杂的项目，尤为有用。其本质上是一个强大的、可编辑的实时报表系统，可以用来产生多个层级及维度的项目报表，从而获得不同层级不同维度的项目视图。

除了层级功能，Structure 还有数据聚合功能。相比 Jira 本身，Structure 的知名度要弱很多，国内应用的也没那么多。

Jira Software 和 Structure ，两者并没有太大依赖，Jira Software 侧重敏捷团队的项目管理，而 Structure 侧重整体视图和报表。即使没有 Jira Software ，仅使用 Jira Core 和  Structure 也是可以搭建使用的，只是敏捷项目管理会困难些。

介绍完了 Jira、Structure ，我们来了解如何使用工具进行流畅的跨团队项目管理？ 

假如我们现在就有一个大需求，需要跨团队协作完成。假设如下：

业务需求：

内容电商项目(内容资讯搭载商品售卖)，由平台产生优质的资讯内容，根据用户的兴趣爱好将内容推荐给用户。在资讯内容中搭载资讯相关并且用户可能购买的商品，从而增加商品的售卖量。

团队配置：

业务及产品团队 – 负责梳理业务和业务需求拆分

CMS 团队 – 负责内容后台及内容服务

APP 内容团队 – 负责内容资讯的应用端展示

搜索团队 – 提供内容资讯及商品的统一搜索服务

推荐团队 – 提供内容个性化推荐服务

商品团队 – 提供商品购买服务

需求大致拆分及对应团队如下图所示：

跨团队项目管理实现过程

总体思路

通过 Jira Software 进行团队级别的需求开发管理，通过 Structure 产生总体视图，从而实现跨团队的项目管理。

1.准备工作

a)Jira 项目创建

我们首先会为每个具体的团队创建团队工作空间，在 Jira 里就是一个 Jira 项目。

b)字段定制

Jira 允许管理员随意定制字段，可根据实际需要做字段的增删。个人建议不要有太多需要填写的字段，以免造成流程过重以及信息的分散。

在本文的示例中，在默认字段的基础上，我们添加了“开始时间”、“完成时间”和“问题/风险”字段来方便强化排期和风险管理。

c)流程定制

.史诗（ Epic ）-- 对应原始的业务需求，是最大粒度的需求

.产品需求（ Story ）-- 对业务需求梳理拆分后的需求，可以分配至开发团队跟进开发。本文中涉及的几个项目团队使用了同一个流程。事实上，不同类型的开发团队流程是不尽相同的，如 APP 类的通常会涉及到合版，服务/h5 类的会涉及到上线。因为我们为每个团队创建了项目空间，因此也支持各团队自定义流程。感兴趣的读者可以自己尝试一下。

.子任务（sub-task）-- 产品需求进一步拆分，具体开发/测试可执行的任务。

2.业务需求维护并拆分产品需求

在【业务需求团队 A 】中创建业务需求（ Epic ），然后拆分为若干具体产品需求（ Epic 下创建 Story），结构如下，目前所有的工作都在【业务需求团队 A 】这个项目空间进行。

3.产品需求完善并分配给团队

在上一步完成需求拆分后，由各需求相应的产品负责人将需求进一步细化，并分配给对应的研发团队，其中分配通过 Jira issue 的移动来实现。

移动完成后，一方面我们保持了业务需求和产品需求的层级链接关系，另一方面使得产品需求到具体的团队链路明确，从而可以进行独立的团队项目管理，从而为后面基于 Structure 建立整体业务需求视图打下基础。

4.研发团队迭代开发

各个研发团队收集到的需求，会自动放入团队的待办列表，团队梳理优先级并确定迭代计划。本文依照 CMS 团队为例展开介绍：

a)需求优先级排序

团队的待办需求列表包含了拆分后的业务需求、团队自有需求以及技术改进类需求。PO /产品经理和团队一起确定需求优先级。Jira Software 中可以直接拖动顺序确定优先级。

b)迭代计划

SM /项目经理根据需求优先级进行任务拆分、任务排期，从而确定迭代计划。为了方便后期的项目进度跟进、风险把控，对于拆分的子任务项需要维护开始时间、完成时间及原始的工作量估计。同时，为了能及时透明项目进度，需要项目团队成员及时更新任务的剩余工作量。

除了 Scrum，Jira Software 还提供了 Kanban 的开发模式，各个团队可以自主选择。

c)任务状态更新和工时

团队需要及时更新任务状态、记录工作内容并维护剩余工作量，以确保系统里有最新的项目进度信息。可以要求团队在每日站会前更新状态，然后在站会时同步下问题，有必要的话再将问题和风险补充到相应字段。

可以在 Jira 中为团队成员创建仪表板，以方便团队成员查看自己的任务和需求。

5.使用 Structure 生成全局视图

Structure 除了生成层级功能外，还可以提供各种数据维度的数据聚合，本文通过以下几个实例简单说明。

a)业务需求视图

业务需求全局视图提供了清晰的 WBS ，除此之外，通过每个项目成员及时更新各自的任务状态和进度，全局视图可以实时提供最新的项目信息。视图中的进度信息可以通过多种方式定义，如状态阶段，工作量完成比例等。关于进度百分比，本文中使用的公式如下：

进度百分比 = 已用工作量 / （已用工作量 + 剩余工作量） *100%

b)研发团队项目视图

研发团队项目视图展示团队项目的整体视图，项目包含业务需求和团队自有需求等。

通过研发资源视图，管理人员可以清晰实时的了解团队成员的工作内容和负荷，从而做出相应决策。

思考与总结

Jira 的优点之一是灵活，但也因过于灵活，很多公司喜欢过度配置，产生非常多的必填字段，导致流程臃长，而实际使用起来却非常不便。最终大家都没有了使用的意愿，慢慢荒废，沦为形式。

使用 Jira 的目的就是提升效率，如果团队都不愿意用，何谈提升效率？建议尽量简化流程，减少不必要字段，让最终团队愿意使用，真正能帮助到团队，而不是成为团队负担。

在团队养成习惯之后，可以考虑适当增加字段和扩展流程，在满足更多的数据度量需要的同时，保证团队都在高效利用。这样才能实现真正意义上的大规模跨团队工具化项目管理。