首先，貼一下官方報(bào)表的說明文檔的鏈接：跳轉(zhuǎn)
最近讀了一本書，書中有一句話，大致意思是：文章太長時，大部分人其實(shí)都不會讀完它。
覺得很有道理，但是這篇JIRA還是沒辦法的寫了很長。
希望這是本人最后一篇JIRA的博文。耶。
與Scrum sprint相關(guān)的報(bào)表
1. Velocity Chart
該報(bào)表會在對應(yīng)sprint complete之后生成出對應(yīng)的sprint velocity總值。
主要的作用是統(tǒng)計(jì)歷史sprint velocity，用以對將來的sprint plan提供velocity上的指導(dǎo)和參考。
以及在velocity趨勢波動的時候，結(jié)合數(shù)據(jù)和實(shí)際情況進(jìn)行分析 —— 波動產(chǎn)生的原因，用以調(diào)整團(tuán)隊(duì)在將來sprint中的工作。
注意：velocity本身基于的估算，本身并不能作為一個sprint工作量的承諾。
Commitment（柱）: 代表sprint start的時候，sprint plan的所有issues估算值的總值。
Completed（柱）：代表sprint complete的時候，實(shí)際完成的issues估算值的總值。
當(dāng)單次Commitment比Completed高時，代表未完成計(jì)劃的issues scope。
當(dāng)單次Completed比Commitment高時，代表sprint中issues scope發(fā)生了變化。
ps：當(dāng)然如果你的團(tuán)隊(duì)總是無法在sprint開啟的時候，確定好issues scope，那Commitment柱基本上是幫不了你了。
velocity chart是board-specific–的，意思是說 —— 如果有兩個board使用同一個sprint，當(dāng)前board的velocity chart只會計(jì)算當(dāng)前board scope（根據(jù)board configure Filter）。
2. Burndown Chart
該報(bào)表不需要等到sprint complete之后才能看。
其根據(jù)時間軸，每當(dāng)sprint內(nèi)有issue估算值變化的時候，就會顯示對應(yīng)變化。
Burndown Chart主要的作用是在sprint過程中實(shí)時跟蹤sprint的進(jìn)度，當(dāng)issues scope change造成
burnup，當(dāng)issue completed后burndown,以及觀察團(tuán)隊(duì)的當(dāng)前sprint剩余工作量、離最終的整體burndown的目標(biāo)還有多遠(yuǎn)，是否要采取一些其他的行動改進(jìn)以達(dá)到最終burndown目標(biāo)等等。
Burndown Chart也是board-specific–的，基于當(dāng)前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被完成?！巴瓿伞钡亩x是基于board column的，當(dāng)issue被挪到active board最右的column，即認(rèn)為complete。
3. Release Burndown / EPIC Burndown
Release Burndown / EPIC Burndown 是從Release version和EPIC的維度，來看涉及到的sprint issues的burndown總量。比如上圖：
首先在左上角下拉框選擇要查看的release version，報(bào)表進(jìn)行顯示。
圖中，該release計(jì)劃交付的issues估算值總數(shù)102。綠色代表sprint 完成的量，深藍(lán)色代表scope change, 淺藍(lán)代表剩余的工作。
假設(shè)原計(jì)劃是5個sprint后完成所有issues，那么該圖表明進(jìn)度已經(jīng)delay，剩余issues估算值28，已經(jīng)在占用后續(xù)release的sprint 6的時間，并且在sprint 6中減少了5個估算值的scope。
與Scrum sprint無關(guān)的報(bào)表
1. Control Chart
主要作用是來查看項(xiàng)目的cycle time（or lead time）。
cycle time代表issues在具體的column對應(yīng)的狀態(tài)上耗費(fèi)的時間。
lead time代表整個團(tuán)隊(duì)對issues —— 從對應(yīng)的需求提出到實(shí)現(xiàn)完成耗費(fèi)的時間。
先從圖上按順序來看一下：
①指向的綠色空心點(diǎn)，代表一個issue。如果是一個大的綠實(shí)心點(diǎn)，代表一堆很接近的issues。
②指向的是，可自定義的報(bào)表x橫軸時間區(qū)間。
③表示，在報(bào)表上使用鼠標(biāo)懸浮滑動，可以查看固定時間點(diǎn)的值信息。
④ 指向的是，Refine report，此報(bào)表最重要的一塊 —— 針對issues scope的選擇。
報(bào)表最上面是統(tǒng)計(jì)信息cycle time、issues count。
Refine report
Columns / Swimlanes / Quick Filter三個過濾條件是 "與&" 的關(guān)系。
Columns：基于board columns，提供多選。勾選上的columns，報(bào)表會計(jì)算出issues處于被勾選的columns的總cycle time，并進(jìn)行顯示。
而報(bào)表圖上的issue綠點(diǎn)的橫向坐標(biāo)，代表該issue“終止”該組columns的時間點(diǎn)?？v坐標(biāo)代表該issue的cycle time。
Swimlanes: 基于board configure Swimlanes設(shè)置的JQL filter進(jìn)行issues scope過濾。
Quick filter: 基于board configure Quick Filters設(shè)置的JQL filter進(jìn)行issues scope過濾。
Swimlanes一般是基于board計(jì)算的，變動不會太大和頻繁。因此，可以通過隨時定制Quick filter，來進(jìn)行Control chart報(bào)表分析時的過濾。
比如添加一個Quick filter —— 為了過濾出某一個sprint或者release的issues；還比如官方推薦了一個去除沒有參考價(jià)值的異常issue的方法，就是通過在具體的異常issue label上進(jìn)行標(biāo)記，然后定制Quick filter進(jìn)行過濾的方式，在Control Chart統(tǒng)計(jì)時排除異常issues。
Include non-working days in calculations
報(bào)表右下角有一個viewing option，Include non-working days in calculations不勾選時，cycle time的計(jì)算不會包含非工作日。
至于Control Chart上統(tǒng)計(jì)數(shù)據(jù)cycle time，包括average\median\min\max的時間顯示，單位w/d/h中，1w = 7 working days，僅是一種簡單的單位換算，不要產(chǎn)生誤區(qū)。
查看lead time
如果項(xiàng)目設(shè)定issue從ready for dev 到 In dev 到 Dev Done 到 In QA 到 QA Done，是一個需求從提出到完成實(shí)現(xiàn)的整個流程的話，將columns勾選上ready for dev \ In dev \ Dev Done \ In QA 4個狀態(tài)，則可以統(tǒng)計(jì)和繪制出lead time和相關(guān)issues。
如果想分析 —— 到開發(fā)們完成卡的這段cycle time，可以僅勾選ready for dev \ In dev 2個狀態(tài)，即可查看。注意，不要將最后的緩沖隊(duì)列Dev Done 誤勾選進(jìn)去。
rolling cycle time
rolling cycle time是根據(jù)當(dāng)前issue + 前面x個issue + 后面x個issue的平均cycle time。x 是基于時間軸上的issue總數(shù)的一個取值。
目的是為了展示cycle time的一個具體范圍趨勢 —— average cycle time就是一條水平線。
報(bào)表上的藍(lán)色陰影區(qū)，代表issue cycle time和rolling cycle time的標(biāo)準(zhǔn)偏差值，藍(lán)色區(qū)域越窄，代表issue cycle time更接近周邊的issues cycle time，這段rolling cycle time置信值越高；越寬的區(qū)域，issue異常情況越多，rolling cycle time置信值越低。rolling cycle time置信值越低，代表該時間段附近issue異常越多。
另類使用小tips：columns單選之后，比如In Dev，計(jì)算出來的Average cycle * issues count，可以看到在此column內(nèi)對應(yīng)issues的時間投入程度（前提，團(tuán)隊(duì)有按真實(shí)情況及時挪卡）。
2. Cumulative Flow Diagram
Cumulative Flow Diagram其實(shí)非常簡單，橫軸是時間軸，縱軸是issue數(shù)量。
不同的色帶，代表不同的column，色帶上邊界值代表該時間點(diǎn)
進(jìn)入過（處于該column + 已經(jīng)transfer到后續(xù)column）的issue總數(shù)值，色帶的縱向?qū)挾燃词恰疤幱谠揷olumn”的issue總數(shù)。Cumulative Flow Diagram主要用來分析issues流量趨勢是否正常、團(tuán)隊(duì)是否存在瓶頸。
比如：
在某一個時間段內(nèi)，Dev done色帶在縱向上逐漸變寬，代表等待QA測試的issues堆積越來越多，QA存在瓶頸；
在某一個時間點(diǎn)，In Dev色帶上邊界值有下降趨勢，代表有部分issues從In dev狀態(tài)被重置回上游column，代表issue內(nèi)容可能被返工；
在某一個時間點(diǎn)，In Dev色帶在縱向上的寬度比正常時窄，說明在制品在減少，如果開發(fā)人員并沒有減少時，代表部分開發(fā)人員在空轉(zhuǎn)；
在一個sprint時間段內(nèi)，Preparing高度仍然在上升，說明sprint scope在增加；
所有in progress的columns色帶，在橫向?qū)挾壬献儗?，說明lead time在逐漸變長。
Refine report
與Control Chart相同，對issues scope進(jìn)行過濾。參照Control Chart Refine report。
