Kanban and Scrum making the most of both - 簡介
source: Kanban and Scrum making the most of both, Henrik Kniberg & Mattias Skarin
http://www.infoq.com/minibooks/kanban-scrum-minibook
我們通常不會寫書. 我們寧可花時間深入戰場, 幫客戶最佳化, 除錯, 以及重構他們的開發流程和組織. 不過, 我們最近注意到一個明顯的趨勢, 希望在此分享一些看法. 下面是一個典型的例子:
Jim: "現在我們終於可以全力執行Scrum了!"
Fred: "所以, 那現在如何呢?"
32. 一般的經驗教訓 (3)
source: Kanban and Scrum making the most of both, Henrik Kniberg & Mattias Skarin
http://www.infoq.com/minibooks/kanban-scrum-minibook
最後的賣點
由回顧開始!
32. 一般的經驗教訓 (2)
source: Kanban and Scrum making the most of both, Henrik Kniberg & Mattias Skarin
http://www.infoq.com/minibooks/kanban-scrum-minibook
白板將會持續演進, 不要讓版面設計都不變
所有的Kanban白板的內容會持續被改變. 在團隊找出真正可行的方法前, 通常都要花兩到三次重新設計. 所以在第一次版面設計時, 會花很多時間來規劃, 以確保之後能很容易重新安排白板的內容. 我們利用黑色的膠布來設計版面, 這些都是很容易重新安排, 並且在牆上或是白板上都適用. 另一種我所看到的方法, 是利用粗的麥克筆來繪製白板的線條(但是要確保他們是可以被擦掉的!?)
32. 一般的經驗教訓 (1)
source: Kanban and Scrum making the most of both, Henrik Kniberg & Mattias Skarin
http://www.infoq.com/minibooks/kanban-scrum-minibook
隨著工作的進展緩慢, 約制開始出現.
所有的團隊一開始, 都是採用相當一般化的WIP現制. 在那個時候, 大部分的精力都花費在試圖去建立流程, 以及確保該組織能獲得它所需要的支援.
31. 事情如何開始改變 (2)
source: Kanban and Scrum making the most of both, Henrik Kniberg & Mattias Skarin
http://www.infoq.com/minibooks/kanban-scrum-minibook
那會怎樣影響團隊的表現?
31. 事情如何開始改變 (1)
source: Kanban and Scrum making the most of both, Henrik Kniberg & Mattias Skarin
http://www.infoq.com/minibooks/kanban-scrum-minibook
在導入Kanban三個月後, 系統管理團隊在IT的部門中, 被管理階層評為"表現最好的團隊". 同時, 系統管理團隊在公司回顧會議中被評選為, 前三個"建設性經驗"中的其中一個. 公司的回顧會議是一個全公司性的事件, 每六週舉行一次. 這是團隊第一次出現在前三名的清單中! 誰想得到三個月前, 團隊曾處於瓶頸狀態, 並且很多人還一直在抱怨.
服務的品質已經增加了, 因此, 這是怎麼發生的?
這不可或缺的關頭是當大家開始通力合作, 經理提供了一個明確的重點, 並且保護團隊免於其它不屬於這裡工作的打擾, 因此團隊可以確保品質和交付期限. 我們大約花了三到四個月才出現這樣的狀況, 可是之後就暢通無阻. 不過不可能所有問題都消失了(那將會使我們都失去工作, 對吧??) - 我們現在面臨了新的挑戰: "我們如何讓團隊保持動力去改進(當他們已經不再是瓶頸之後)?"
30. 要度量什麼?
source: Kanban and Scrum making the most of both, Henrik Kniberg & Mattias Skarin
http://www.infoq.com/minibooks/kanban-scrum-minibook
很多事情事可能可以被度量的 - 循環時間, 速度, 序列, 燃燒狀況... 重要的問題是哪個數據是可以被用來改進流程. 我的建議是去做實驗, 然後看哪個適合你. 我們了解到, 燃燒圖對於小於四週的專案來說是殺雞用牛刀. 基本的進展狀況是藉由查看Kanban的白板來判斷(有多少故事在白板上, 以及有多少已經做完)
我們從度量"每種工作種類的速度"和"序列長度"開始. "每種工作種類的速度"是很容易去度量. "序列長度"則是一個非常好的領先指標, 因為她們可以立即被指出(一但你知道去哪裡去找到它們)
29. 找到一個可行的規劃概念
source: Kanban and Scrum making the most of both, Henrik Kniberg & Mattias Skarin
http://www.infoq.com/minibooks/kanban-scrum-minibook
一個故事
我記得其中一個團隊的轉淚點. 在第二次的估算會議, 我和他們坐在一起. 團隊陷入一個狀況, 他們不知道要如何估算. 他們有太多不知道, 所以整個估算陷入停頓. 與其介入和接手, 我要求他們去改善流程已去找到更好的解法. 在他們經理的帶領之下, 他們重拾挑戰, 並且開始設計自己的解決方案. 這個事件是重要的轉淚點, 一個重要的勝利讓他們建立團隊的信心. 在此之後, 他們開始發展的很迅速, 我們已經讓他們走出自己的路.
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"的區域)
28. 因此, 我們是怎樣真的在運作呢? (1)
source: Kanban and Scrum making the most of both, Henrik Kniberg & Mattias Skarin
http://www.infoq.com/minibooks/kanban-scrum-minibook
Kanban真的是非常不受限制, 你可以把它運用在各種類型的事情上. 你可以讓團隊根據事先預定的活動來運作; 或者你可以根據是否有足夠的動力, 來選擇自己要做的活動.
圖7 當有3個任務放到backlog中, 這將會觸發一個規劃/評估的事件發生
27. 如何評估?
source: Kanban and Scrum making the most of both, Henrik Kniberg & Mattias Skarin
http://www.infoq.com/minibooks/kanban-scrum-minibook
這是一個不斷發展的議題, 當然一定會有一個以上的作法:
# 定期評估
# 當有需要時進行評估
26. 那些任務要放在白板上?
source: Kanban and Scrum making the most of both, Henrik Kniberg & Mattias Skarin
http://www.infoq.com/minibooks/kanban-scrum-minibook
我們早就決定, 不要把團隊所有所做的工作放在白板上. 監督像打電話或是倒咖啡這些事情, 會把Kanban變成一個管理的怪物. 在這裡我們是要去解決問題, 而不是要去產生問題, 對不對? 所以我們決定只把大於1小時的任務放到白板中, 而小於一小時的視為是"白噪音(white noise)". 這一小時的限制, 運作的相當不錯, 是這裡少數沒有改變的事情. 
圖6. 我們一開始假設總共的生產力大部分是消耗在兩類型的工作, 大的(與專案有關)和小的(與支援有關)工作. 追蹤專案的速度, 可以給我們交貨日期一個指示, 如果這是必要的話. "白噪音(white noise)"(較小的支援工作 < 1小時, 倒咖啡, 幫助同事)的工作通常會預期隨時都會有.
25. 實踐WIP的限制
source: Kanban and Scrum making the most of both, Henrik Kniberg & Mattias Skarin
http://www.infoq.com/minibooks/kanban-scrum-minibook
在理論上, 遵守WIP的限制聽起來很簡單. 但在實務上, 實踐WIP的限制是一件棘手的事情. 它意味著在某些階段需要說"不". 我們有嚐試過各種方法來應對.
在白板上討論
24. 設定第一次的WIP限制
source: Kanban and Scrum making the most of both, Henrik Kniberg & Mattias Skarin
http://www.infoq.com/minibooks/kanban-scrum-minibook
我們第一次正在處理的工作項目(WIP)限制是寬鬆的. 我們的理由是因為藉由視覺化的流程, 我們可以查看並體會到有什麼問題發生. 此外不可能一開始, 我們就能夠猜出最正確的限制. 隨著時間的推移, 每當我們發現好的理由時, 我們就可以調整WIP的限制值(我們要做的只是在白板上指明出來).
我們使用的第一個WIP限制是用2n-1(n=團隊成員的個數, -1則是鼓勵要做合作事宜的工作). 為什麼是這樣呢? 簡單地說, 我們沒有更好的主意. 並且這樣開始看起來也沒有爭議. 對於任何想把工作丟給團隊的人, 這個公式提供了一個簡單, 並且合乎邏輯的解釋: "...當我們考慮到每個團隊成員最多可以同時處理兩件工作: 一件正在處理, 一件在等待. 那為什麼你會期待他們能夠承擔更多呢?" 回過頭來看, 任何寬鬆的限制在一開始都會可行. 但藉由監控Kanban白板, 在沿路上可以很容易指出正確的限制為何.
23. 建構第一次的白板 (2)
source: Kanban and Scrum making the most of both, Henrik Kniberg & Mattias Skarin
http://www.infoq.com/minibooks/kanban-scrum-minibook
第一個看板的模型
23. 建構第一次的白板 (1)
source: Kanban and Scrum making the most of both, Henrik Kniberg & Mattias Skarin
http://www.infoq.com/minibooks/kanban-scrum-minibook
製作價值溪流圖(Value Stream map), 是一個很好的方式, 來開始建構看板的白板. 基本上, 它是一個視覺化的價值鏈, 對於整個系統的工作狀態, 流程和時間(週期時間), 提供了詳細的洞察.
但是, 我們開始的比較簡單, 由經理們一起畫在白紙上, 當做一份簡單的白板. 檢視幾次過後我們開始行動. 在這個階段, 有些問題讓人感到不安, 包含:
22. 解決利益關係人
source: Kanban and Scrum making the most of both, Henrik Kniberg & Mattias Skarin
http://www.infoq.com/minibooks/kanban-scrum-minibook
利益關係人會受到看板執行的影響, 這件事情是可能的. 然而這樣的改變會變得更好 - 它意味著團隊會開始拒絕他們不能完成的工作, 開始為了品質而行動, 並且把優先順序地的項目從團隊的backlog中移除. 儘管如此, 做之前先有個討論, 會是一個好的作法.
最有關聯的利益關係人, 是第一線的支援和部門經理. 因為他們有參與研討會, 他們對於繼續下去有著正面的看法, 同樣地, 開發團隊也有相同的想法(不管怎樣, 會或多或少期待有改善). 但是對於這個團隊, 支援團隊, 事情變得不一樣. 他們最大的問題是, 他們的工作負荷量太大. 他們也需要處理客戶的問題, 因為公司有承諾要去回應所有的問題. 如果我們要實施看板和開始強迫WIP限制的話, 現在這種狀況很可能會改變.
因此, 我們到關鍵的利益關係人的地方, 介紹我們的意圖, 預期的利益, 以及可能的結果. 讓我感到欣慰的是, 我們的想法普遍地受到歡迎,甚至有些人評論是"如果我們最後能這些問題長眠, 那是多棒啊".
21. 團隊開始運作
source: Kanban and Scrum making the most of both, Henrik Kniberg & Mattias Skarin
http://www.infoq.com/minibooks/kanban-scrum-minibook
我們如何讓團隊開始運作呢? 並沒有任何手冊說要如何展開, 若是做錯將會有很大的風險. 我們面對的是一個生產平台和高度專業化的人, 這些人是很難被取代的. 不要不但沒有改善, 反而導致他們因此而相互疏離, 這將會是一個很糟的主意.
* 我們應該開始就好? 等到有問題就承擔後果?
20. 開始行動
source: Kanban and Scrum making the most of both, Henrik Kniberg & Mattias Skarin
http://www.infoq.com/minibooks/kanban-scrum-minibook
所以我們需要開始行動, 但是我們要從哪裡開始呢? 唯一我們確定的事情是: 我們不會在原地踏步
我的背景是開發人員, 所以我確定我只知道一些有關營運部門的特性, 我不是要"橫衝直撞和一開始就改變一些事情", 我需要一個較不會反抗的方法, 可以教導我們一些相關的事情, 和放棄一些無關的事情, 並且很容易去學習.
19. 我們從哪裡開始呢?
source: Kanban and Scrum making the most of both, Henrik Kniberg & Mattias Skarin
http://www.infoq.com/minibooks/kanban-scrum-minibook
一個好的開始是藉由詢問開發團隊, 誰是技術營運部門的顧客?
開發人員對營運部門的想法
我問過:"當你想到"營運部門", 你會想到的三件有關他們的事是什麼?" 最常見的答案是:
