使用Jira software+Structure实现大规模跨团
跨团队项目开发普遍存在于各大互联网公司，而且随着业务的快速变化，项目复杂度也在不断增加。如果团队业务梳理不及时，这种状况还会不断加剧，项目管理工作直接面临巨大挑战。通常可能会遇到如下问题：
a) 缺乏项目整体视图；
b) 无法及时获取项目最新状态信息；
c) 具体开发人员没有清晰的待办列表；
d) 度量数据不及时、不准确。
解决上述问题的方法有很多，本文结合笔者多年对Jira、Structure的使用经验，向读者们介绍一种高效可行的方案。
关于Jira，大多数IT从业者应该都不陌生，它是一种项目与事务跟踪工具。其特点是灵活，可以自定义字段及流程，常用来进行bug、审批及项目管理。其中Jira software比较适合敏捷项目管理，其内置的scrum、看板模式本身就是敏捷软件开发的主流框架。
关于Structure，它是Jira的插件，顾名思义，可以用来维护层级结构。特别对于复杂的项目，尤为有用。其本质上是一个强大的、可编辑的实时报表系统，可以用来产生多个层级及维度的项目报表，从而获得不同层级不同维度的项目视图。
除了层级功能，Structure还有数据聚合功能。相比Jira本身，Structure的知名度要弱很多，国内应用的也没那么多。
Jira software和Structure，两者并没有太大依赖，Jira software侧重敏捷团队的项目管理，而Structure侧重整体视图和报表。即使没有Jira software，仅使用Jira core 和 Structure也是可以搭建使用的，只是敏捷项目管理会困难些。
介绍完了Jira、Structure，我们来了解如何使用工具****进行流畅的跨团队项目管理？
假如我们现在就有一个大需求，需要跨团队协作完成。假设如下：
业务需求
内容电商项目(内容资讯搭载商品售卖)，由平台产生优质的资讯内容，根据用户的兴趣爱好将内容推荐给用户。在资讯内容中搭载资讯相关并且用户可能购买的商品，从而增加商品的售卖量。
团队
业务及产品团队 – 负责梳理业务和业务需求拆分
CMS团队 – 负责内容后台及内容服务
APP内容团队 – 负责内容资讯的应用端展示
搜索团队 – 提供内容资讯及商品的统一搜索服务
推荐团队 – 提供内容个性化推荐服务
商品团队 – 提供商品购买服务
需求大致拆分及对应团队如下图所示：
image
跨团队项目管理实现过程
****大体思路****
通过Jira software进行团队级别的需求开发管理，通过Structure产生总体视图，从而实现跨团队的项目管理。
1. ****准备工作
a) Jira 项目创建
我们首先会为每个具体的团队创建团队工作空间，在Jira里就是一个Jira项目。
image
b) 字段定制
Jira允许管理员随意定制字段，可根据实际需要做字段的增删。个人建议不要有太多需要填写的字段，以免造成流程过重以及信息的分散。
在本文的示例中，在默认字段的基础上，我们添加了“开始时间”、“完成时间”和“问题/风险”字段来方便强化排期和风险管理。
c) 流程定制
- 史诗（epic）-- 对应原始的业务需求，是最大粒度的需求
image
- 产品需求（story）-- 对业务需求梳理拆分后的需求，可以分配至开发团队跟进开发。本文中涉及的几个项目团队使用了同一个流程。事实上，不同类型的开发团队流程是不尽相同的，如APP类的通常会涉及到合版，服务/h5类的会涉及到上线。因为我们为每个团队创建了项目空间，因此也支持各团队自定义流程。感兴趣的读者可以自己尝试一下。
image
- 子任务（sub-task）-- 产品需求进一步拆分，具体开发/测试可执行的任务。
image
2. ****业务需求维护并拆分产品需求
在【业务需求团队A】中创建业务需求（Epic），然后拆分为若干具体产品需求（Epic下创建story），结构如下，目前所有的工作都在【业务需求团队A】这个项目空间进行。
image
3. ****产品需求完善并分配给团队
在上一步完成需求拆分后，由各需求相应的产品负责人将需求进一步细化，并分配给对应的研发团队，其中分配通过Jira issue的移动来实现。
移动完成后，一方面我们保持了业务需求和产品需求的层级链接关系，另一方面使得产品需求到具体的团队链路明确，从而可以进行独立的团队项目管理，从而为后面基于Structure建立整体业务需求视图打下基础。
image
4. ****研发团队迭代开发
各个研发团队收集到的需求，会自动放入团队的待办列表，团队梳理优先级并确定迭代计划。本文依照CMS团队为例展开介绍：
a) 需求优先级排序
团队的待办需求列表包含了拆分后的业务需求、团队自有需求以及技术改进类需求。PO/产品经理和团队一起确定需求优先级。Jira software中可以直接拖动顺序确定优先级。
image
b) 迭代计划
SM/项目经理根据需求优先级进行任务拆分、任务排期，从而确定迭代计划。为了方便后期的项目进度跟进、风险把控，对于拆分的子任务项需要维护开始时间、完成时间及原始的工作量估计。同时，为了能及时透明项目进度，需要项目团队成员及时更新任务的剩余工作量。
image.gif
image
除了Scrum，Jira software还提供了 Kanban的开发模式，各个团队可以自主选择。
c) 任务状态更新和工时
团队需要及时更新任务状态、记录工作内容并维护剩余工作量，以确保系统里有最新的项目进度信息。可以要求团队在每日站会前更新状态，然后在站会时同步下问题，有必要的话再将问题和风险补充到相应字段。
image
可以在Jira中为团队成员创建仪表板，以方便团队成员查看自己的任务和需求。
image
5. ****使用Structure生成全局视图
Structure除了生成层级功能外，还可以提供各种数据维度的数据聚合，本文通过以下几个实例简单说明。
a) 业务需求视图
image
业务需求全局视图提供了清晰的WBS，除此之外，通过每个项目成员及时更新各自的任务状态和进度，全局视图可以实时提供最新的项目信息。视图中的进度信息可以通过多种方式定义，如状态阶段，工作量完成比例等。关于进度百分比，本文中使用的公式如下：
*进度百分比 = 已用工作量 / （已用工作量 + 剩余工作量） 100%
b) 研发团队项目视图
image
研发团队项目视图展示团队项目的整体视图，项目包含业务需求和团队自有需求等。
image
通过研发资源视图，管理人员可以清晰实时的了解团队成员的工作内容和负荷，从而做出相应决策。
结语
Jira的优点之一是灵活，但也因过于灵活，很多公司喜欢过度配置，产生非常多的必填字段，导致流程臃长，而实际使用起来却非常不便。最终大家都没有了使用的意愿，慢慢荒废，沦为形式。
使用Jira的目的就是提升效率，如果团队都不愿意用，何谈提升效率？建议尽量简化流程，减少不必要字段，让最终团队愿意使用，真正能帮助到团队，而不是成为团队负担。
在团队养成习惯之后，可以考虑适当增加字段和扩展流程，在满足更多的数据度量需要的同时，保证团队都在高效利用。这样才能实现真正意义上的大规模跨团队工具化项目管理。
