主要記錄下在敏捷項目管理中，我們參考的圖表可能會有哪些，哪些圖表是我們可以關注的；
大家都知道，在敏捷項目中，主要有三部分：Epic, User story,? Task；
Epic（史詩）： 一個整體功能，可以跨越多個版本；
User story（用戶故事）：用戶特性，用戶提出的需求，或站在用戶角度上，想要實現(xiàn)的功能點（三要素：用戶、功能、價值）；
Task（任務）：可以包含在特定用戶故事下拆分的任務（用戶故事->實施），也可以是為了實現(xiàn)某些功能（非用戶提出，重構(gòu)等），而建立的任務；
具體如何拆分Epic（到特性）到用戶故事，用戶故事如何拆分到任務，我們就先不說了；
今天主要想看看有哪些圖表在我們敏捷項目管理當中會用到的：
主要從項目、迭代、需求和缺陷四個角度來梳理；
項目：
? ? 團隊速度圖：通過對過去數(shù)個沖刺的用戶故事數(shù)量評估，預測后續(xù)沖刺所能完成用戶故事數(shù)；
? ? 不足：如果單純只是考慮用戶故事數(shù)量，會忽略用戶故事難易程度；
? ? 個人觀點：單純對團隊速度進行評估的話，可以考慮在估算用戶故事時，引入故事點估算；故事點估算已經(jīng)包含了對用戶故事難易度的評估，需要注意的是在項目中基準是不變的，也是大家認可的，4個故事點的用戶故事工作量是1個故事點的用戶故事的4倍。也就是說，以后可以說我們團隊的單一迭代的速度是20個故事點，未來先估算用戶故事故事點數(shù)，然后根據(jù)預測以往經(jīng)驗，納入相應用戶故事至版本當中。
迭代：
? ? 燃盡圖：跟蹤沖刺剩余工作量，根據(jù)與預期的偏離程度，及時識別風險；
? ? 不足：1.無法呈現(xiàn)所有信息（優(yōu)先級等），依賴成員的精準的評估，壓迫感;2. 出現(xiàn)延誤，無法區(qū)分范圍蔓延還是團隊出現(xiàn)延誤的問題，不直觀；
? ? 個人觀點：可以采用燃起圖覺得第二類問題，范圍與進展獨立開；
? ? 燃起圖：能夠直觀的展示項目時間與完成工作的關系，可以區(qū)分不同角色展現(xiàn)工作量的完成情況，更容易跟蹤和理解；
? ? 個人觀點：燃起圖做為完成工作的統(tǒng)計，能夠非常清晰的統(tǒng)計團隊的速率，發(fā)現(xiàn)團隊的問題。當然明確清晰的看板也可以達到燃起圖類似的效果，燃起圖是個統(tǒng)計圖表；
????成員負荷圖：成員現(xiàn)有所承載的用戶故事數(shù)（已完成&未完成），可以看出當前時間點，項目成員的負荷；
? ? 個人觀點：員工出現(xiàn)并行任務情況下，需要多多關注其他任務的依賴風險，提前預知；凡事只統(tǒng)計用戶故事，不統(tǒng)計故事點的，都會存在忽略難易度的問題，所以不妨在成員負荷圖中加入故事點的維度展示；
需求：
? ? 需求屬性分布：根據(jù)優(yōu)先級進行需求屬性（優(yōu)先級、來源、分類）分布的統(tǒng)計；
? ? 個人觀點：需求緯度的基本統(tǒng)計，全面了解現(xiàn)階段需求的情況，從來源（客戶、產(chǎn)品、自研等）和分類角度上，進行數(shù)據(jù)分析，為后續(xù)能夠更好的掌握需求提供數(shù)據(jù)支撐。
? ? 需求狀態(tài)分布：對當前時間點，需求狀態(tài)分布的統(tǒng)計；
? ? 個人觀點：單純的狀態(tài)分布大致能看出當前（項目整體/迭代）需求的處理狀態(tài)，也能看出未來需要處理的需求量，與團隊速率進行配合，可以大致預估未來的版本數(shù)量。
? ? 需求每日趨勢：跟蹤一段時間內(nèi)，新增需求&修改需求的統(tǒng)計；
? ? 個人觀點：可以在項目回顧會上，把范圍定在一段時間內(nèi)，查看新增需求&修改需求的數(shù)量和頻率，分析問題并加以解決，達到漸進明細的效果。
? ? 需求累積流圖：跟蹤一段時間內(nèi)，各種狀態(tài)下的需求累積情況，監(jiān)控需求的變化趨勢；
? ? 個人觀點：包含了每日趨勢的需求，同時考慮到需求的狀態(tài)，能夠宏觀的看出需求pending、正在解決和被解決數(shù)量，找到項目瓶頸；同樣能夠預測需求完成時間，及時做好項目規(guī)劃；
? ? 需求年齡報告：統(tǒng)計所有需求按照年齡的分布情況，跟蹤需求的生命周期和響應情況；
? ? 個人觀點：通過提供需求年齡報告，能夠讓客戶&管理者更清晰的了解需求被關注&實現(xiàn)的速率；可以分優(yōu)先級等緯度統(tǒng)計需求的生命周期，預估我們相關優(yōu)先級的需求的響應情況。
缺陷：
? ? 缺陷屬性分布：根據(jù)優(yōu)先級進行需求屬性（優(yōu)先級、嚴重程度、復現(xiàn)概率、類別、原因分析、解決方案）分布的統(tǒng)計；? ?
? ? 個人觀點：沖刺過程中，應該每日關注缺陷，尤其是優(yōu)先級高、嚴重程度高、經(jīng)常復現(xiàn)的Bug，并且給予充分的重視，無需等到回顧會議才去回顧，盡早處理和解決；
? ? 缺陷狀態(tài)分布：對當前時間點，缺陷狀態(tài)分布的統(tǒng)計；
? ? 個人觀點：相對于屬性分布，與每日趨勢圖配合，結(jié)合迭代進程來判斷可能出現(xiàn)的風險，在迭代初期暴露風險何嘗不是個好消息？
? ? 缺陷每日趨勢：跟蹤一段時間內(nèi)，新增缺陷的統(tǒng)計；
? ? 個人觀點：同上；
? ? 缺陷累積流圖：跟蹤一段時間內(nèi)，各種程度和類別的缺陷累積情況，監(jiān)控缺陷的變化趨勢；
? ? 個人觀點：與需求累積流圖類似，能夠比每日趨勢圖更多的發(fā)現(xiàn)沖刺的瓶頸與風險，并為解決時間做預測；
? ? 缺陷年齡報告：統(tǒng)計所有缺陷按照年齡的分布情況，跟蹤缺陷的生命周期和響應情況；
? ? 個人觀點：關注缺陷的嚴重程度、處理人和處理人當前的負荷情況，綜合考量和計劃如何實施缺陷修復；也可以做為回顧會議上的議題來討論，為什么會出現(xiàn)缺陷長期被阻礙的情況，是工作量巨大還是單元測試工作做的不夠。
? ? 缺陷回歸分布：統(tǒng)計項目中缺陷在回歸測試中分布情況，跟蹤缺陷的重新打開率；
? ? 個人觀點：與自動化測試關系很大，沒有做好代碼管理&自動化測試&持續(xù)集成，這種問題應該今早修復，否則會嚴重影響后續(xù)的交付能力。
大家可以在項目管理中多多嘗試，并沒有好壞之分，而是真正輔助到我們項目，有益于項目的進展，那才是好的圖表。
