起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識[干貨]如何將你的敏捷項目可視化？
敏捷事關“整體團隊”經驗。我們在一起做計劃、在一起編碼、在一起測試、在一起檢視過去，以便團隊中的每一個人都能達成一致的共識。然而，隨著項目增大，團隊開始迷失在大堆的用戶故事里，很難讓每個人都能看到相同的全景圖（big picture）。本文討論了可視化全景圖的各種方法。不僅可用于負責人和管理者，更可以用于每一個人。
在理想的情況下，敏捷團隊應該針對當前迭代提出清晰的計劃，而后續的發布計劃可以較為粗略。而事實上很多情況是，團隊在當前迭代只是急于實現下一步的小創意。他們完全忽略了全景圖。通常會有這樣一種情況：這張圖保存在一個角色的腦中，比如團隊領導、業務分析師、項目經理、產品經理、甚至是ScrumMaster。這往往是由于他或她沒有真正地推動自組織所導致的。這一現象在某些情況下還是可以接受的，比如一個不重要的短期項目，但在許多情況下，這會造成惡劣的后果，當團隊偏離軌道時他們也什么也察覺不到，因為他們覺得所有的工作都還在正常地運轉。
商業價值
在很多時候，我們在一些偉大想法（這可能來自于公司創辦人、部門主管、顧客群或社區）的基礎上去規劃一些事情。在我們的現實世界中，這些想法通常不是靜態的，它在不斷地發生著變化。如果能夠精確地看出項目進展全景圖（big picture），可以使我們具備更多的洞察力，幫助我們保持正確的運轉方向。
例如：你的大老板洞察力到通過LinkedIn登錄將是一個很有殺傷力的特性，它對于滲透到尚未開發的專業市場很有幫助，但是，一旦傳達到產品經理那里，在種種原因影響之下信息溝通產生了畸變，而且優先級未被正確理解。用以連接的API不是現成的。你的生產環境上還有5個其他的問題，以及許多其他正當的理由，導致你沒有把這項新功能安排上日程。到最后，距離發布日期還有不到一半的時間了，你們甚至還沒有開始這個集成功能的開發。最好讓你的老板和團隊能夠從一開始就知道這種差異，而不是拖到最后。
有時候，團隊迷戀在次要特性的技術問題上，投資過高而業務價值回報較低。假設，團隊為了努力解決與FourSquare的集成，在前3個迭代中已經花費了一多半的精力，了解到這一點的產品經理會決定說“算了吧”，然后繼續前進。
那么，我們如何使這些信息可見呢？
燃盡圖（Burndown Chart）
產品燃盡圖是敏捷團隊經典的進度可視化工具，它非常有效的描繪了團隊進展的速度和生產能力。它可以基于數百個故事的故事點和狀態精細地展示概要。它有自己獨特的美，但只有這些可能還不夠。假設你已經按時達成了目標，但卻發現這是一個錯誤的目標！燃盡圖可以判別完成的時間，但不能判別完成的內容。下面這張虛構的燃盡圖（來自Mike Cohn的《敏捷估算和規劃》）顯示，在迭代2末端追加了一些范圍，然后一切都回到了預計的軌道上。
我們如何可視化全景圖？這里有幾個技巧。
史詩故事(Epic)
史詩故事從根本上說只是大的用戶故事。憑借Mike Cohn和他《敏捷估算與規劃》一書，這個術語已經被廣泛采用。然而，史詩故事和類似的術語（如主題和特性）在不同的敏捷團隊有著不同的應用，但無論在哪一個團隊中，它們都是為用戶故事進行分組的技巧。在他自己博客的一個評論中，Mike Cohn提到，最初是Kent Beck向他解釋了史詩故事這個術語。這里有摘自該博客的一些定義：
1、我們將一個特定的故事稱為史詩故事時，并沒有什么特殊的界限。它的意思只是“大的用戶故事”。
2、“主題”是一系列用戶故事。我們可以把關于月度報表的故事分為一組，并拿條橡皮筋把它們束起來，然后稱之為“主題”。
這也意味著史詩故事與主題之間是無關的。下面的圖片可以幫你更好地去理解。
Mike作出一個有趣的總結，“把一個故事稱為史詩故事有時能傳達額外的含義”。比如說這個故事估計會很大，我們需要將它分解為一些較小的故事。
精益人還介紹了其他術語，如MMF（最小市場特征或最小市場特征集Minimal Marketable Feature or Minimal Marketable Feature set）這是另外一種定義需求的方式。MMF通常比故事更大，于是許多人已經將它視為史詩故事了，但是它比剛才的大故事有更多具體的定義。如果你發布的東西有客戶來買，功能再少了客戶就不買了，這樣的最少特性集就是MMF。如果它沒有市場，可能是它太小了，而且不能分解出更大的故事。一個或多個MMF與最小可用產品（MVP）一起發布。因為精益企業（Lean Startup）活動的出現，最近這個詞已經非常流行。
于是我們有了史詩故事、主題和MMF?，F在該怎么辦？我們如何使用它們，以幫助我們獲得更好的全景圖？
故事映射（Story Mapping）
故事映射模式因Jeff Patton而流行起來，它是大量待處理故事（backlog）的可視化方式。按照Mike Cohn對史詩故事這一術語的描述，故事映射只不過是一張史詩故事地圖，它們所有的子故事都在一面大墻上。主干（backbone）包含一個有序的史詩故事列表，當列出子故事時,你認為要講述哪些故事，就像骷髏人（walking skeleton）那樣在主干下排出優先級（編輯注：即，在只有骨架沒有肉的狀態下開始行走）。下圖出自《新用戶故事待辦工作是一張地圖（The new user story backlog is a map）》一書，由Jeff Patton寫于2008年。
如下，杰夫描述了故事映射的用法。
當這個項目正在運行時，它成為我們沖刺或迭代計劃的公示板。我們直接在示意圖上識別或劃分出要在下一次迭代中去構建的故事。在迭代期間我們將不只放置故事，我們采用任務墻去管理它們的開發——但這個故事示意圖放在規劃墻上提醒我們什么是全景圖，我們已經取得了多少進展。
故事映射的確是一個把大量待辦工作組織起來的好方法。相比平白直敘地描述待辦工作，它可以更好地去講述一個故事。在同一骨干項目（如史詩故事）下把故事分組，幫助我們可以在更高的級別上溝通，效果優于在詳細故事上的溝通。它也非常有助于挑選最小可用產品部件，你或許需要從各個骷髏人的一個（頂層）點堆積組成一個最小可用產品。
然而，有時候你只需要一張單獨的圖片來描繪項目概要。你已經給老板展示了燃盡圖，但它表達的是“什么時候”而不是“什么”。你很希望老板在大故事映射墻上花些時間，但事實很難如愿。我們該怎么做？是否還有其他選擇？
停車場圖（Parking Lot Diagram）
由Mike Griffiths寫于2009年的《重新討論停車場圖——使用區域去展示成就（Parking
Lot Diagrams Revisited – Using Area to Show Effort）》書中，提到了一個有趣的全景圖可視化技術——“相對尺寸”停車場圖。
紅綠燈顏色代表了緊迫感，如紅色意味著它已經錯過了進度，而綠色意味著它可以滿足最后期限的要求。因為大多數項目仍然在向最后期限進發的進程中，所以它們一直用黃色來表示。相對尺寸是原始尺寸停車場圖的改進版。較大的矩形表示它有較大的估值（在故事點中）。作者指出，該圖很容易理解，但在PowerPoint中很難用手工來繪制。博客還提到了一些其他想法，包括一個簡單的按比例縮放的柱狀圖，它比較容易用Excel繪制或編碼實現。
樹圖（TreeMap）
另一種可視化方式是通過樹圖（也稱作熱力型地圖（Heatmap））可視化大型產品的待辦工作。這個方式由Mike Cohn寫于2008年，我覺得用它來記錄大型和復雜的數據集很有意義。盡管寫于幾年前，Mike邁克在最近的評論中仍堅持認為，它一直是展現大型項目的最佳方法。
“是的，我仍然認為這是可視化大型產品待辦工作的最佳方法。樹圖已經經受住了時間的考驗，比如圖形化股票市場，所以在最近這段時間，對我們來說它依然是一門好的技術，我不希望它們被替代 [Mike Cohn，2012年5月11日]?！?/p>
下面這張樹圖源自Eidos beta版最近的待辦工作，是通過Google Chart Tools API繪制的，我所在的公司正致力于這個敏捷項目協同工具。深綠色的塊表示下一步的史詩故事已取得一定進展，它們的面積與史詩故事的規模（所有故事的故事點總和）成比例。此樹圖告訴我們，因為已經完成了許多大型史詩故事，Eidos的beta版本差不多準備就緒了。
這些圖片提供給我們不錯的今日快照，但它不能告訴我們關于過去和未來的任何信息，因為這里只有兩個維度的數據，比如在本例中，只有史詩故事的規模和狀態，但沒有時間維度。
鏢靶圖（Dartboard）
下面的鏢靶圖，由Nicholas Muldoon在《針對產品的史詩故事（Epic）可視化》中提出，每個史詩故事圖形化的“計劃”由每塊區域來表示。每個方塊符號是一個故事。最內部的圓圈是當前版本，在它外圍的4個圓圈是接下來的4個版本。圓圈外面的符號是計劃外的故事。紅綠燈顏色代表故事已完成的程度，從紅色、黃色到最終的綠色。
盡管該圖顯示了時間維度，但它并不能真實地顯示出故事之間所需的相對努力。也許，以每個符號的大小去反映它相對的規模，可以很容易地將它進一步增強。
面積堆疊圖（Stacked Area Chart）
在Eidos中，我們正在研究如何去有效地可視化全景圖。還有一個方法是面積堆疊圖。本圖不僅顯示相對規模和狀態，并且顯示進度已經歷的時間。例如，針對故事板（Storyboard）和故事卡（StoryCard）上的史詩故事，你可以看到我們從開始到現在所有的工作進展，以及我們剛剛在迭代6中提交的迭代計劃和附件。
帶有史詩故事條的增強型燃盡圖
還有一個方法是在燃盡圖下顯示史詩故事進度，原始Eidos截圖如下。在燃盡圖下的條形圖中，每個色塊代表每個史詩故事的故事點總數。在其他圖中，增強的燃盡圖還能顯示每個史詩故事“還剩哪些”沒有實現。
總結
所有這些可視化方法都在努力解決同樣的問題，比如在時間、規模和需求組等不同維度概括大型、復雜的數據集。更為復雜的數據與可視化，你就需要去更加自動化地表達全景圖。
讓我們再來回顧一下所有已討論過的可視化。關鍵的不同在于維度和打算要可視化顯示的內容。很明顯，如果采用了僅顯示某時間點的截圖（如樹圖），就無法顯示各時間段上的數據（如燃盡圖）。
可視化 時間 范圍與狀態分類 贊成意見 反對意見 可編程繪制 (發布) 燃盡圖（Burndown） 時間序列 發布層 直觀，易于手繪 沒有衰變數據 困難 故事映射（Story Mapping） 截圖 故事層 直觀，易于手繪 待辦工作太多時難以維護 非常困難（主要通過往墻上貼便箋來完成） 停車場圖（Parking Lot） 截圖 史詩故事級（Epic Level） 直觀 創作較費時 非常困難 刻度條圖（Scaled Bar Chart） 截圖 史詩故事級（Epic Level） 直觀 創作較費時 容易 樹圖（Treemap） 截圖 史詩故事級（Epic Level） 更全面地顯示全部范圍和狀態 不直觀 中等 鏢靶圖 （Dartboard） 截圖 史詩故事級（Epic Level） 占用空間小 不適用于太多的待辦工作 困難 面積堆疊圖（Stacked Area Chart） 時間序列 史詩故事級（Epic Level） 同時記錄時間序列與衰變 不直觀并有些雜亂 中等 燃盡圖+史詩故事條 （Burndown + Epic Bar） 時間序列 史詩故事級（Epic Level） 直觀 有點雜亂 困難
您怎么看待這些可視化？您的項目全景圖是如何可視化的？我們很樂意聽到您的想法。
- 目前還沒評論，等你發揮！
