本系列的第1篇【用戶故事驅動的敏捷開發(fā) – 1. 計劃篇】跟大家分享了如何使用用戶故事來幫助團隊創(chuàng)建需求的進程,在這1篇中,我們來看看如何使用這些用戶故事和功能點構成產(chǎn)品backlog。產(chǎn)品backlog是敏捷開發(fā)中用來管理需求列表,排定優(yōu)先級,構成迭代計劃,組織開發(fā)/測試和交付進程的工具。可以說,產(chǎn)品backlog是1個敏捷團隊管理開發(fā)進程的核心,所有的活動和交付物都圍繞backlog來進行。1旦需求明確,我們就必須在開發(fā)進程中延續(xù)的跟蹤backlog內(nèi)容的實現(xiàn)和交付進程,確保我們的想法可以依照我們希望的時間和質(zhì)量交付,及時了解偏差并做出調(diào)劑。
從這個時間點開始,我們需要引入電子化工具來管理我們的開發(fā)進程。其實,每一個開發(fā)團隊都會或多或少的使用某種電子化工具,用最多的估計是Word/Excel/Project這類辦公軟件,還有就是如Jira, Redmine, Bugzilla 等工具。對軟件研發(fā)來講,我們需要管理內(nèi)容包括:1)需求/任務/測試用例/Bug/問題等工作事項;2)源代碼;3)各種計劃,包括迭代計劃,發(fā)布計劃,測試計劃等;4)各種工件(包括:依賴包/在制品/交付物),如:JAR包,WAR包,NuGet包,NPM包,安裝包,交付包等;5)人員/團隊。所以,對軟件研發(fā)管理系統(tǒng)來講,我們最少需要這些功能:1)工作項跟蹤;2)計劃制定和跟蹤;3)人員(包括權限)管理;4)源代碼管理;5)自動化引擎。
很多敏捷教練其實對電子化工具持保存態(tài)度,覺得電子化的backlog或kanban等工具會影響團隊的參與感和靈活性。對這1點,我也同意,特別是在進行創(chuàng)造的進程中,我也不同意使用電子化工具。主要緣由是創(chuàng)造的進程需要群策群力,需要每一個團隊成員都有參與感,需要每一個人可以隨時對用戶故事做出改變,這樣的進程如果使用電子化工具會很受限制。
但是,電子化工具依然有其不可替換的用武之地,特別是我們需要進行延續(xù)的跟蹤和數(shù)據(jù)分析的時候,電子化工具就顯示出它的優(yōu)勢;同時,如果你的團隊散布在不同的物理地點,那末使用電子化工具就成為1種必定。由于這些場景都是物理板沒法發(fā)揮作用的時候。另外,斟酌到軟件開發(fā)進程的復雜性和各個部份只見關聯(lián)性很強,如果沒有電子化工具的輔助,是很難支持1個團隊的開發(fā)工作的。
在我?guī)ьI團隊使用用戶故事地圖的進程中,隨著用戶故事數(shù)量的增加,我發(fā)現(xiàn)團隊開始迷失功能點與故事之間關聯(lián)性,分解出來的功能點被淹沒在不同的模塊當中了,用戶故事已開始漸漸消失了。這是個非常不好兆頭,所以我在這個時候開始要求團隊引入電子化工具。
為了能夠更好的說明這個進程,在這個系列中我使用【鳳凰項目:1個IT運維的傳奇故事】這本書為背景的ASP.NET 5樣例利用,創(chuàng)建了1些用戶故事
關于【鳳凰項目:1個IT運維的傳奇故事】:本書講述了1位IT經(jīng)理臨危受命,在未來董事的幫助和自己“3步工作法”理念的支持下,終究挽救了1家具有悠久歷史的汽車配件制造商的故事。 小說揭露了管理現(xiàn)代IT組織與管理傳統(tǒng)工廠的共通的地方,讓讀者不但能對如何管理IT組織心照不宣,更重要的是將以完全不同于以往的視角看待自己的工作環(huán)境。
可以通過以下鏈接購買這本書的中文版:http://item.jd.com/10034038960.html
這個樣例利用可以通過以下地址訪問:
http://pucd.chinacloudsites.cn/
這是1個簡單的電子商務網(wǎng)站原型,具有產(chǎn)品列表,購物車,后臺管理,促銷和定單處理等電子商務網(wǎng)站的基本功能。你可以閱讀1下這個網(wǎng)站,對其中的功能簡單了解1下。
以下是我使用影響地圖和用戶故事地圖整理出來的故事列表,每張圖片的左邊是影響地圖,列出1個故事;右邊是這個故事所分解出來的功能點擺放在用戶故事地圖上的的效果。
上面5個用戶故事所分解出來的功能點我分別使用不同色彩在故事地圖上進行了標注,你可以看到當故事不停增加的時候,這個地圖會漸漸變得非常龐大而復雜,分辨出用戶故事變得愈來愈難。
Team Foundation Server (TFS) 是微軟公司的研發(fā)管理平臺,其中提供了從需求管理,項目管理,配置(源代碼)管理,測試管理,代碼編譯延續(xù)集成,自動化測試,自動化發(fā)布及部署環(huán)境管理在內(nèi)的研發(fā)運維1體化(DevOps)的完全工具鏈。微軟自己的大多數(shù)產(chǎn)品都在使用這個平臺進行研發(fā)管理,其中也對敏捷開發(fā)提供了很好的支持。
在整理用戶故事的進程中,我們可以先使用Excel來記錄這些用戶故事和功能點,同時記錄每一個功能點所屬的功能區(qū)域,構成類似以下的文檔。
以上表格中,我們用2維表的方式保存了用戶故事地圖上的所有關鍵信息,在導入到TFS的時候需要注意:
首先,在TFS中依照功能區(qū)域和模塊創(chuàng)建區(qū)域路徑,對應到用戶故事地圖頂部的分類信息
現(xiàn)在我們就能夠將我們的用戶故事導入到TFS中,
關于如何使用Excel批量導入和更新工作項,請參考:https://msdn.microsoft.com/en-us/library/vs/alm/work/office/bulk-add-modify-work-items-excel
構成的backlog以下,你可以看到TFS很好的保護了我們的用戶故事到功能點之間的聯(lián)系,同時也保存了每一個功能點所對應的功能區(qū)域,這樣就把用戶故事地圖上的關鍵數(shù)據(jù)進行了很好的保護,便于我們從不同的角度來查看和跟蹤。
導入的工作項用不同的字段保存了用戶故事地圖上的關鍵信息:
固然,你依然需要對每一個用戶故事工作項和功能點工作項進行進1步完善,將團隊在討論進程中所產(chǎn)出的信息進行記錄,比如:每一個用戶故事需要包括用戶背景,操作流程圖,交互設計原型;每一個功能點需要包括數(shù)據(jù)字典,輸入輸出,數(shù)據(jù)驗證,界面原型等。這些內(nèi)容可以直接填寫在工作項的 說明 字段,或使用附件的情勢上傳到工作項上統(tǒng)1保存。
在計劃篇中,我強調(diào)過用戶故事所重視的是它所驅動的進程,而不是那份文檔。但是,我們依然需要將團隊討論中所產(chǎn)生的關鍵信息進行詳細的記錄,這樣便于團隊在后續(xù)的開發(fā)中回想起討論的細節(jié)。這些信息在看板或白板這類物理工具上是沒法表達和保存的,所以這個時候引入電子化工具恰到好處。
我們所導入的故事和功能點將構成后續(xù)開發(fā)所使用的backlog,便于團隊對這些內(nèi)容進行優(yōu)先級排序,迭代計劃,任務分解,測試計劃的制定,測試用例的分解等等。也就是說,后續(xù)的軟件研發(fā)進程均會依照我們導入的backlog作為主線進行。這樣,團隊既可以依照用戶的角度來抽取出相應的功能點,也能夠從產(chǎn)品模塊的角度查看功能列表和影響這些模塊的用戶需求,保證團隊在滿足用戶需求與架構優(yōu)化演進之間做出取舍,為團隊建立起完全的需求跟蹤視圖(有很多團隊會稱之為需求跟蹤矩陣)。
見下圖,我們之前所做的其實就是建立的圖中的 架構模型 和 條目化需求 部份的內(nèi)容,同時在這兩部份內(nèi)容之間建立的聯(lián)系,這些是建立1個軟件研發(fā)管理系統(tǒng)的源頭。
至此,我們就完成了用戶故事到產(chǎn)品backlog的轉化,下1篇中將介紹如何完成開發(fā)和測試計劃的制定,并開始引入Kanban來跟蹤開發(fā)進程。
注:以上場景是【DevOps敏捷開發(fā)動手實驗】的1部份,請點擊以下鏈接訪問這個動手實驗的指點文檔:
http://vsalm-hols.readthedocs.org/
參考資料:
有關用戶故事地圖:
http://devopshub.cn/2016/01/10/user-story-mapping-for-the-first-time/
http://devopshub.cn/2016/01/11/how-to-create-user-story-mapping/
有關Team Foundation Server:
http://vsalm-hols.readthedocs.org/zh_CN/latest/concepts/about-vsalm.html
上一篇 分類模型中的參數(shù)估計
下一篇 C#之三十七 實體類