前言:在 上一篇 TFS2015敏捷開發實踐 中,我們給大家介紹了TFS2015中看板的基本使用和功能,這一篇中我們來看一個具體的場景,如何使用看板來執行一個sprint。Sprint是Scrum對迭代的稱謂,也是Scrum中團隊協作的一個迭代單元,包含了Scrum中最主要的活動,我們來看看如何使用看板來支援這些活動。
TFS 2015中對看板功能進行了大量改進。我們可以通過對列,泳道,展示樣式及卡片內容進行定製,使TFS看板具有更強的展示效果與可操作性。本篇博文中我就對TFS 看板進行了一些深度定製,以實現敏捷團隊在TFS 2015看板上完成一個Scrum的Sprint。
團隊介紹
團隊組成:
- 產品負責人: 1名
- Scrum Master: 1名(團隊成員輪流兼任)
- 開發團隊成員: 8名(5開發,3測試)
迭代週期:2周,10個工作日
團隊平均速率:100(每個迭代完成100工作量的積壓工作)
注:在敏捷團隊建立之初,確定一個迭代的週期對於敏捷團隊是最重要的。 迭代週期不是越短越好,迭代週期的選定包含很多要素:
- 團隊能交付一定量的產品增量
- 產品負責人能承諾的不改變已經進行計劃的積壓工作的最長時間
- 測試資源
- 其他因素
Scrum事件發生時間:
迭代計劃會議:迭代第一個工作日上午召開(星期二 9:30 )
每日站立會議:每日早上9:45到10點
迭代評審會議:迭代最後一個工作日下午召開 (星期一),選在週一下午召開是因為我們有一個週末的時間可以處理緊急問題
迭代回顧會議:迭代最後一個工作日下午評審會議完成後召開(星期一)
- 採用6列:新建,當前迭代(會在迭代計劃會議中將本迭代需要完成的PBI和Bug放入此列),開發,測試,釋出(此列可選),完成。 其中當前迭代對應狀態New, 開發對應狀態Approved,測試與釋出對應狀態Committed。
- 關於WIP,當前迭代列為每個迭代的平均完成積壓工作數量;開發、測試列的WIP採用資源數*2-1的方法來計算,比如:開發WIP為 5(開發人員)*2-1 = 9。
- 採用Bug與PBI雙泳道,並且Bug泳道在PBI泳道之上。我這樣設計是為了說明Bug的處理優先順序應該高於PBI,處於當前迭代下游的開發人員,應該優先解決當前迭代列中的Bug。在顯示效果上也更醒目。
- 啟動在開發、測試與釋出列中的緩衝區,就是每個列下面的Doing和Done。因為大家都知道在看板中是採用拉動式生產方式,團隊成員應該從自己所處列的上游拉取卡片到自己的工作列中。因此我們在TFS配置中啟動列的緩衝區,這樣可以明確的告知我們的下游團隊成員哪些卡片使能夠被拉取。比如:如果開發列中的卡片處於Done中,那麼表示開發工作已經完成,測試人員可以對這些PBI或者Bug進行測試。
啟動一個迭代
在迭代計劃會議開始之前我們的產品負責人一定要提前整理好團隊積壓工作列表,包括錄入積壓工作及按照商業價值/緊迫程度為積壓工作排序。這部份工作一定要在開始迭代計劃會議之前完成,不然會大大的降低會議效率。
迭代計劃會議
最左側是由產品負責人整理的擠壓工作列表,優先順序由上到下。那下面我們要確定這個Sprint我們要完成哪些工作:
- 先由產品負責人將最頂的積壓工作拖拽到 當前迭代中,並設定欄位 迭代路徑
- 開發團隊對工作量進行預估,同時讓團隊成員認領積壓工作。關於工作量也多說兩句:工作量與工時是量化完成工作的兩個維度。工時很好理解就是完成積壓工作需要耗費的單位時間,工作量是一個沒有單位的數值,預估的方式為:在積壓工作列表中選取一個最簡單的積壓工作,然後將工作量預估為1,其他的積壓工作的工作量與這個相比較。 工作量數值一般採用近似於斐波那契陣列的值:1,3,5,8,13,20,40,60,100。在TFS中工作項的工作量在積壓工作項中設定,而所需工時需要在由積壓工作項分解出的任務中設定。
- 與產品負責人一同確定驗收標準
- 按照優先順序依次將新建的積壓工作項拖拽到當前迭代列,直到積壓工作項的工作量達到飽和。
關於開發團隊每個迭代的工作量總和可以通過TFS的Sprint 速率報表(Velocity)檢視以往迭代的完成速率來確定。
- 確定如何完成這些積壓工作。細化需求,將積壓工作項分解為任務。如果一個積壓工作不能在一天內完成,我們又想知道每天的工作進度,可以將積壓工作分解為任務,通過任務來跟蹤團隊成員每日的工作情況
每日站立會議
按照先開發人員再測試人員的順序,每個團隊成員只需要回答3個問題:
- 昨天做了什麼? 完成了哪個積壓工作或者任務。 如果積壓工作完成,將積壓工作從開發拖入到測試正在進行中
- 如果該團隊成員完成了工作,將卡片從當前列的Doing移動到Done,表示此工作在當前階段已經完成。
- 如果團隊成員未完成整個PBI只是PBI分解出的任務,可以通過勾選卡片中任務前的勾選框來標記,任務已經完成,系統會自動將任務狀態改為Done。這樣我們可以通過任務來跟蹤團隊成員每天的工作及PBI的工作進度。
- 今天要做什麼?該團隊成員只需要從自身角色所在流程的上游獲取新的卡片即可,比如開發人員在當前迭代中拉取新的PBI或者Bug到開發列的Doing中;測試人員將開發列Done中的PBI拖拽到測試的Doing進行測試
- 遇到了哪些問題?千萬不要在站立會議上尋求問題的解決方案,這會佔用團隊的大量時間,只需要告訴大家你有什麼問題就可以了。
如果我們每個列的卡片過多,每個團隊成員在站立會議過程中只想展示自己的卡片怎麼辦?可以使用看板中的快速搜尋功能
迭代評審會議 & 迭代回顧會議
- 向產品經理交付在測試完成列中的積壓工作,不在新建與釋出列Done列中的其他工作項當前Sprint未完成積壓工作。
- 根據接受標準向產品負責人展示交付物,如果產品負責人接受交付,將積壓工作項拖入完成列。
- 如果產品負責人不接受,開發團隊同意下個迭代進行修改,可以新增標籤註明是哪個迭代的積壓工作,並在下個迭代計劃會議中將積壓工作項拖拽到當前迭代中
對於迭代評審會議的其他事件與迭代回顧會議,由於不涉及看板就不在這裡贅述了。在本文中大家可以看到如何使用TFS看板來完整的執行一個Scrum迭代,下個帖子我將向大家講述怎樣在TFS平臺上提高我們的原始碼開發效率。
請關注微信公眾號 【devopshub】,獲取更多關於DevOps研發運維一體化的資訊