声明：本网站为 Atlassian 官方公众号知识库
甘宇珲，江湖人称金鱼哥，Atlassian 资深企业用户，曾工作于跨国银行及大型消费企业 IT，对于如何使用 Atlassian 产品落地规模化敏捷、跨产品团队协作及外包项目管理有着丰富的经验。
2021年6月2日（周三）晚 7 点，我们邀请到金鱼哥与大家分享历时四年打磨出的 Jira 治理方案，与大家分享：
· 在 VUCA 的时代，规模团队在协同和管理中的常见问题
· 如何规划规模团队的运作模式，在“敏捷”与“管控”中取得平衡
· 什么是“Jira 治理”，在使用 Jira 时需要注意的关键点
彩蛋分享：针对规模团队的场景，金鱼哥现场演示 Jira 与相关实用插件，如 Structure、ScriptRunner 等，结合使用案例与实操，展示工具最牛特性。
内容简介：
演讲嘉宾：
甘宇珲
Atlassian 广州 ACE Leader
测试及效能经理
Q1：Demo-Req 是通过 Epic 跟其他Project 的关联起来的？
理解是正确的，因为我这里设计的是一个按“Requirement-Epic-Story-SubTask”的层级关系，在产品化管理模式中，“Story-SubTask”按产品划分在各自Project中进行管理。
但从本质来看，我们再深化一下。Jira 中的基础单位是 issue，所有功能都是围绕 issue 展开，而 issue 之间的关联方式有两种，一种是强关联（Epic-标准任务-子任务），第二种是弱关联（所有有权限访问的issue都可以通过issue link进行关联，关联关系还可以自定义）。为了更好地管理 issue，Jira 以 Project（说 Jira 空间可能更好理解，就好像excel 中的一个工作表，表内的各行才是真实数据）进行管理。因此从本质上讲，应该是 requirement（在DEMO-REQ这个Jira空间里的issue），以自定义的弱关联（父级）链接到Epic，然后 Epic 以 Epic Link 的强链接，链接到 Story 再到子任务（Epic 和 Story 可以在同一 Jira 空间，又或者分开独立空间）。
Q2：Jira 里可以对需求环节、开发环节、测试环节，分别对 BA/PO、Dev、tester 进行单独的效能度量吗？哪些度量指标是比较推荐的？
首先对不同的环节作度量，就工具而言，功能上肯定是能满足的，但更重要的是整体的设计和使用的规范。Jira 中的统计基础是 issue 以及 issue 中的信息（包括任务类型、时间、经办人等等），因此如何根据管理需要，定义 Jira Project，以及 Project 中包含的 issue（任务类型）、流程还有字段内容等，对做数据统计最为关键。有了规划的基础，就可以定义各环节的统计，例如需要统计的是哪些 Project 中的哪些 issue 中的字段，或者按人维度的某团队、某具体人员所负责 issue 的字段。
度量指标建议从两个维度进行设计，一个是按团队整体效能度量，设置对业务方真实有感觉的指标，如需求按时完成率、发布速率、生产缺陷率、平均生产缺陷修复时长；另一个是按环节度量，目的作为环节改进参考，如需求变更率、开发质量、代码集成平均时长、自动化测试覆盖率等。
Q3：Story 拆分一般是从个开发纬度，测试的角度会跟开发不一样，那么在工时设置的时候有没有什么办法整合？
测试主要任务有需求沟通、测试用例编写和测试执行3项，这3项任务其实是围绕 Story 或 Story 的上级展开。当前我们的做法是，每个 Story 创建时都会自动创建一个编写测试用例的子任务，以表示每个 Story 都要有测试用例覆盖，工时也记录于该子任务；因为我们的结构是 Epic 是独立上线的最小单位，所以需求沟通和测试执行在 Story 的父层级即 Epic 级下建任务（即与 Story 同级）作记录，测试执行也会按版本即发布火车作测试。另外，如果可以的话 Story 尽量按业务角度创建，这样开发或测试任务，都是源自该 Story 的拆解，更贴合业务价值导向。
Q4：项目的管理是通过在迭代团队任务里增加项目的标识，再 JQL 展示在 bigpicture 上吗？还是在 Jira 建立项目维度的项目，而不以迭代团队维度来建立项目？
Jira 就是太灵活了，以至于这两种方式在 Jira 都可以做，而且看到 Jira 上的 Project，我们通常第一反应就是以 Jira Project 对应我们的实际项目，但我更建议的是 Jira Project 按团队或者按产品（系统）建立。
在规模不大的团队中，项目其实以 Epic 标识即可，Epic-Story-SubTask 三个层级足以把月级别项目拆解到按天级别；如果是规模团队而且 Epic 粒度以周为单位，那有需要在Epic 之上增加一个父级以便对整个项目进行管理，增加层级有两种方式，第一种是用原生 Jira 功能，增加一个“项目”的 issue 类型，然后链接到拆解的 Epic 中去；第二种是使用插件功能，在插件中统筹管理所有项目相关 Epic，如 Structure/BigPicture/Jira Portfolio 等都有整体管理的功能，如 Structure，可以建立一个“xxx项目”的Structure 把相关 Epic 纳入进行管理，如 BigPicture 可以建立一个独立的 Program 做管理，Program 下还可以进一步拆分 Iteration。插件管理会比较方便，但做统计就只能依赖于插件本身的功能，灵活性稍差，但一般来说已能满足要求。
Q5：项目管理中 一个问题状态 没有拆分的很细，存在多个经办，对于【处理中】这个状态 A 干完了 转给 B，B 干完了转办给 C。 这样是不是需要优化流程？
最好的做法确实应该分开，以不同的状态代表不同的阶段，这样在做统计时会更清晰知道哪个阶段属于瓶颈。而且在我们触发状态转变的时候，其实是可以自动地更新经办人的，这样能省去一些人工工作。
这里还有一个实践经验是，一个 issue 的流程状态不要定义得太多太长，通常长工作流是没人会去点击的，这样反而偏离了流程设计的本意了，若一个 issue 涉及很长的流程，那可以考虑是否拆解子任务，如问题中所提到的，有几个不同的角色先后要处理各自的任务，可以是 A 有一个子任务，处理完成后便生成一个子任务单给 B，而各子任务使用最简单的“To do, In Progress, Done”这三个状态就足够了。
Q6：您这边 Demo 环境中是一个项目内的需求分成了很多的项目，包括正在说的这个假日管理的项目，都是有什么办法关联起来的呢？
可以这样理解，Jira 中的基础单位是 issue，所有功能都是围绕 issue 展开，Jira Project 可以看作是一个容器把强相关的 issue 装起来，那具体这个容器应该按什么维度去设计就看团队的视角和统计维度去划分了。
对于 issue 之间的关联方式，具体有两种，一种是强关联（Epic-标准任务-子任务），第二种是弱关联（所有有权限访问的 issue 都可以通过 issue link 进行关联，关联关系还可以自定义）。强关联关系无论是在 Jira Issue 的详细页面，又或者是插件中，都是可以直接展开和做统计的，Epic Link 可以作跨 Jira Project 的链接，这个特性我们可以用于跨团队或者跨产品的协作。
在 Jira 中还有另外一个统计维度，就是人的维度，如某个项目参与人是哪些任务的经办人，记录的工时在那个 issue 上，都可以直接搜索和统计。对于假期、沟通、会议这种类型的任务，其实属于一种通用型的任务，一般我们不会放在某个产品 Project 或者团队 Project 中管理，而是独立一个 Project，这样能更方便和其他审批类系统做对接。还有在Tempo 这个插件中，可以定义这种通用型任务，这样工时记录就更加方便了，不用参加个会议就每个人填写个 issue 单，太繁琐。
按这样的设计我们做数据统计时，按人的维度看，可以统计某个项目参与人的参与任务和工时分配；而按照类型来看，如会议，则可以统计在某时间段里，某团队或某人在参与会议上所耗费的时间。
联系我们
想要了解更多 Atlassian Data Center 和 ITSM 解决方案如何帮助您的团队释放潜力，请填写右侧表单，我们会尽快与您联系。
关注 Atlassian 官方公众号
获取产品与服务的最新信息
请提交您的需求
姓名
*
公司名称
*
企业邮箱
*
联系电话
*
是否有指定的合作伙伴
*
留言
*
提交
|
|