JIRA 报表使用浅析

JIRA

首先，贴一下官方报表的说明文档的链接：跳转
最近读了一本书，书中有一句话，大致意思是：文章太长时，大部分人其实都不会读完它。
觉得很有道理，但是这篇JIRA还是没办法的写了很长。
希望这是本人最后一篇JIRA的博文。耶。

与Scrum sprint相关的报表

1. Velocity Chart

Velocity Chart

该报表会在对应sprint complete之后生成出对应的sprint velocity总值。
主要的作用是统计历史sprint velocity，用以对将来的sprint plan提供velocity上的指导和参考。
以及在velocity趋势波动的时候，结合数据和实际情况进行分析 —— 波动产生的原因，用以调整团队在将来sprint中的工作。
注意：velocity本身基于的估算，本身并不能作为一个sprint工作量的承诺。

Commitment（柱）: 代表sprint start的时候，sprint plan的所有issues估算值的总值。
Completed（柱）：代表sprint complete的时候，实际完成的issues估算值的总值。
当单次Commitment比Completed高时，代表未完成计划的issues scope。
当单次Completed比Commitment高时，代表sprint中issues scope发生了变化。
ps：当然如果你的团队总是无法在sprint开启的时候，确定好issues scope，那Commitment柱基本上是帮不了你了。

velocity chart是board-specific–的，意思是说 —— 如果有两个board使用同一个sprint，当前board的velocity chart只会计算当前board scope（根据board configure Filter）。

2. Burndown Chart

Burndown Chart

该报表不需要等到sprint complete之后才能看。
其根据时间轴，每当sprint内有issue估算值变化的时候，就会显示对应变化。
Burndown Chart主要的作用是在sprint过程中实时跟踪sprint的进度，当issues scope change造成burnup，当issue completed后burndown,
以及观察团队的当前sprint剩余工作量、离最终的整体burndown的目标还有多远，是否要采取一些其他的行动改进以达到最终burndown目标等等。

Burndown Chart也是board-specific–的，基于当前board filter：
Scope change - Issue added to sprint（具体原因）: 一个issue加入了此active sprint。具体原因有多种，比如“Estimate of 1 has been added"添加估算，“Estimate changed from 3 to 2”修改估算，等等其他。
Burndown - Issue completed: 一个issue被完成。“完成”的定义是基于board column的，当issue被挪到active board最右的column，即认为complete。

3. Release Burndown / EPIC Burndown

Release Burndown

Release Burndown / EPIC Burndown 是从Release version和EPIC的维度，来看涉及到的sprint issues的burndown总量。
比如上图：
首先在左上角下拉框选择要查看的release version，报表进行显示。
图中，该release计划交付的issues估算值总数102。绿色代表sprint 完成的量，深蓝色代表scope change, 浅蓝代表剩余的工作。
假设原计划是5个sprint后完成所有issues，那么该图表明进度已经delay，剩余issues估算值28，已经在占用后续release的sprint 6的时间，并且在sprint 6中减少了5个估算值的scope。

与Scrum sprint无关的报表

1. Control Chart

Control Chart

主要作用是来查看项目的cycle time（or lead time）。
cycle time代表issues在具体的column对应的状态上耗费的时间。
lead time代表整个团队对issues —— 从对应的需求提出到实现完成耗费的时间。

先从图上按顺序来看一下：
①指向的绿色空心点，代表一个issue。如果是一个大的绿实心点，代表一堆很接近的issues。
②指向的是，可自定义的报表x横轴时间区间。
③表示，在报表上使用鼠标悬浮滑动，可以查看固定时间点的值信息。
④ 指向的是，Refine report，此报表最重要的一块 —— 针对issues scope的选择。
报表最上面是统计信息cycle time、issues count。

Refine report
Columns / Swimlanes / Quick Filter三个过滤条件是 "与&" 的关系。
Columns：基于board columns，提供多选。勾选上的columns，报表会计算出issues处于被勾选的columns的总cycle time，并进行显示。
而报表图上的issue绿点的横向坐标，代表该issue“终止”该组columns的时间点。纵坐标代表该issue的cycle time。

Swimlanes: 基于board configure Swimlanes设置的JQL filter进行issues scope过滤。
Quick filter: 基于board configure Quick Filters设置的JQL filter进行issues scope过滤。
Swimlanes一般是基于board计算的，变动不会太大和频繁。因此，可以通过随时定制Quick filter，来进行Control chart报表分析时的过滤。
比如添加一个Quick filter —— 为了过滤出某一个sprint或者release的issues；还比如官方推荐了一个去除没有参考价值的异常issue的方法，就是通过在具体的异常issue label上进行标记，然后定制Quick filter进行过滤的方式，在Control Chart统计时排除异常issues。

Include non-working days in calculations
报表右下角有一个viewing option，Include non-working days in calculations不勾选时，cycle time的计算不会包含非工作日。
至于Control Chart上统计数据cycle time，包括average\median\min\max的时间显示，单位w/d/h中，1w = 7 working days，仅是一种简单的单位换算，不要产生误区。

查看lead time
如果项目设定issue从ready for dev 到 In dev 到 Dev Done 到 In QA 到 QA Done，是一个需求从提出到完成实现的整个流程的话，将columns勾选上ready for dev \ In dev \ Dev Done \ In QA 4个状态，则可以统计和绘制出lead time和相关issues。
如果想分析 —— 到开发们完成卡的这段cycle time，可以仅勾选ready for dev \ In dev 2个状态，即可查看。注意，不要将最后的缓冲队列Dev Done 误勾选进去。

rolling cycle time
rolling cycle time是根据当前issue + 前面x个issue + 后面x个issue的平均cycle time。x 是基于时间轴上的issue总数的一个取值。
目的是为了展示cycle time的一个具体范围趋势 —— average cycle time就是一条水平线。
报表上的蓝色阴影区，代表issue cycle time和rolling cycle time的标准偏差值，蓝色区域越窄，代表issue cycle time更接近周边的issues cycle time，这段rolling cycle time置信值越高；越宽的区域，issue异常情况越多，rolling cycle time置信值越低。rolling cycle time置信值越低，代表该时间段附近issue异常越多。

另类使用小tips：columns单选之后，比如In Dev，计算出来的Average cycle * issues count，可以看到在此column内对应issues的时间投入程度（前提，团队有按真实情况及时挪卡）。

2. Cumulative Flow Diagram

Cumulative Flow Diagram

Cumulative Flow Diagram其实非常简单，横轴是时间轴，纵轴是issue数量。
不同的色带，代表不同的column，色带上边界值代表该时间点进入过（处于该column + 已经transfer到后续column）的issue总数值，色带的纵向宽度即是“处于该column”的issue总数。
Cumulative Flow Diagram主要用来分析issues流量趋势是否正常、团队是否存在瓶颈。

比如：
在某一个时间段内，Dev done色带在纵向上逐渐变宽，代表等待QA测试的issues堆积越来越多，QA存在瓶颈；
在某一个时间点，In Dev色带上边界值有下降趋势，代表有部分issues从In dev状态被重置回上游column，代表issue内容可能被返工；
在某一个时间点，In Dev色带在纵向上的宽度比正常时窄，说明在制品在减少，如果开发人员并没有减少时，代表部分开发人员在空转；
在一个sprint时间段内，Preparing高度仍然在上升，说明sprint scope在增加；
所有in progress的columns色带，在横向宽度上变宽，说明lead time在逐渐变长。

Refine report
与Control Chart相同，对issues scope进行过滤。参照Control Chart Refine report。