敏捷事關(guān)“整體團(tuán)隊(duì)”經(jīng)驗(yàn)。我們?cè)谝黄鹱鲇?jì)劃、在一起編碼、在一起測(cè)試、在一起檢視過(guò)去,以便團(tuán)隊(duì)中的每一個(gè)人都能達(dá)成一致的共識(shí)。然而,隨著項(xiàng)目增大,團(tuán)隊(duì)開(kāi)始迷失在大堆的用戶故事里,很難讓每個(gè)人都能看到相同的全景圖(big picture)。本文討論了可視化全景圖的各種方法。不僅可用于負(fù)責(zé)人和管理者,更可以用于每一個(gè)人。 在理想的情況下,敏捷團(tuán)隊(duì)?wèi)?yīng)該針對(duì)當(dāng)前迭代提出清晰的計(jì)劃,而后續(xù)的發(fā)布計(jì)劃可以較為粗略。而事實(shí)上很多情況是,團(tuán)隊(duì)在當(dāng)前迭代只是急于實(shí)現(xiàn)下一步的小創(chuàng)意。他們完全忽略了全景圖。通常會(huì)有這樣一種情況:這張圖保存在一個(gè)角色的腦中,比如團(tuán)隊(duì)領(lǐng)導(dǎo)、業(yè)務(wù)分析師、項(xiàng)目經(jīng)理、產(chǎn)品經(jīng)理、甚至是ScrumMaster。這往往是由于他或她沒(méi)有真正地推動(dòng)自組織所導(dǎo)致的。這一現(xiàn)象在某些情況下還是可以接受的,比如一個(gè)不重要的短期項(xiàng)目,但在許多情況下,這會(huì)造成惡劣的后果,當(dāng)團(tuán)隊(duì)偏離軌道時(shí)他們也什么也察覺(jué)不到,因?yàn)樗麄冇X(jué)得所有的工作都還在正常地運(yùn)轉(zhuǎn)。 商業(yè)價(jià)值在很多時(shí)候,我們?cè)谝恍﹤ゴ笙敕ǎㄟ@可能來(lái)自于公司創(chuàng)辦人、部門(mén)主管、顧客群或社區(qū))的基礎(chǔ)上去規(guī)劃一些事情。在我們的現(xiàn)實(shí)世界中,這些想法通常不是靜態(tài)的,它在不斷地發(fā)生著變化。如果能夠精確地看出項(xiàng)目進(jìn)展全景圖(big picture),可以使我們具備更多的洞察力,幫助我們保持正確的運(yùn)轉(zhuǎn)方向。 相關(guān)廠商內(nèi)容 例如:你的大老板洞察力到通過(guò)LinkedIn登錄將是一個(gè)很有殺傷力的特性,它對(duì)于滲透到尚未開(kāi)發(fā)的專業(yè)市場(chǎng)很有幫助,但是,一旦傳達(dá)到產(chǎn)品經(jīng)理那里,在種種原因影響之下信息溝通產(chǎn)生了畸變,而且優(yōu)先級(jí)未被正確理解。用以連接的API不是現(xiàn)成的。你的生產(chǎn)環(huán)境上還有5個(gè)其他的問(wèn)題,以及許多其他正當(dāng)?shù)睦碛桑瑢?dǎo)致你沒(méi)有把這項(xiàng)新功能安排上日程。到最后,距離發(fā)布日期還有不到一半的時(shí)間了,你們甚至還沒(méi)有開(kāi)始這個(gè)集成功能的開(kāi)發(fā)。最好讓你的老板和團(tuán)隊(duì)能夠從一開(kāi)始就知道這種差異,而不是拖到最后。 有時(shí)候,團(tuán)隊(duì)迷戀在次要特性的技術(shù)問(wèn)題上,投資過(guò)高而業(yè)務(wù)價(jià)值回報(bào)較低。假設(shè),團(tuán)隊(duì)為了努力解決與FourSquare的集成,在前3個(gè)迭代中已經(jīng)花費(fèi)了一多半的精力,了解到這一點(diǎn)的產(chǎn)品經(jīng)理會(huì)決定說(shuō)“算了吧”,然后繼續(xù)前進(jìn)。 那么,我們?nèi)绾问惯@些信息可見(jiàn)呢? 燃盡圖(Burndown Chart)產(chǎn)品燃盡圖是敏捷團(tuán)隊(duì)經(jīng)典的進(jìn)度可視化工具,它非常有效的描繪了團(tuán)隊(duì)進(jìn)展的速度和生產(chǎn)能力。它可以基于數(shù)百個(gè)故事的故事點(diǎn)和狀態(tài)精細(xì)地展示概要。它有自己獨(dú)特的美,但只有這些可能還不夠。假設(shè)你已經(jīng)按時(shí)達(dá)成了目標(biāo),但卻發(fā)現(xiàn)這是一個(gè)錯(cuò)誤的目標(biāo)!燃盡圖可以判別完成的時(shí)間,但不能判別完成的內(nèi)容。下面這張?zhí)摌?gòu)的燃盡圖(來(lái)自Mike Cohn的《敏捷估算和規(guī)劃》)顯示,在迭代2末端追加了一些范圍,然后一切都回到了預(yù)計(jì)的軌道上。 我們?nèi)绾慰梢暬皥D?這里有幾個(gè)技巧。 史詩(shī)故事(Epic)史詩(shī)故事從根本上說(shuō)只是大的用戶故事。憑借Mike Cohn和他《敏捷估算與規(guī)劃》一書(shū),這個(gè)術(shù)語(yǔ)已經(jīng)被廣泛采用。然而,史詩(shī)故事和類似的術(shù)語(yǔ)(如主題和特性)在不同的敏捷團(tuán)隊(duì)有著不同的應(yīng)用,但無(wú)論在哪一個(gè)團(tuán)隊(duì)中,它們都是為用戶故事進(jìn)行分組的技巧。在他自己博客的一個(gè)評(píng)論中,Mike Cohn提到,最初是Kent Beck向他解釋了史詩(shī)故事這個(gè)術(shù)語(yǔ)。這里有摘自該博客的一些定義:
這也意味著史詩(shī)故事與主題之間是無(wú)關(guān)的。下面的圖片可以幫你更好地去理解。 (點(diǎn)擊圖像放大) Mike作出一個(gè)有趣的總結(jié),“把一個(gè)故事稱為史詩(shī)故事有時(shí)能傳達(dá)額外的含義”。比如說(shuō)這個(gè)故事估計(jì)會(huì)很大,我們需要將它分解為一些較小的故事。 精益人還介紹了其他術(shù)語(yǔ),如MMF(最小市場(chǎng)特征或最小市場(chǎng)特征集Minimal Marketable Feature or Minimal Marketable Feature set)這是另外一種定義需求的方式。MMF通常比故事更大,于是許多人已經(jīng)將它視為史詩(shī)故事了,但是它比剛才的大故事有更多具體的定義。如果你發(fā)布的東西有客戶來(lái)買,功能再少了客戶就不買了,這樣的最少特性集就是MMF。如果它沒(méi)有市場(chǎng),可能是它太小了,而且不能分解出更大的故事。一個(gè)或多個(gè)MMF與最小可用產(chǎn)品(MVP)一起發(fā)布。因?yàn)榫嫫髽I(yè)(Lean Startup)活動(dòng)的出現(xiàn),最近這個(gè)詞已經(jīng)非常流行。 于是我們有了史詩(shī)故事、主題和MMF。現(xiàn)在該怎么辦?我們?nèi)绾问褂盟鼈儯詭椭覀儷@得更好的全景圖? 故事映射(Story Mapping)故事映射模式因Jeff Patton而流行起來(lái),它是大量待處理故事(backlog)的可視化方式。按照Mike Cohn對(duì)史詩(shī)故事這一術(shù)語(yǔ)的描述,故事映射只不過(guò)是一張史詩(shī)故事地圖,它們所有的子故事都在一面大墻上。主干(backbone)包含一個(gè)有序的史詩(shī)故事列表,當(dāng)列出子故事時(shí),你認(rèn)為要講述哪些故事,就像骷髏人(walking skeleton)那樣在主干下排出優(yōu)先級(jí)(編輯注:即,在只有骨架沒(méi)有肉的狀態(tài)下開(kāi)始行走)。下圖出自《新用戶故事待辦工作是一張地圖(The new user story backlog is a map)》一書(shū),由Jeff Patton寫(xiě)于2008年。 如下,杰夫描述了故事映射的用法。
故事映射的確是一個(gè)把大量待辦工作組織起來(lái)的好方法。相比平白直敘地描述待辦工作,它可以更好地去講述一個(gè)故事。在同一骨干項(xiàng)目(如史詩(shī)故事)下把故事分組,幫助我們可以在更高的級(jí)別上溝通,效果優(yōu)于在詳細(xì)故事上的溝通。它也非常有助于挑選最小可用產(chǎn)品部件,你或許需要從各個(gè)骷髏人的一個(gè)(頂層)點(diǎn)堆積組成一個(gè)最小可用產(chǎn)品。 然而,有時(shí)候你只需要一張單獨(dú)的圖片來(lái)描繪項(xiàng)目概要。你已經(jīng)給老板展示了燃盡圖,但它表達(dá)的是“什么時(shí)候”而不是“什么”。你很希望老板在大故事映射墻上花些時(shí)間,但事實(shí)很難如愿。我們?cè)撛趺醋觯渴欠襁€有其他選擇? 停車場(chǎng)圖(Parking Lot Diagram)由Mike Griffiths寫(xiě)于2009年的《重新討論停車場(chǎng)圖——使用區(qū)域去展示成就(Parking Lot Diagrams Revisited – Using Area to Show Effort)》書(shū)中,提到了一個(gè)有趣的全景圖可視化技術(shù)——“相對(duì)尺寸”停車場(chǎng)圖。 (點(diǎn)擊圖像放大) 紅綠燈顏色代表了緊迫感,如紅色意味著它已經(jīng)錯(cuò)過(guò)了進(jìn)度,而綠色意味著它可以滿足最后期限的要求。因?yàn)榇蠖鄶?shù)項(xiàng)目仍然在向最后期限進(jìn)發(fā)的進(jìn)程中,所以它們一直用黃色來(lái)表示。相對(duì)尺寸是原始尺寸停車場(chǎng)圖的改進(jìn)版。較大的矩形表示它有較大的估值(在故事點(diǎn)中)。作者指出,該圖很容易理解,但在PowerPoint中很難用手工來(lái)繪制。博客還提到了一些其他想法,包括一個(gè)簡(jiǎn)單的按比例縮放的柱狀圖,它比較容易用Excel繪制或編碼實(shí)現(xiàn)。 (點(diǎn)擊圖像放大) 樹(shù)圖(TreeMap) 另一種可視化方式是通過(guò)樹(shù)圖(也稱作熱力型地圖(Heatmap))可視化大型產(chǎn)品的待辦工作。這個(gè)方式由Mike Cohn寫(xiě)于2008年,我覺(jué)得用它來(lái)記錄大型和復(fù)雜的數(shù)據(jù)集很有意義。盡管寫(xiě)于幾年前,Mike邁克在最近的評(píng)論中仍堅(jiān)持認(rèn)為,它一直是展現(xiàn)大型項(xiàng)目的最佳方法。
下面這張樹(shù)圖源自Eidos beta版最近的待辦工作,是通過(guò)Google Chart Tools API繪制的,我所在的公司正致力于這個(gè)敏捷項(xiàng)目協(xié)同工具。深綠色的塊表示下一步的史詩(shī)故事已取得一定進(jìn)展,它們的面積與史詩(shī)故事的規(guī)模(所有故事的故事點(diǎn)總和)成比例。此樹(shù)圖告訴我們,因?yàn)橐呀?jīng)完成了許多大型史詩(shī)故事,Eidos的beta版本差不多準(zhǔn)備就緒了。 (點(diǎn)擊圖像放大) 這些圖片提供給我們不錯(cuò)的今日快照,但它不能告訴我們關(guān)于過(guò)去和未來(lái)的任何信息,因?yàn)檫@里只有兩個(gè)維度的數(shù)據(jù),比如在本例中,只有史詩(shī)故事的規(guī)模和狀態(tài),但沒(méi)有時(shí)間維度。 鏢靶圖(Dartboard)下面的鏢靶圖,由Nicholas Muldoon在《針對(duì)產(chǎn)品的史詩(shī)故事(Epic)可視化》中提出,每個(gè)史詩(shī)故事圖形化的“計(jì)劃”由每塊區(qū)域來(lái)表示。每個(gè)方塊符號(hào)是一個(gè)故事。最內(nèi)部的圓圈是當(dāng)前版本,在它外圍的4個(gè)圓圈是接下來(lái)的4個(gè)版本。圓圈外面的符號(hào)是計(jì)劃外的故事。紅綠燈顏色代表故事已完成的程度,從紅色、黃色到最終的綠色。 盡管該圖顯示了時(shí)間維度,但它并不能真實(shí)地顯示出故事之間所需的相對(duì)努力。也許,以每個(gè)符號(hào)的大小去反映它相對(duì)的規(guī)模,可以很容易地將它進(jìn)一步增強(qiáng)。 面積堆疊圖(Stacked Area Chart)在Eidos中,我們正在研究如何去有效地可視化全景圖。還有一個(gè)方法是面積堆疊圖。本圖不僅顯示相對(duì)規(guī)模和狀態(tài),并且顯示進(jìn)度已經(jīng)歷的時(shí)間。例如,針對(duì)故事板(Storyboard)和故事卡(StoryCard)上的史詩(shī)故事,你可以看到我們從開(kāi)始到現(xiàn)在所有的工作進(jìn)展,以及我們剛剛在迭代6中提交的迭代計(jì)劃和附件。 (點(diǎn)擊圖像放大) 帶有史詩(shī)故事條的增強(qiáng)型燃盡圖還有一個(gè)方法是在燃盡圖下顯示史詩(shī)故事進(jìn)度,原始Eidos截圖如下。在燃盡圖下的條形圖中,每個(gè)色塊代表每個(gè)史詩(shī)故事的故事點(diǎn)總數(shù)。在其他圖中,增強(qiáng)的燃盡圖還能顯示每個(gè)史詩(shī)故事“還剩哪些”沒(méi)有實(shí)現(xiàn)。 (點(diǎn)擊圖像放大) 總結(jié)所有這些可視化方法都在努力解決同樣的問(wèn)題,比如在時(shí)間、規(guī)模和需求組等不同維度概括大型、復(fù)雜的數(shù)據(jù)集。更為復(fù)雜的數(shù)據(jù)與可視化,你就需要去更加自動(dòng)化地表達(dá)全景圖。 讓我們?cè)賮?lái)回顧一下所有已討論過(guò)的可視化。關(guān)鍵的不同在于維度和打算要可視化顯示的內(nèi)容。很明顯,如果采用了僅顯示某時(shí)間點(diǎn)的截圖(如樹(shù)圖),就無(wú)法顯示各時(shí)間段上的數(shù)據(jù)(如燃盡圖)。
您怎么看待這些可視化?您的項(xiàng)目全景圖是如何可視化的?我們很樂(lè)意聽(tīng)到您的想法。 查看英文原文:Visualizing the Big Picture of your Agile Project 感謝楊賽對(duì)本文的審校。 給InfoQ中文站投稿或者參與內(nèi)容翻譯工作,請(qǐng)郵件至editors@cn.。也歡迎大家通過(guò)新浪微博(@InfoQ)或者騰訊微博(@InfoQ)關(guān)注我們,并與我們的編輯和其他讀者朋友交流。 作者簡(jiǎn)介Kulawat Wongsaroj是一個(gè)投入創(chuàng)業(yè)的敏捷教練,他致力于解決那些不人性的敏捷項(xiàng)目協(xié)作工具所帶來(lái)的問(wèn)題。在尋找最好的敏捷工具的過(guò)程中,他發(fā)現(xiàn)并沒(méi)有一個(gè)完美的工具,所以他在泰國(guó)創(chuàng)建了Proteus Agility公司,試圖構(gòu)建Eidos——一個(gè)為人類設(shè)計(jì)的人性化工具。Kulawat是敏捷宣言泰文版的首席譯者,也是泰國(guó)最大的敏捷社區(qū)Agile66.com的創(chuàng)始人。他一直致力于在泰國(guó)技術(shù)社區(qū)推廣敏捷,并在泰國(guó)軟件公司中組織敏捷培訓(xùn)。 |
|
來(lái)自: 滾滾小白 > 《項(xiàng)目》