28. 因此, 我們是怎樣真的在運作呢? (2)
source: Kanban and Scrum making the most of both, Henrik Kniberg & Mattias Skarin
http://www.infoq.com/minibooks/kanban-scrum-minibook
循環規劃
每週我們舉行循環規劃會議一次. 並且我們在每週同一時間舉行舉行, 這是因為我們發現如果我們沒有把它計算在內, 這段時間可能被其它項目所佔用. 並且我們要求更多團隊交談. 典型的議程會像是:
* 更新圖表和白板. (已經做完的專案會移到"Wall of Done"的區域)
* 查詢上週的內容, 看看發生了什麼事? 為什麼會這樣?怎樣做才能改善呢?
* 重新調整WIP限制值(如果需要的話)
* 任務分解和新的專案的評估(如果有需要它的話)
基本上, 循環計畫是一個結合評估和持續改進的脈動. 小型到中型的問題, 可經由第一線經理在現場解決. 但是有些基本架構有關的問題, 是個很艱難的考驗. 為了處理這些問題, 我們讓團隊有這樣的能力, 可以指派兩個"團隊的障礙"給他們的經理
其中的規則是
1. 經理可以在任何時間點處理這兩個事情
2. 如果已經兩個了, 只要你移掉較不重要的一個, 你便可以增加一個新的
3. 團隊決定這個問題是否被解決
這是一個很正面的改變. 忽然間, 團隊能知道經理正在幫助他們, 即使是很困難的問題. 他們可以指著問題問說"究竟這是怎麼回事?", 但他們不能因為有一個新的較高優先順序的事情, 因而忘記或是拒絕處理.
這裡有個嚴重障礙的例子. 當營運團隊懷疑有個bug時, 營運團隊沒有從開發人員那邊獲得他們所需要的幫助. 他們需要幫忙去指出系統哪個部份造成這個問題, 但是因為開發人員忙碌於開發sprint中的新項目, 所以問題一直被堆放著. 無疑地, 營運團隊會認為開發人員不夠關心品質的問題.
留言列表
