David Ko的學習之旅

source: Kanban and Scrum making the most of both, Henrik Kniberg & Mattias Skarin
http://www.infoq.com/minibooks/kanban-scrum-minibook

Kanban 的本質是一個很簡單的想法: 同時進行的工作 (Work In Progress, WIP) 必須被限制; 當目前手上工作被完成, 或是下游的工作被拉動, 新的工作才可以開始. 看板(或是訊號卡) 會產生視覺化的訊號, 是因為目前工作量沒到達限額, 所以新的工作可以被拉進來. 這聽起來不是革命性的改變, 似乎也不會影響團隊或組織的績效, 文化, 能力或成熟度. 但很神奇地看板做到了！看板看起來只是小的變化, 但是卻改變商業中的一切.

我們意識到, 看板是一個關於變革管理的方法, 它不是軟體開發方法, 也不是專案管理的生命週期或過程. 看板是給現有軟體開發週期或專案管理方法, 引入改變的做法. 看板的原則, 是從你現在做的開始, 藉由分析價值流程來了解你目前的工作流程. 然後在工作流程上的每個階段, 對限制同時工作的量達成共識. 當看板訊號產生時, 藉由拉動工作, 開始讓流程運作.

source: Kanban and Scrum making the most of both, Henrik Kniberg & Mattias Skarin
http://www.infoq.com/minibooks/kanban-scrum-minibook

Henrik Kniberg 是一個非常罕見的人, 他能從複雜的狀況中萃取出事情的本質, 從無序的干擾中梳理出核心想法, 並且產生出非常容易理解的明確解釋. 在本書中, Henrik 出色地解釋了 Scrum 和 Kanban 的差別. 他明確地指出這些只是工具, 而你真的想要的是擁有完整的工具箱, 了解每個工具的長處和限制, 以及如何使用它們.

在本書中, 你將會學習到 Kanban 的全部含義, 他的優點和局限性, 以及使用時機. 你還將會獲得很棒的一堂課: Scrum 或其他工具的改進時機和方案. Henrik 在書中說的很清楚, 你一開始選擇什麼工具並不重要, 重要的是不斷改善它的用法, 以及持續擴充你的工具箱.

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

我們如何讓團隊開始運作呢? 並沒有任何手冊說要如何展開, 若是做錯將會有很大的風險. 我們面對的是一個生產平台和高度專業化的人, 這些人是很難被取代的. 不要不但沒有改善, 反而導致他們因此而相互疏離, 這將會是一個很糟的主意.

* 我們應該開始就好? 等到有問題就承擔後果?