Kanban and Scrum making the most of both

1. 1
如何把看板和 Scrum
發揮到極致
Henrik Kniberg 和 Mattias Skarin 著
Mary Poppendieck 和 David Anderson 序
柯仁傑 (David Ko) 譯

2. 2
Mary Poppendieck 的序
Henrik Kniberg 是一個非常罕見的人, 他能從複雜的狀況中萃取出事情的本質, 從無序
的干擾中梳理出核心想法, 並且產生出非常容易理解的明確解釋. 在本書中, Henrik 出
色地解釋了 Scrum 和 Kanban 的差別. 他明確地指出這些只是工具, 而你真的想要的
是擁有完整的工具箱, 了解每個工具的長處和限制, 以及如何使用它們.
在本書中, 你將會學習到 Kanban 的全部含義, 他的優點和局限性, 以及使用時機. 你
還將會獲得很棒的一堂課: Scrum 或其他工具的改進時機和方案. Henrik 在書中說的
很清楚, 你一開始選擇什麼工具並不重要, 重要的是不斷改善它的用法, 以及持續擴充
你的工具箱.
本書中由 Mattias Skarin 所撰寫的第二部分, 描述了真實生活中 Scrum 和 Kanban
的應用案例, 把本書變得更加精彩. 這裡你會看到這兩個工具如何被個別使用, 或者是
組合起來, 去改善軟體開發流程. 你將會注意到, 沒有所謂最佳的做事方法, 你必須自
己思考, 如何在你的脈絡中, 邁向更好的軟體開發的下一步.
Mary Poppendieck

3. 3
David Anderson 的序
Kanban 的本質是一個很簡單的想法: 同時進行的工作 (Work In Progress, WIP) 必須
被限制; 當目前手上工作被完成, 或是下游的工作被拉動, 新的工作才可以開始. 看板
(或是訊號卡) 會產生視覺化的訊號, 是因為目前工作量沒到達限額, 所以新的工作可以
被拉進來. 這聽起來不是革命性的改變, 似乎也不會影響團隊或組織的績效, 文化, 能
力或成熟度. 但很神奇地看板做到了！看板看起來只是小的變化, 但是卻改變商業中的
一切.
我們意識到, 看板是一個關於變革管理的方法, 它不是軟體開發方法, 也不是專案管理
的生命週期或過程. 看板是給現有軟體開發週期或專案管理方法, 引入改變的做法. 看
板的原則, 是從你現在做的開始, 藉由分析價值流程來了解你目前的工作流程. 然後在
工作流程上的每個階段, 對限制同時工作的量達成共識. 當看板訊號產生時, 藉由拉動
工作, 開始讓流程運作.
看板對實施敏捷開發的團隊非常有用, 但對於只是傳統做法的團隊也能吸引他們的目
光. 在組織文化中要進行精益改造, 和鼓勵持續改進, 看板往往會被導入其中.
因為 WIP 在看板中是被限制的, 不管因為什麼原因, 任何被阻礙的任務, 都會對系統
造成影響. 如果有足夠多的任務被阻礙, 整個流程將會被停止. 這將會迫使整個團隊,
甚至大到整個組織, 聚焦在此來解決問題, 好讓被阻礙的任務再度流動.
看板使用視覺化控制的機制, 追蹤工作流經價值流程的每個階段. 一般來說, 實體白板
加上便利貼, 或者是電子看板 是最常被使用. 最好的方式是兩者都用. 它所帶來的透明
度將會促使文化的轉變. 敏捷方法某些方面已經提供了不錯的透明度, 像是 WIP, 完成
的工作, 以及有關速度的度量報告(也就是每個迭代中完成的工作數量). 然而, 看板更
近一步, 提供了流程和工作流動的透明度. 看板會曝露瓶頸, 堆積在每個階段的工作,
變化, 以及浪費. 所有這些因素都會影響組織的績效, 包含所交付的有價值的工作的數
量, 以及這些交付工作的交付週期. 團隊成員和外面的利害關係人, 都可以從看板中自
己行動(或不做什麼)所帶來的影響. 因此, 早期的研究顯示, 看板可以改變行為, 並且促
進在工作場所有更緊密的協作. 當人們看到瓶頸, 浪費, 和變化所造成的影響, 將會促
使他們討論如何改進, 並且很快地把改進方案落實到他們的流程當中.

4. 4
因此, 看板鼓勵現有流程以漸進的方式演進, 逐漸地向敏捷和精益靠攏. 看板不要求徹
底改變人們的習慣, 而是鼓勵逐步改善. 它的改變是工作者以及和他一起合作的人都達
成共識的.
由於拉式系統的特色, 看板鼓勵延遲承諾, 不管是新工作優先順序的排序, 或者是現有
工作的交付. 一般來說, 團隊同意和上游利害關係人定期開會, 來決定接下來要做什麼.
這類型的會議因為時間短, 所以會經常召開. 在會議上通常要回答一個很簡單的問題.
例如 “目前從上次以來我們有兩個空位, 我們交付的週期時間是 6 週, 你最希望在 6
週之後要交付哪 2 個項目?” 這個問題有兩個含義: 一個問題可以得到快速且明確的答
案, 並且也讓會議很短. 另外, 也意味到了最後時候, 才承諾接下來要做什麼. 透過期待
管理, 縮短從承諾到交付的週期時間, 來改善敏捷性. 而且由於優先順序變化的狀況變
少了, 所以也減少重工的機會.
關於看板我想說的最後一件事, 是限制 WIP 可以讓週期時間變得更容易預測, 並且交
付更加可靠. 當出現障礙或錯誤後的”停線”機制, 也確保高品質的水準, 並讓重工的狀
況急劇下降.
儘管從書中精彩且清楚的解釋可以證明這些好處, 但是如何做到這樣卻看不出來. 看板
並不是在一個下午的時間裡, 忽然間就奇蹟般的頓悟, 它需要幾年才能夠漸漸成型. 許
多深層的心理和社會的影響, 對組織文化, 能力, 成熟度的程度所帶來的改變, 是無法
想像的, 但是它就是發生了. 許多看板所造成的結果是反直覺的. 看起來很機器化的作
法–限制 WIP 和以拉式方法運作–卻對人與人之間的互動和協作的方式, 產生深遠的
影響. 不管是我, 或是其他人, 在開始使用看板時, 都沒有預想到這一點.
我追求一種最小阻力的變革方法, 就是後來的看板方法, 我在 2003 年的時候就清楚明
白這點. 一開始我追求的是機械式的效益, 後來在實施精益技術時發現, 如果管理 WIP
是有意義的, 那限制 WIP 就更有意義, 因為它能夠釋放一部分管理的精力. 所以在
2004 年, 我嘗試在最基本的原則裡放入拉式系統. 那時候有個機會, 微軟有個經理找
我, 希望我幫他管理內部一個正在做維護升級的 IT 團隊. 第一個要落實的就是根據限
制理論的拉式系統方案, 也就大家所知的 Drum-Buffer-Rope (鼓-緩衝-繩法). 效果非
常棒, 週期時間減少了 92%, 生產力增加了 3 倍, 可預測性(due date performance,
截止日期績效)是非常令人滿意的 98%.
在 2005 年 Donald Reinertsen 說服我去實踐完整的看板系統. 在 2006 年, 我掌管
西雅圖 Corbis 公司的軟體工程部門, 因此我有個機會去實施看板. 在 2007 年, 我開
始展示實施看板的成果. 在 2007 年五月, 在芝加哥的 Lean New Product

5. 5
Development Summit 中有了第一次簡報. 同年八月, 我接著在華盛頓 DC 的 Agile
2007 大會裡的開放空間會議中也有分享. 那時候有 25 個人參加, 其中有 3 位來自
Yahoo: Aaron Sanders, Karl Scotland 和 Joe Arnold. 當他們各自回到加州, 印度和
英國後, 在原先很掙扎實施 Scrum 的團隊中, 去推行看板. 同時他們也成立了一個
Yahoo 討論群組, 在寫這個文章的同時, 已經有了 800 個成員. 看板已經被傳播開來
了, 先驅者正在談論他們的經驗.
在 2009 年, 看板的採用率確實在成長, 越來越多一線的報告出來. 在過去五年, 我們
在看板上學到很多東西, 並且也持續學習下去. 我現在的重心是在實施看板, 記錄看板,
講解看板, 和思索看板, 這都是為了更好理解看板, 並且和他人解釋. 我漸漸地不再比
較看板和其他現有敏捷方法, 除了在 2008 年有花時間解釋, 為什麼看板也算是一種和
敏捷相容的方法.
像 ”看板和 Scrum 比較起來如何” 這種問題, 我就留給其他比較有經驗的人回答. 我
很高興 Henrik Kniberg 和 Mattias Skarin 變成這方面的領導者. 身為這個領域的知識工
作者, 你需要一些資訊來決策, 讓你知道要往哪裡走. Henrik 和 Mattias 以我所不行的
方式來滿足大家的需求. Henrik 善於全面的比較, 以及他的實事求是與公正均衡的表達
方式, 給我留下了特別深刻的印象. 他的漫畫和圖片特別有見地, 可以讓你有一畫勝千
言的感覺. Mattias 的實地案例非常重要, 他證明了看板不只是理論, 並且在透過實際案
例, 向你展示了對你的組織有什麼用處.
我希望你能喜歡這書中對看板和 Scrum 的比較, 讓你更深入地了解敏捷, 尤其是看板
和 Scrum. 如果你想要學習更多有關於看板的知識, 歡迎拜訪我們社群的網站: The
Limited WIP Society,
http://www.limitedwipsociety.org/
David Anderson
史魁恩, 華盛頓, 美國
7 月 8 日, 2009 年

6. 6
前言
我們通常不會寫書. 我們寧可花時間深入戰場, 幫客戶最佳化, 除錯, 以及重構他們的
開發流程和組織. 不過, 我們最近注意到一個明顯的趨勢, 希望在此分享一些看法. 下
面是一個典型的例子:
Jim: "現在我們終於可以全力執行 Scrum 了!"
Fred: "所以, 那現在如何呢?"
Jim: "嗯, 比我們以前的狀況好很多 ..."
Fred: "... 但是呢?"
Jim: "... 但是你知道我們是個支援和維護的團隊"
Fred: "是的, 然後呢?"
Jim: "好的, 我們喜歡這整個事情, 像是決定 product backlog 中的優先順序, 自我組織
的團隊, 每日 Scrum 會議, 和回顧會議等等..."
Fred: "所以, 有什麼問題嗎?"
Jim: "我們的 sprint 一直有問題"
Fred: "為什麼?"
Jim: "因為我們發現到, 我們很難去承諾一個兩週的計畫. 迭代對我們來說沒有太大的
意義, 我們只處理今天最重要的事情. 可能我們應該要用為期一週的迭代吧?"
Fred: "那你們能承諾為期一週的工作嗎? 你可以集中精力和平順地工作一周嗎?"
Jim: "不可能, 事實上, 我們每日都有問題進來, 或許我們可能可以做為期一天的
sprints..."
Fred: "那你們的問題可以在一天內就解決了嗎?"
Jim: "不行, 有些時候他們需要好幾天"
Fred: "所以為期一天的 sprint 也是不適用. 那你們曾經考慮過完全不要用 sprint 嗎?"
Jim: "嗯, 坦白說, 我們曾經想過. 但是那不是違背 Scrum 嗎?"
Fred: "Scrum 只是一個工具. 你可以決定何時或是怎麼去用它, 不要變成他的奴隸!"
Jim: "所以我們應該怎麼樣做呢?"
Fred: "你有聽過 Kanban 嗎?"
Jim: "那是什麼? 和 Scrum 有什麼區別呢?"
Fred: "嘿, 可以讀這本書!"
Jim: "但是我真的很喜歡 Scrum 其它的部份, 我需要去轉換嗎?"
Fred: "不用, 你可以結合這兩種技術"
Jim: "什麼? 那要怎麼做?"
Fred: "看這本書你就知道...."

7. 7
這本書的目的
如果你有興趣敏捷軟體開發方法, 那你可能聽過 Scrum, 並且你可能也聽過看板. 所以
我們常常聽到一個問題: "什麼是看板, 和 Scrum 比較起來如何? 那些地方是相輔相成?
有沒有任何潛在的衝突?
這本書的目的就是要去釐清這些困惑, 讓你在你的環境中, 找出如何使用看板和
Scrum 的地方.
如果我們成功了, 請讓我們知道!

8. 8
第一部分 比較
本書的第一部份, 是打算對看板和 Scrum 做出一個客觀和務實的比較. 它是 2009 年
四月 “Kanban vs. Scrum” 這篇文章的微調版本. 這篇文章很受歡迎, 因此我決定把
它寫成一本書. 並且邀請我同事 Mattias, 分享跟另一位客戶的實戰經驗. 這部分特別
棒, 如果你比較喜歡實戰經驗, 你可以忽略第一部分, 直接跳到第二部分, 我不會感到
難過的.
嗯, 或許有一點吧.

9. 9
1. 那麼什麼是 Scrum 和看板呢?
好的, 讓我們試著用少於 250 個字, 來簡述 Scrum 和看板是什麼.
Scrum 概述
* 把組織分割成小規模, 跨功能, 和自我組織的團隊.
* 把工作分割成較小, 並且可具體交付的清單. 會根據優先順序來排列, 及評估每個項
目所需的相對工作量
* 把時間切割成較短且固定長度的迭代(通常是 1~4 周). 每個迭代結束後, 有出貨水準
的程式可以展示.

10. 10
*迭代結束後, 和客戶一起檢視所發佈的項目, 根據所獲得的洞見, 優化發佈計畫, 及更
新工作的優先順序.
* 迭代結束後, 藉由回顧會議來優化流程
因此, 與其很大的團隊, 花很多時間去做一件大的東西; 還不如一個小的團隊, 每次花
點時間打造一點東西. 藉由規律整合來看到全貌.
242 個字... 已經夠接近了.
如果需要更多資訊, 請參考“Scrum 和 XP 的實戰經驗”. 這本書有免費的線上版本. 我
認識這位作者, 他是個好人哦 :o)
http://www.crisp.se/ScrumAndXpFromTheTrenches.html.
在這裡有更多 Scrum 的連結
http://www.crisp.se/ScrumAndXpFromTheTrenches.html
看板概述
* 工作流程視覺化
# 把工作切割成小塊, 將他們寫到卡片內, 並貼到牆壁上
# 把每行標上名稱, 以說明工作流程中項目的狀態
* 限制正在進行中的工作(WIP, work in progress) - 明確限制工作流程中每個狀
態最多同時進行的項目數.
* 度量前置時間(lead time)(平均去完成每個項目的時間, 有時候又叫"週期時間

11. 11
"(cycle time)). 優化流程去使得前置時間盡可能的短, 以及可預測
我們收集一些有用的看板連結在 http://www.crisp.se/kanban

12. 12
2. 那麼, Scrum 和看板有什麼關聯?
Scrum 和看板都是流程的工具
工具 = 任何可以完成工作或目標的東西.
流程 = 你如何工作
Scrum 和看板都是流程的工具, 在一定的程度上, 它們會告訴你要做什麼, 來幫助你工
作的更有效率. Java 也是個工具, 它提供你一個簡單的方式, 來撰寫電腦程式. 牙刷也
是個工具, 它幫助你接觸到你的牙齒, 所以你可以清潔他們.
比較是為了要理解, 而不是比高低
刀或叉 - 那一個工具比較好?
相當沒有意義的問題, 對嗎? 因為答案取決於你的情境. 吃肉丸時用叉最好, 要切磨菇
可能用刀比較合適, 若是要敲桌子兩者一樣好. 若要吃牛排, 你可能要兩者一起使用.
若要吃米飯... 嗯... 有些人喜歡用叉, 而有些人喜歡用筷子.

13. 13
所以當我們在比較工具時, 我們應該要小心. 比較是為了要理解, 而不是比高低.
沒有任何工具是完備的, 沒有任何工具是完美的
就像任何工具, Scrum 和看板既不完美也不完備. 它們不會告訴你, 任何你需要做的事
情, 它只是提供一定的約束和指導方針. 例如, Scrum 限制你要有時間盒的迭代, 和跨
功能的團隊. 看板則限制你要用視覺化的白板, 並且限制工作個數(queue)的多寡.
相當有趣的是, 工具的價值限制了你的選擇. 一個可以讓你做任何事的流程工具, 通常
不是很有用. 我們會叫這個流程工具是"什麼都可以", 但是它真的是"作正確的事"嗎?
若有個"會作正確的事"的流程能夠確保沒問題, 那它將會是一個銀製子彈. 如果它不可
行, 很明顯地, 你一定沒有遵守這個流程 :o)
使用正確的工具可以幫助你成功, 但是不保證一定成功. 人們很容易混淆專案成/敗和
工具成/敗的關係.
l 一個專案可能會成功, 是因為用一個偉大的工具.
l 一個專案可能會成功, 儘管使用了一個糟糕的工具.
l 一個專案可能失敗, 因為使用了一個糟糕的工具.
l 一個專案可能會失敗, 但它用了一個偉大的工具.
Scrum 比看板更多規範
我們可以藉由它們提供多少規則來比較這些工具. "規範的(Prescriptive)" 意謂著 "要
遵守較多的規則", "可調適的(Adaptive)" 意謂著 "要遵守較少的規則". “100% 規範”
意謂著你不需要用到大腦, 這裡對每件事情都有規則. “100% 可調適” 意謂著做任何事
都可以, 這裡一點規則或限制都沒有. 正如同你所看到的, 這兩種極端都是很可笑的.
敏捷方法有時候又稱為輕量級方法, 因為他們比傳統方法有較少的規範. 敏捷宣言的第
一條宗旨, 就是"個人和互動勝於流程與工具".

14. 14
Scrum 和看板兩者都是高度可調適性的. 但相對而言, Scrum 比看板有更多的規範.
Scrum 有較多的限制, 只留下一些選擇是未定的. 例如, Scrum 規定要有時間盒的迭代,
而看板沒有.
讓我們從規範度和調適的程度, 來比較更多的流程工具:
RUP 是非常有規範的 - 它有超過 30 個角色, 20 多個活動, 和 70 多個產出物. 它有一
大堆東西要學習, 然而你不會真的用到所有的東西吧. 應該根據你的專案, 選擇適當的
部分. 不幸的是, 它看起來很難做到. "嗯....我們需要建構審核調查結果 (configuration
audit findings artifacts) 嗎? 我們需要一個變更控制經理 (change control manager)
嗎? 不確定, 所以我們最好保留他們以防萬一.". 所以這就為什麼 RUP 和敏捷方法 (像
是 Scrum 和 XP) 作比較時, RUP 的實作往往是重量級的.
XP (極限編程) 和 Scrum 比起來是相當有規範的. 它包含了大部分的 Scrum + 一堆相
當具體的工程實務, 像是測試驅動開發和搭檔編程.
Scrum 比 XP 還少點規範, 因為它沒有規定任何工程的實務. 但 Scrum 是比看板有更多
的規範, 它多規定一些事情, 像是迭代和跨功能團隊.
Scrum 和 RUP 之間的一個主要差別, 是 RUP 給你太多東西, 你應該要移除不需要的部
份. 然而在 Scrum 中, 你得到的太少, 需要增加你遺漏的部份.

15. 15
看板對所有事情都是開放的. 僅有的約束是要視覺化你的工作流程, 和限制你同時處理
的工作數量. 雖然只比 "Do Whatever" 再多一點限制, 但是你會驚訝它的效用居然這
麼強大.
不要限制你自己只用一個工具
根據你的需求來混合及配對工具! 我很難想像一個成功的 Scrum 團隊, 沒有包含 XP 大
多元素. 例如, 許多看板的團隊使用每日會議 (Scrum 的做法). 有些 Scrum 團隊會用
使用個案 (use case, RUP 的實踐) 來撰寫他們的 backlog; 或者限制他們同時工作量
的大小(看板的方式). 不管是什麼, 只要能幫你做事就好.
宮本武藏說的好: 勿以器御心. (17 世紀著名的武士, 他以雙劍戰鬥技術著名)
不過, 我們還是要注意每個工具的限制. 例如, 如果你使用 Scrum, 卻決定停止使用時
間盒的迭代 (或者其他 Scrum 核心觀點), 那就不要說你是在使用 Scrum. Scrum 已經
是精簡到不能再精簡, 如果你移掉一些東西, 可是仍然叫它 Scrum, 這將會變得沒有意
義, 且令人混淆的. 應該叫它 "受到 Scrum 啟發", 或是"Scrum 的子集合", 或者你認為
"有點 Scrum"如何 :O)

16. 16
3. Scrum 所規定的角色
Scrum 規定 3 個角色: 產品負責人 (設定產品願景和優先事項), 團隊 (實作產品), 和
Scrum master (排除障礙和擔任流程的領導角色).
看板沒有規定任何角色
這並不意味你不能或不應該在看板中有產品負責人的角色. 它只是意味著這不一定要.
在 Scrum 和看板中, 你可以根據你的需求, 增加任何額外的角色.
然而在新增角色時要小心. 要確認額外的角色是真的有加值, 不會和流程中其他成員相
衝突. 你確定需要專案經理這個角色嗎? 在大型的專案中, 這可能是個好的主意, 他可
以幫助不同團隊和產品負責人間同步訊息. 可是在小型專案中, 這樣的角色可能是種浪
費, 或者更糟的是, 可能導致局部優化和微觀管理.
在 Scrum 和看板中, 主要的思維是"少即是多". 所以當有懷疑時, 從少開始.
在接下來的部份, 我將會使用"產品負責人"這個術語, 來代表決定團隊優先順序的人,
不管是哪個流程被使用到.

17. 17
4. Scrum 規定有時間盒的迭代
Scrum 是以時間盒的迭代為基礎. 你可以選擇迭代的長度, 但是一般而言, 迭代的長度
需要保持相同, 並且持續一段時間, 以建立一定的節奏.
* 在迭代的開始時: 迭代計畫要被建立. 換言之, 團隊根據產品負責人的優先順序,
和團隊認為他們在一個迭代中可以完成多少項目, 在產品 backlog 中挑出特定數量的
項目.
* 在迭代的過程時: 團隊集中火力來完成他們承諾的項目. 迭代的範圍是固定的.
* 在迭代的結束時: 團隊對利害關係人展示可運作的程式碼. 理想上, 程式碼應該是
可交付的(也就是被測過的). 然後團隊進行回顧會議, 討論和改進他們的流程.
所以 Scrum 的迭代是一個有時間盒的單一節奏, 結合了三種不同的活動: 規劃, 流程改
進, 以及(理想上的)發佈.
在看板中, 並沒有規定要有時間盒的迭代. 你可以選擇什麼時候去做規劃, 流程改進,
和發佈. 你可以選擇定期去做這些活動(每星期一發佈), 或者有需求才做(每當我們有了
有用的東西要發佈, 才會去發佈)
團隊 #1 (單一節奏)
"我們使用 Scrum 的迭代"
團隊 #2 (3 個節奏)
"我們有 3 個不同的節奏. 每個禮拜, 我們會發佈任何我們可發佈的部份. 每兩個禮拜,
我們會有一個規劃會議, 並且更新我們的優先順序和發佈計畫. 每四個禮拜, 我們會有
一個回顧會議, 調整和改善我們的流程"

18. 18
團隊 #3 (主要是事件驅動)
"每當我們快做完事情時, 我們會觸發一個規劃會議. 當 MMF(最小可銷售的功能集,
minimum marketable feature set)準備好時, 我們就觸發一個發佈. 每當我們遇到同樣
的問題重複發生, 我們就觸發自發性的品管圈來處理. 我們也會每四個星期進行更深入
的回顧會議."

19. 19
5. 看板限制每個工作流程狀態的 WIP,
Scrum 限制每個迭代的 WIP
在 Scrum 中, sprint backlog 顯示了目前這個迭代中, 有那些工作要被執行. ("sprint,
衝刺", 這是英式橄欖球的術語) 通常這些工作會以卡片方式貼在牆上. 我們稱這個板
為 Scrum 的白板, 或是任務的白板.
所以, 那麼 Scrum 的白板和看板的白板有什麼不同呢? 讓我們用一個簡單的項目來比
較他們:
在這兩種方法中, 我們利用工作流程的進展, 來追蹤一群工作項目. 我們選擇了三種狀
態: 待處理 (To Do),進行中 (Ongoing), 和已完成 (done). 你可以選擇任何你需要的狀
態 - 有些團隊會增加一些狀態, 像是整合 (Integrate), 測試 (Test), 發佈 (Release)
等等. 但是不要忘記少即是多的原則.
所以, 那這兩個白板有什麼分別呢? 是的, 在看板的白板中, 有個小 2 在中間的欄位.
那就是不同所在. 這個 2 代表 "在任何時刻, 這個欄位不會有超過兩個以上的項目".
在 Scrum 中, 沒有任何規則會阻止團隊把所有的項目都放在"進行中"這個欄位! 因為迭
代本身有固定的範圍, 所以這是一個隱晦的限制. 在這個例子中, 整個白板中只有 4 個
項目, 所以在每個欄位有個隱藏的限制是 4. 因此, Scrum 是間接限制 WIP, 而看板則
是直接限制 WIP.

20. 20
最終, 大部分 Scrum 的團隊會明白, 太多進行中的項目是個壞主意. 因此, 會逐漸形成
一個文化: 在開始新的項目前, 先完成目前沒做完的項目. 有些人甚至去限制 “進行中”
欄位的項目個數, 然後 – 你看 – Scrum 的白板變成看板的白板.
所以 Scrum 和看板兩者都限制了 WIP, 但是用了不同的方法. Scrum 團隊通常是衡量
速度 - 多少項目(或是相對應的單位, 像是"故事點數")在迭代中完成. 一但團隊知道他
們的速度, 那將變成他們 WIP 的限制(或至少是個指引). 一個平均速度是 10 的團隊,
在迭代中通常不會做超過 10 個項目(或故事點數)
因此, 在 Scrum 中, WIP 是限制了每個時間的單位.
而在看板中, WIP 限制了每個工作流程的狀態
以上面看版的例子來說, 在任何時間, 最多 2 個項目會在"進行中"的狀態, 不管它是任
何節奏. 你需要去抉擇什麼樣的限制會要加到那些工作流程的狀態. 但是一般而言, 是
限制整個工作流程狀態的 WIP. 最好這個值在整個流程狀態中, 是越早被套用越好, 並
且越晚被解除越好. 所以在上面的例子中, 我們應該也要考慮加 WIP 的限制到"待處理
"的狀態(或者你稱做輸入序列也可以). 一但我們有適當的 WIP 限制, 我們便能開始度
量和預測前置時間(lead time). 也就是, 平均一個項目在整個白板上從頭到尾移動的時
間. 有了前置時間, 便可以讓我們去承諾 SLA(服務等級契約, services-level
agreements)和制定務實的發佈計畫.
如果項目的大小相差很大, 你可能考慮用故事點數來代替定義好的 WIP 限制, 或者任
何你習慣使用的單位來代替. 有些團隊會花精力去把項目拆解成相同的大小, 以避免這
類型的考量, 並減少時間花在評估這樣的事情上(你可能甚至會認為這樣評估是種浪費).
如果項目的大小大致是相同的話, 那就很容易去建立一個順暢進行的系統.

21. 21
6. 兩者都是以經驗為依據的
想像一下, 如果有這樣的儀器, 並且上面有些旋轉鈕, 可以讓你簡單地藉由調整這些旋
轉鈕, 就可以調整你的流程. "我要高性能, 低前置時間, 高品質, 和高度可預測性. 所
以我將各自地調整它們到 10, 1, 10, 10."
那不是很好嗎? 很遺憾的是, 沒有這樣這麼直接的控制. 這並不是我知道的少, 如果你
有發現, 請讓我也知道.
相反地, 我們有一堆間接的控制.
Scrum 和看板都是以經驗為依據的, 這個意思就是當你去實驗這流程時, 你會被期待要
去客製化它, 以適應你的狀況. 事實上, 你必須要去體驗, 因為不論 Scrum 或是看板,
都不會提供所有的答案 - 它們只是給你一些限制, 以迫使你自己流程的改進.
* Scrum 說你應該要組成跨功能的團隊. 所以那誰應該在什麼團隊呢? 不知道, 要實驗
看看.
* Scrum 說團隊要自行選擇在一個 sprint 要做多少工作. 所以那應該有多少工作被放
進去呢? 不知道, 要實驗看看.

22. 22
* 看板說你應該限制 WIP. 所以那這個限制應該是多少呢? 不知道, 要實驗看看.
正如我前面提到的, 看板是比 Scrum 有著較少的限制. 這意味著你會得到更多的參數
來思考, 及更多的旋轉鈕去調整. 這既可以是缺點, 也可以是優點, 但要視你的狀況而
定. 當你打開一個軟體工具的建構對話盒, 你會喜歡有 3 個選項去選, 還是有 100 個選
項去調整? 也許介於兩者之間. 這將取決於有多少狀況你需要調整, 或者你有多了解這
個工具.
因此, 如果我們減少 WIP 的值, 根據假設, 這將會改進我們的流程. 然後我們觀察一下
一些事情, 像是效能, 前置時間, 品質和可預測性的變化. 我們可以從這些結果得出結
論, 然後改變一些事情, 持續不斷地改善我們的流程.
這裡有很多名稱來形容這件事情. Kaizen(日本話的"改善", 在 Lean 的行話是持續改進),
檢視 & 調適 (以 Scrum 的行話來說), 務實的流程控制, 或是為什麼不是科學方法
這件事情最關鍵的元素是回饋迴路. 也就是改變一些 => 檢查一下它會怎樣 => 從中學
到什麼 => 再改變一些事情. 一般來說, 你會想辦法盡量縮短回饋迴路, 所以你才能很
快調適你的流程.
在 Scrum 中, 基本的回饋迴路是 sprint. 然而, 如果你結合 XP(eXtreme programming,
極致編程)那會有更多的回饋:
當事情被做的正確時, Scrum + XP 會給你一堆很有價值的回饋迴路

23. 23
最內圈的回饋迴路, 搭檔編程, 它是在幾秒鐘發生的回饋迴路. 錯誤可以在幾秒鐘內被
發現以及被修復("嘿, 這變數不是應該是 3 嗎?"). 這是一個"我們是否把這東西做對?"
的回饋迴路.
最外圈的回饋迴路, sprint, 它是一個幾週的回饋週期. 這是一個"我們是否做對的東西"
的回饋迴路.
那看板怎麼樣呢? 嗯, 不論你是否使用看板, 首先你可以(也可能應該)把上述所有回饋
迴路放進你的流程. 然後看板會給你一些非常有用的即時衡量.
* 平均所需的前置時間. 每次有項目被"做完"時, 會更新這個數值. (或者每當你宣稱已
經放到最右邊那個欄位)
* 瓶頸. 典型的症狀是某個欄位 X 擠滿了工作項目, 而第 X+1 欄位則是空著的. 尋找出
白板上的"氣泡(air bubbles)"
有關於即時衡量最棒的事是, 根據你多久願意分析衡量的結果和作出改變, 你可以選擇
你回饋迴路的長度. 太長的回饋迴路, 意味著你的流程改進會十分緩慢. 太短的回饋迴
路, 意味著在每次改變之間, 你的流程可能還沒有足夠的時間去穩定下來, 這將會導致
不斷的抖動.
事實上, 回饋迴路的長度本身是一件你能實驗的事情, 有點像分析回饋迴路的回饋迴路
(meta-feedback loop).
好吧! 我就講到這裡為止.
範例: 在看板中實驗 WIP 的限制
看板其中一個典型的"調整點"是 WIP 的限制. 那麼, 我們如何知道這樣做是否是正確
的?
假設我們有一個 4 個人的團隊, 我們決定 WIP 限制的值一開始是 1.

24. 24
每當我們開始處理一個項目, 在這個項目作完前, 我們不能再開始處理任何新的項目.
所以它將會很快的被做完
很棒! 但是事實證明, 對於一個有四個人的團隊, 它通常是不可以行的(在這範例中很明
顯), 因為我們有人坐著沒事做. 如果只發生一次, 那沒有問題. 但是如果它經常發生,
其結果是平均前置時間將會增加. 基本上來說, WIP 為 1 意味著當有項目到來時"進行
中"欄位時, 它要很快地被處理. 但是大多數的項目都在"待處理"欄位阻塞超過所需要
的時間, 所以在整個工作流程中, 前置時間的總和將會變成不必要地高.
因此, 如果 WIP 為 1 是太少的話, 那增加到 8 如何?

25. 25
這將有一段時間能運作的很好. 我們發現, 平均而言, 成雙成對的將會使工作做完地最
快. 所以以一個 4 個人的團隊, 隨時隨地, 我們通常有兩個進行中的項目. WIP 值是 8
只是最高的限制, 因此有較少的項目在進行中會比較好.
但是, 想像一下, 我們遇到一個有關整合伺服器的問題, 所以我們不能完整地完成任何
項目(我們做完的定義包含要做整合). 這樣的事情有時候會發生, 不是嗎?
既然我們不能完成項目 D 或 E, 我們開始進行項目 F. 但我們無法整合任何一個項目,
所以我們再找一個新的項目 G. 過了一會兒, 我們達到我們看板的限制 - 8 個項目在"
進行中"

26. 26
在這個時刻, 我們無法再拉更多項目來做. 嘿, 我們最好修復壞掉的整合伺服器! WIP
的限制會我們做出反應和修復瓶頸, 而不是只是放了一大堆為完成的工作.
這是很好的. 但是如果 WIP 的限制是 4 的話, 我們將能早一點作出反應, 因此讓我們
有更好的前置時間的平均值. 所以這是一種權衡. 我們要衡量前置時間, 並且保持最佳
化 WIP 的限制, 以優化前置時間.
過了一會兒, 我們可能發現有些項目堆在"待處理"的欄位. 這也是個時機點, 同樣地去
增加 WIP 的限制.

27. 27
為什麼我們需要一個"待處理"的欄位呢? 嗯, 如果每當團隊詢問時, 顧客能隨時告訴團
隊下一步要做什麼, 那"待處理"的欄位可以不需要. 但是在顧客有時候不是有空的狀況
下, "待處理"的欄位會讓團隊有個小的緩衝區, 可讓團隊在這段時間還有工作可處理.
實驗! 或者如 Scrum 專家說的, 檢視&調適

28. 28
7. Scrum 拒絕在迭代內作改變
比方說, 我們的 Scrum 白板看起來像這樣子:
如果有人出現, 說想要增加 E 到白板上去呢?
Scrum 的團隊通常會這樣說: "不, 對不起, 我們已經承諾要在這個迭代做 A+B+C+D. 但
是可以隨意把 E 放到產品 backlog 上去. 如果產品負責人認為它有較高的優先順序, 我
們會把它放到下次的迭代中." 正確的 sprint 長度, 是剛好讓團隊足夠的時間集中精神
把事情做完, 同時還允許產品負責人定期去管理和更新優先順序.
那麼, 看板團隊會說什麼呢?

29. 29
看板團隊可能會說: "請隨意去增加 E 到"待處理"的欄位. 但是因為這個欄位的限制是
2, 所以在這種情況下你需要去移掉 C 或 D. 我們現在正在處理 A 和 B, 只要我們一有
空檔, 我們會從"待處理"欄位中, 把最重要的項目拿來處理."
因此, 一個看板團隊的反應時間(多久能回應一個優先順序的改變), 在根據一般的原則:
"一個項目處理完 = 另一個項目才能進來"(由 WIP 的限制來驅動), 是指多久才能讓你
有空擋去處理下一個項目.
在 Scrum 中, 平均來說, 反應時間是 sprint 長度的一半.
在 Scrum 裡面, 產品負責人不能碰觸 Scrum 的白板, 因為團隊已經承諾在這個迭代中,
要完成一些特定的項目. 在看板中, 你必需設定你自己的基本規則, 也就是誰可以被允
許去改變白板的內容. 通常來說, 產品負責人會在最左邊的欄位, 像"待處理", 或"準備
中", 或"Backlog", 或"建議的", 那裡他可以隨時根據自己的喜好更改內容.
然而這兩種方法並不互相排斥. Scrum 團隊可以決定允許產品負責人, 在 sprint 中間去
修改優先順序(雖然這通常會被認為是例外). 而看板團隊可以決定去增加些限制, 當優
先順序要被改變時. 甚至看板團隊可以決定採用有時間盒的迭代, 並且固定承諾的範
圍, 就像 Scrum 一樣.

30. 30
8. 每次迭代開始 Scrum 的白板會重新設
定
在迭代的不同階段中, Scrum 白板通常看起來會像這樣:
當這個 sprint 結束, 白板的內容會被清除 - 所有的項目被移除. 新的 sprint 開始, 之
後會進行 sprint 規劃會議, 我們就會有新的內容在 Scrum 白板, 所有新的項目會在最
左邊的欄位. 就技術上來說, 這是一種浪費, 但是有經驗的 Scrum 團隊通常不會在此花
太久的時間, 重置白板的流程會讓你有不錯的成就感和結束的感覺. 就像晚餐後要洗碗
的感覺 - 做起來有點痛苦, 但是做完後感覺不錯.
在看板中, 白板的內容通常是持續的事情 - 你不需要去重新設定和重新開始.

31. 31
9. Scrum 規定要跨功能的團隊
一個 Scrum 白板剛好只被一個 Scrum 團隊所擁有. Scrum 團隊是跨功能的, 在這個迭
代中, 要完成這些項目所需要的所有技巧, 它都有包含到. Scrum 白板通常是所有有興
趣的人都看得到的, 但是只有擁有這個看板的 Scrum 團隊可以修改它 - 它是在迭代中
用來管理他們承諾的工具.
在看板中, 跨功能的團隊不是必要的, 白板不需要被某個特定的團所擁有. 白板只是有
關於某個工作流程, 不需要是某個團隊.
這裡有兩個例子:
範例 1: 這整個白板只給一個跨功能的團隊使用, 就像 Scrum 一樣.

32. 32
範例 2: 產品負責人設定欄位 1 中的優先順序. 跨功能的開發團隊會進行開發(欄位 2)
和測試(欄位 3). 發佈(欄位 4)是由專家小組來處理. 在此這些團隊能力上有些重複, 所
以如果發佈小組成為瓶頸時, 開發人員可以幫助他們.
因此, 在看板中, 你需要建立一些基本規則, 決定誰可以使用這個白板, 及如何使用.
然後實驗這些規則, 以優化這個流程.

33. 33
10. Scrum backlog 的項目必須適合在
sprint 內完成
Scrum 和看板都是基於漸進式開發. 也就是, 把工作拆解成更小的工作.
Scrum 團隊只會承諾他們認為能在一個迭代中完成的項目(根據"做完"的定義). 如果項
目太大, 以至於不適合在一個 sprint 內完成, 產品負責人需要試著找到方法, 去把它拆
解成更小的項目, 直到他們合適在一個 sprint 內完成. 如果項目都有較大的傾向, 迭代
將會被拉長(儘管通常不會長超過 4 個禮拜).
看板團隊需要試著去減少前置時間和流程的大小. 所以間接創造出一個動機, 去把項目
拆解成更小的項目. 但是並沒有明確的規定, 所有項目一開始就要小的足夠可以放到某
個時間盒裡面. 因此, 在同一個白板上, 我們可能有個項目需要花一個月才能完成, 而
另一個項目只需要一天.

34. 34
11. Scrum 規定要做評估和衡量速度
在 Scrum 中, 對於他們承諾要做的每個項目, 團隊應該要去評估其相對大小(工作的大
小). 在 sprint 結束時, 藉由加總每個完成項目的大小, 我們可以得到速度. 速度是對能
力的衡量 - 在每次 sprint 我們可以交付多少東西. 下面有一個團隊的例子, 他們平均
速度是 8.
知道平均速度為 8 是件很好的事. 因為對於在即將到來的 sprint 中可以完成那些項目,
我們可以做出合理的預測, 因此可規劃出務實的計畫.
在看板中, 評估沒有被規定要做. 所以如果你需要做出承諾, 你需要去決定如何提供可
預測性.
有些團隊選擇做出評估和衡量速度, 就像 Scrum 一樣. 其它團隊則選擇跳過評估, 但是
會試著把每個項目, 拆解成大致相同大小 - 然後他們可以藉由每單位時間內有多少項
目被完成, 來簡單地評估速度(例如每週有多少功能). 有些團隊把項目分類到 MMF(最
小可銷售的功能集, minimum marketable features), 並測量每個 MMF 的平均前置時
間, 並且使用它來建立 SLA(服務層級協議, service-level agreements) - 例如: "我們
承諾一個 MMF, 可以總是在十五天內被交付"
雖然有各式各樣有趣的技巧, 可以進行看板風格的發佈計畫和承諾管理 - 但是沒有任
何特定的技巧是被規定一定要做的. 因此可以到 google 上面尋找, 嘗試一些不同的技
巧, 直到找到一個適合你的狀況為止. 隨著時間的推移, 我們可能會看到一些"最佳實務
"的出現.

35. 35
12. 兩者都允許同時處理多個產品的工作
在 Scrum 中, "產品 backlog"是一個較為不幸的名字, 因為它意味著所有項目必須都是
為了同一個產品. 這裡有兩個產品, 綠色和黃色, 每一個有它們自己的產品 backlog 和
它們自己的團隊:
如果你只有一個團隊呢? 好的, 把產品 backlog 想成團隊的 backlog. 它會為某個團隊
(或一組團隊), 為即將到來的迭代列出優先順序. 所以, 如果這個團隊要維護多個產品
時, 把它們合併成一份清單. 那會強迫我們去排出產品之間的優先順序, 在某些況下這
是有用的. 在實務上, 有幾種方法可以進行:
有一種策略是讓團隊在每次 sprint 專注於一個產品:
另一種策略是讓團隊在每次 sprint 中, 同時處理來自兩個產品的功能 :

36. 36
這是和看板相同. 我們有好幾個產品流竄中相同的白板中, 可能利用不同顏色的便利貼
來區分它們:
... 或者利用"泳道"來區分:

37. 37
13. 兩者都是精實(lean)和敏捷
我不打算在這裡討論精實思想和敏捷宣言. 但是一般來說, Scrum 和看板跟這些價值和
原則完全是一致的. 例如:
* Scrum 和看板都是拉式排程系統, 相當於 JIT(Just In Time)庫存管理精益原則, 這
意味著團隊選擇何時及承諾多少工作要做. 當他們準備好時, 他們會"拉"工作來做,
而不是有工作從外面推進來. 就像印表機一樣, 只有當它準備好要印刷時, 它才會拉
下一張紙進來(雖然它每次能夠拉的紙, 是很少並且數量有限的).
* Scrum 和看板是個持續進行, 和累積經驗的流程優化過程. 它符合精益的改善原則.
* Scrum 和看板強調反應變化勝於遵循計畫(雖然看板通常可以比 Scrum 反應更快),
這是敏捷宣言中四個價值的其中一個.
...等等.
從某個角度來看, Scrum 被認為並沒有那麼精實, 因為它規定要在有時間盒限制的迭代
內, 批次處理項目. 但是這是取決於你迭代的長度, 和你要比較什麼. 在傳統的流程,
我們可能每年整合和發佈一些東西 2-4 次. 和它比較起來, Scrum 團隊每兩週能產生可
交付的程式碼, 所以是極端的精實.
但是, 如果你要讓你的迭代儘可能的短, 你本質上會開始著手使用看板. 當你開始談論
讓迭代短於一週, 你可能會考慮完全放棄有時間盒的迭代.
雖然我之前已經提過, 但是我再提一次: 一直嘗試, 直到找到適合你的狀況為止! 然後
繼續嘗試 :o)

38. 38
14. 細小的差異
這裡有些分歧, 但似乎沒有比之前提的那麼重要. 然而, 能瞭解它們也是很好的.
Scrum 規定要有訂好優先順序的產品 backlog
在 Scrum 中, 優先順序是藉由整理產品 backlog 來完成, 而優先順序的改變會在下個
sprint 中生效(而不是現在的 sprint). 在看板中, 你可以選擇任何優先順序的計畫(甚至
沒有), 只要產能能允許, 改變就能生效(而不是在固定的時間). 它可能有, 也可能沒有
一個產品的 backlog; 並且它可能有, 也可能沒有優先順序.
實際上, 這差別並不大. 在看板的白板上面, 最左邊欄位填寫的內容, 通常和 Scrum 產
品 backlog 的目的相同. 不論是否這個列表依照優先順序排序, 團隊需要某些判定的規
則, 來決定哪些項目要先被拉出來做. 這裡有些判定規則的例子:
* 始終拿最重要的項目
* 始終拿最古老的項目(所以每個項目都有一個時戳, timestamp)
* 可拿任何項目
* 大約花 20%時間在維護的項目, 80%的時間在新功能
* 把團隊的產能大致平均分配到產品 A 和產品 B
* 始終先拿紅色項目, 如果有的話.
在 Scrum 裏, 產品 backlog 也能以有點看板的方式來使用. 我們可以限制它的規模, 並
且建立判定的規則, 來決定它應該如何被排定優先順序.
在 Scrum 裏每日會議是規定要的
Scrum 團隊每天在相同時間相同地點, 有個簡短的會議(最多 15 分鐘). 這會議的目的是
去傳播訊息, 有關於什麼是正在進行, 計畫今天要做的工作. 以及指出任何重大的問題.
有時候這又稱為每日站立會議, 因為它通常是站著開會(以保持簡短和維持很高的幹勁).

39. 39
看板中沒有規定要每日站立會議, 但是大部分看板團隊似乎都有這樣做. 它是很好的技
術, 不管你是用什麼流程.
在看板中, 會議的形式是以人為主 - 每個人一個接著一個報告. 許多看板團隊以白板
導向的形式來進行, 著重於瓶頸和其他明顯的問題. 這個方法更具可擴展性. 如果你有
四個團隊, 共用相同的白板並且一起進行每日站立會議, 我們可能不需要聽每個人報告,
我們只要集中心力在白板中瓶頸的部份.
在 Scrum 中規定要有燃燒圖
在 sprint 的燃燒圖, 以每日為基礎, 顯示目前這個迭代還剩餘多少工作
Y 軸的單位和 sprint 任務的單位相同. 通常是數小時或是數天(如果團隊把 backlog 的
項目拆解成任務的話)或是故事點數(如果團隊沒這樣做). 雖然這裡有許多不同的作法.
在 Scrum 中, sprint 的燃燒圖被使用來, 當作追蹤迭代進度的其中一個主要的工具.
有些團隊有使用發佈燃燒圖, 它也是使用相同的格式, 不過是從發佈的角度來看, 它通
常顯示在每次 sprint 後, 產品 backlog 中還剩餘多少故事點數.
燃燒圖主要的目的, 是當我們提前完成或是時程落後時, 能夠容易地儘早發現, 以便讓
我們能夠調適.

40. 40
在看板中, 並沒有規定要燃燒圖. 事實上, 沒有規定要任何特定類型的圖表. 但是, 他
們當然可以使用任何他們喜歡的圖表(包括燃燒圖)
這裡有一個累積流量圖表的範例. 這類的圖形清楚地顯示了你的流量有多順暢, 以及
WIP 如何影響你的前置時間.
下面是它的運作原理. 在看板中, 每天每個欄位的項目的總和, 會是 Y 軸上面的值. 所
以在第四天, 有九個項目在白板上. 在最下面有 1 個項目是屬於"Production", 有 1 個項
目是屬於"Test", 有 2 個項目是屬於"Dev", 有 5 個項目是屬於"backlog". 如果我們每
天繪製這些點並且把他們連接起來, 我們可以得到像上面這樣不錯的圖形. 水平和垂直
的箭頭說明了 WIP 和前置時間的關係.
水平的箭頭告訴我們, 在第 4 天被加到 backlog 的項目, 平均要花 6 天才會到達
"Production". 大約有一半的時間是在"Test". 我們可以知道如果限制在"Test"和
"Backlog" WIP 的值, 我們將會大大減少整個前置時間的值.
深藍色區域的斜度告訴我們速度的值(也就是, 每天多少項目被部署完成). 隨著時間的
演進, 我們可以看到較高的速度會減少前置時間, 而較高的 WIP 值則會增加前置時間.
大多數的組織想要把事情做得更快(= 減少前置時間). 不幸地, 許多人落入這樣的陷阱,
就是假設越多人加入或超時工作會更快. 通常讓東西更快做好, 最有效的方法是消除流

41. 41
程上的障礙, 並且限制工作的量, 而不是去增加更多人或是更努力工作. 由於這樣類型
的圖表顯示了為什麼, 因此增加了團隊和管理階層能合作地更有效率的可能性.
如果我們能區分出排隊狀態(像是"wait for test")和處理中狀態(像是"testing"), 那將
會更清楚. 我們希望能完全地減少在 queue 中等待處理的項目數目, 累積流量圖表則能
夠為這件事情提供適當的刺激.

42. 42
15. Scrum 白板 v.s 看板白板 - 一個較
簡易的範例
在 Scrum 中, sprint backlog 只是全貌中的一部份 - 這部份顯示團隊在目前這個 spint
中正在進行什麼. 其它部份是在產品的 backlog 中 - 產品負責人打算在未來 sprints 要
完成的項目清單.
產品負責人可以看得到, 但是不能碰觸 sprint backlog. 他可以在任何他喜歡的時間修
改產品 backlog, 但是這個改變在下個 sprint 才會生效(也就是, 不會影響目前正在進行
的工作).
當 sprint 結束, 團隊會"交付可能出貨的程式"給產品負責人. 所以團隊完成這個 sprint,
然後進行 sprint 檢視, 以及展示功能 A, B, C 和 D 給產品負責人. 產品負責人現在能決
定是否要發行這個版本. 最後一部份 - 實際發行產品 - 通常沒有包含在 sprint 裡面,
因此不會在 sprint backlog 中看到.
反之, 在這種情況下, 看板的白板可能看起來是這樣:

43. 43
現在整個流程是在同一個白板上 - 我們不只看一個 Scrum 團隊在一個迭代中在做什麼
在上面的例子, "Backlog"欄位只是個普通的願望清單, 並沒有特定的順序. 在
"Selected" 欄位裡面的是高優先順序的項目, 並且有限制是 2 個. 所以在任何時間點
可能只有 2 個高優先順序的項目. 每當團隊準備好開始處理新的項目, 他們將從
"Selected"欄位中取出最優先的項目. 產品負責人可在任何他想要的時間, 改變
"Backlog"和"Selected"欄位的內容, 但不是其他欄位.
"Dev"欄位(分成兩個子欄位)顯示了哪些項目是目前正在開發, 並且限制是 3. 以網路的
術語來說, 看板的限制相當於是"頻寬", 而前置時間相當於是"ping"(或是反應時間)
為什麼我們把"Dev"欄位分成兩個子欄位"Ongoing"和"Done"? 這是讓線上的團隊
(production team)有機會知道什麼項目他們可以放到生產線上.
"Dev"限制是 3, 並且是由兩個子欄位來分享. 為什麼呢? 假設有兩個項目在"Done"欄
位:

44. 44
這意味著僅有一個項目在"Ongoing"欄位. 也意味著可能產能過剩, 開發人員可能想開
始處理一個項目, 但是因為看板的限制而不被允許. 這將給他們強烈的誘因去集中力
量, 幫忙把事情能推上生產線, 清除掉"Done"欄位內的項目, 以最大化整個流量. 這樣
的效果是好的, 並且循序漸進 - 更多的項目留在"Done", 將會使更少的項目是允許在
"Ongoing"欄位中被處理 - 將會幫助團隊集中在正確的事情上面.
單件流程
單件流程是一種"完美流程"的場景, 那裡只有一個項目在白板上流動, 沒有被陷在任何
一個序列中. 這意味著在任何時刻, 有人正在處理這個項目. 以下是白板在這種狀況下
可能如何運作:
在那個時間點, 項目 B 正在被開發, 而項目 A 將要被放到生產線上. 每當團隊準備好要
處理下個項目, 他們會詢問產品負責人那個最重要, 並且得到立即的反應. 如果這種理
想的狀況存在的話, 我們會擺脫"Backlog"和"Selected"這兩個欄位, 並且得到一個真正
短的前置時間.
Cory Ladas 說的很好: "理想的工作規劃流程, 應該提供團隊下一步最需要處理的事情,
不多也不少"
WIP 的限制是在防止事情變得不可控制. 因此, 如果事情進行的很順利, WIP 的限制可
以不用真的被使用.

45. 45
看板世界中的一天

46. 46

47. 47

48. 48
看板的白板必須看起來像這樣嗎?
不用, 上面的白板只是一個例子 !
唯一看板規定的是, 工作流程應該要被視覺化, WIP 的值應該被限定. 其目的是為整個
系統建立一個順暢的流程, 並減少前置時間. 所以你需要定期提出這樣的問題, 像是:
我們應該有哪個欄位?
每個欄位代表一個流程的狀態, 或者兩個工作流程狀態之間的序列(緩衝區). 從簡單的
地方開始著手, 然後添加需要的欄位
看板應該採取什麼限制呢?
當看板中"你的"欄位的限制已經達到時, 你會沒有事情可做, 因此開始找尋下游的瓶頸

49. 49
(也就是, 放在白板右邊的項目)並且幫助解決它. 如果沒有瓶頸, 這表示看板的限制可
能過低. 因為之所以會有這個限制的原因, 是為了減低加遽下游發生瓶頸的風險.
如果你發現許多項目待了一陣子, 都沒有被處理, 這個跡象表示看板的限制可能太高.
* 太低的看板限制 => 無所事事的人 => 不好生產力
* 過高的看板限制 => 被閒置的任務 => 很差的前置時間
看板的限制應該多嚴格?
許多團隊把它們視為是很嚴格的規則(也就是, 團隊不得超過限制); 有些團隊把它們視
為是指導方針或是討論的觸發點(意即, 違反看板限制是允許的. 但是應該根據某些具
體的原因來做出決定). 所以再一次強調, 這是取決於你. 我告訴過你, 看板不是非常有
規範的, 對嗎?

50. 50
16. Scrum 和看板比較的結論
類似的地方
- 都是精實和敏捷
- 都使用拉式排程
- 都有限制 WIP
- 都利用透明化來驅使流程的改進
- 都著重於盡早及經常交付可出貨的軟體
- 都是基於自我組織的團隊
- 都要求把工作拆解成更小的工作
- 在兩者中, 發佈計畫是根據 資料(速度/前置時間)來持續優化
不同的地方
Scrum 看板
規定要有時間盒限制的迭代 有時間盒的迭代不一定需要. 規劃,
發佈, 和流程改進可以有不同的節奏.
可以是事件驅動, 而不用有時間盒限
制
團隊承諾要在這個迭代中要完成特定
數量的工作
承諾不一定需要
在規劃和流程改進時, 利用速度當作
的預設度量方法
使用前置時間當作規劃和流程改進的
基本度量
規定要有跨功能的團隊 跨功能團隊不一定需要. 專家小組是
允許的
項目必須能被拆解, 好讓他們能在一
個 sprint 中被完成
沒有規定要特定大小的項目
規定要有燃燒圖 沒有規定要特定型態的圖表
間接地限制了 WIP (套用在每次的
sprint 上)
直接規定 WIP 的限制(套用在每個流
程的狀態上)

51. 51
規定要做估算 估算不一定需要
不能在正在進行中的迭代增加需求項
目
只要產能允許的話, 可以增加新的項
目
Sprint backlog 是由某個特定的團隊
所擁有
看板的白板可以讓多個團隊或是個人
共用
規定要有 3 個角色(產品負責人
/Scrum master/團隊)
沒有規定任何角色
Scrum 白板的內容在每次 sprint 都被
重設
看板的白板內容是持續存在的
規定要有一個排好優先順序的產品
backlog
優先順序不一定需要
就是這樣, 現在你知道他們的差別了
但是, 還沒有結束, 現在好戲正要上場! 把鞋子穿好, 現在要和 Mattias 跳進壕溝中, 實
際看看到底它是怎樣!

52. 52
第二部份 - 個案研究
在真實生活中的看板
這是一個我們如何學習使用看板去進行改善的故事. 當我們一開始時, 並沒有太多資
料. 這一次, 連博學的 Google 都無法提供我們任何東西. 今日, 看板成功地不斷演進,
並且成為一個新興的知識體. 我強烈地推薦去看一下 David Anderson 所做的事情, 例
如'服務的類別'. 所以這裡第一次(也是最後一次)聲明(承諾!), 不論你使用哪個解決方案,
要確認他們有解決你特定的問題. 到此, 這部份已經介紹完. 讓我們繼續接著下去, 所
以, 以下是我們的故事.
/Mattias Skarin

53. 53
17. 技術營運的本質
如果你曾經 24X7 待命, 你對於管理一個上線環境所要負的責任, 會有很多的想法. 你
被期待在半夜中要處理狀況, 不管你是不是問題的來源. 因為沒有人知道, 這就是為什
麼他們要打電話給你. 這是非常具挑戰性的, 因為你沒有建立過這些硬體, 驅動程式,
作業系統或是客製化的軟體. 因此對於以下這些事情, 你所能做的選擇非常的少: 縮小
問題, 限制影響範圍, 儲存能夠重建問題的證據, 並等待造成這些麻煩的負責人, 重現
及解決問題.
所以能夠快速和準確反應和解決問題, 將會是重要的關鍵.

54. 54
18. 究竟為什麼要改變呢?
在 2008 年, 我們其中一個的客戶, 來自北歐的遊戲開發公司, 經歷了一連串的流程改
善. 其中包含了逐漸推廣 Scrum 到開發部門, 以及一點一滴排除障礙好讓開發團隊能
交付軟體. 當軟體開始運作, 處理的量增加, 這時候壓力會到下游去, 也就是技術營運
部門身上. 以前, 他們只是在旁邊看, 現在他們逐漸開始加入, 變成開發流程中積極的
一份子.
圖 1. 技術營運部門包含三個團隊: 資料庫工程人員(DBA), 系統管理和二線支援
因此, 幫助開發團隊是不購的. 如果我們一直只集中於開發團隊, 這將會導致延誤技術
營運部門, 對於關鍵基礎設施的改善. 所以在兩邊的改進都是需要的.
此外, 開發團隊的進行, 經理逐漸地被要求幫忙分析和回饋意見. 這意味著他們有較少
的時間, 可以及時設定工作的優先順序以及解決問題. 管理團隊意識到, 他們需要在局
勢不可收拾前採取行動.

55. 55
19. 我們從哪裡開始呢?
一個好的開始是藉由詢問開發團隊, 誰是技術營運部門的顧客?
開發人員對營運部門的想法
我問過:"當你想到"營運部門", 你會想到的三件有關他們的事是什麼?" 最常見的答案
是:
"多樣化知識"
"當談到基礎建設時非常厲害"
"他們想幫忙, 但實際上很難幫得上
忙”
"專案都花很長的時間"
"他們的工作流程系統很討厭"
"這些人是在做什麼?"
"需要許多電子郵件去做些簡單的事
情"
"很難去接觸"
總之, 這是開發人員對營運部門的想法. 現在, 讓我們比較營運部門對開發人員的想
法...
營運部門對開發人員的想法

56. 56
"為什麼你們不利用現有平台的優點?"
"不要把發佈的工作變得十分複雜!"
"因為你們品質不好, 我們被你害慘了!"
"他們應該改變" - 這是雙方爭論時共同的主題. 如果過去我們在解決這些問題有些摩
擦, 明顯地, 這樣的心態現在需要改變. 從正面來看: 前面"當談到基礎建設時非常厲害
"(表示相信其核心競爭能力)這句話, 會使我相信"我們和他們"這種心態可以修正, 如果
我們能建立正確工作狀態的話. 消除過於繁重的工作, 並且著重於品質, 這會是一個可
行的作法.

57. 57
20. 開始行動
所以我們需要開始行動, 但是我們要從哪裡開始呢? 唯一我們確定的事情是: 我們不會
在原地踏步
我的背景是開發人員, 所以我確定我只知道一些有關營運部門的特性, 我不是要"橫衝
直撞和一開始就改變一些事情", 我需要一個較不會反抗的方法, 可以教導我們一些相
關的事情, 和放棄一些無關的事情, 並且很容易去學習.
有一些候選的項目:
1. Scrum - 這是開發團隊已經執行不錯的方法
2. 看板 - 很新&尚未經過考驗, 但是很適合去補足精實原則所缺乏的.
和管理階層討論後, 看板和精實原則看起來和我們想解決的問題相匹配. 從他們的觀點
看來, sprint 並沒有很符合. 因為我們是以每天為基礎, 來進行優先順序的排定, 所以
看板是個合理的出發點. 即使對我們來說, 它是一個全新的事物.

58. 58
21. 團隊開始運作
我們如何讓團隊開始運作呢? 並沒有任何手冊說要如何展開, 若是做錯將會有很大的風
險. 我們面對的是一個生產平台和高度專業化的人, 這些人是很難被取代的. 不要不但
沒有改善, 反而導致他們因此而相互疏離, 這將會是一個很糟的主意.
* 我們應該開始就好? 等到有問題就承擔後果?
* 或者先有個研討會
對我們來說很明顯 - 先做研討會對嗎? 但是要如何做呢? 讓整個技術營運的團隊都
去參加研討會是一個挑戰(如果有人打電話來, 誰要去回呢?). 最後, 我們決定做一個半
天的研討會, 讓它保持簡單, 並且以實作為主.
研討會
研討會的其中一個好處是, 它幫助讓我們的問題及早出現. 它提供了一個高度信任的環
境, 任何影響可以和團隊成員直接討論. 我的意思是讓我們面對現實 - 不是每個人都
改變目前工作方式很有熱誠, 但是大部分團隊成員是願意去嘗試. 我們執行了一個研討
會來展示最重要的原則, 並且進行了小規模的看板模擬.
在研討會結束時, 我們利用了"first of five" 來表決, 是否團隊願意在現實生活中去實
驗它. 沒有人反對這件事, 所以我們就繼續來進行了.
22. 解決利益關係人

59. 59
利益關係人會受到看板執行的影響, 這件事情是可能的. 然而這樣的改變會變得更好 -
它意味著團隊會開始拒絕他們不能完成的工作, 開始為了品質而行動, 並且把優先順序
地的項目從團隊的 backlog 中移除. 儘管如此, 做之前先有個討論, 會是一個好的作法.
最有關聯的利益關係人, 是第一線的支援和部門經理. 因為他們有參與研討會, 他們對
於繼續下去有著正面的看法, 同樣地, 開發團隊也有相同的想法(不管怎樣, 會或多或少
期待有改善). 但是對於這個團隊, 支援團隊, 事情變得不一樣. 他們最大的問題是, 他
們的工作負荷量太大. 他們也需要處理客戶的問題, 因為公司有承諾要去回應所有的問
題. 如果我們要實施看板和開始強迫 WIP 限制的話, 現在這種狀況很可能會改變.
因此, 我們到關鍵的利益關係人的地方, 介紹我們的意圖, 預期的利益, 以及可能的結
果. 讓我感到欣慰的是, 我們的想法普遍地受到歡迎,甚至有些人評論是"如果我們最後
能這些問題長眠, 那是多棒啊".

60. 60
23. 建構第一次的白板
製作價值溪流圖(Value Stream map), 是一個很好的方式, 來開始建構看板的白板. 基
本上, 它是一個視覺化的價值鏈, 對於整個系統的工作狀態, 流程和時間(週期時間), 提
供了詳細的洞察.
但是, 我們開始的比較簡單, 由經理們一起畫在白紙上, 當做一份簡單的白板. 檢視幾
次過後我們開始行動. 在這個階段, 有些問題讓人感到不安, 包含:
* 我們有哪些型態的工作?
* 誰處理它?
* 我們需要對於不同型態的工作, 都採用共同責任制嗎?
* 對於某些專業技能工作, 共同的責任制要如何處理?
因為不同型態的工作有不同的服務層級協議(service levels agreements), 它讓我們很
自然地, 讓每個團隊控制他們自己白板的設計, 他們提出自己的欄位和列數.
下一個重大的決定是, 是否要對不同種類的工作使用共同責任制. "我們應該讓團隊固
定一部分的人處理直接的問題(反應性的工作), 而團隊剩下的人著重於專案嗎(主動性的
工作)?" 後來我們決定先嘗試共同責任制. 一個關鍵的原因是, 我們認為自我組織和團
隊成員的成長, 對於要持續成長是不可或缺的. 不過這個決策的缺點是可能會造成每個
人的不和或分裂, 但是這是我們能想到一開始時最好的作法. 當我們在進行研討會時,
團隊實際上已經開始自我組織地去解決問題. 他們讓一個人去處理眼前的需求, 而其他
人則處理更大的問題.

61. 61
第一個看板的模型
底下是我們看板的基本模型. 請注意, 團隊決定讓項目由下網上流動(像水中的泡泡一
樣), 而不是比較典型的由左至右.
圖 2. 這是第一個看板的模型. 優先順序是由左至右, 流動是由下往上. 正在處理的項
目在"Work in progess"這列中, 加總所有工作項目可以得到(用紅色圈起來的地方). 模
型的製作是有受到 Linda Cook 她的經驗的影響.
圖 3. 系統管理團隊的第一個 Kanban 白板.
使用到的列
工作流程的狀態 (列) 我們如何定義它

62. 62
Backlog 經理決定需要做的故事
Ready for WIP 故事已經被評估好. 並且被拆解成任務, 最大的大
小是 8 小時.
Workinprogress 這列有 WIP 的限制. 我們一開始是 2 X 團隊大小
- 1 (1 使指處理合作事宜的人). 所以, 4 個人的團
隊, WIP 的限制是 7
Done 可以被使用者執行的項目
使用到的欄位
工作的種類 我們如何定義它
Release 正在幫助開發團隊發行軟體
Support 從其他團隊來的較小的需求
Unplanned 需要被處理的一些無法預期的工作, 但是還沒有明
確的負責人. 例如小型的基礎設施改善
Project A 較大的高科技專案. 例如: 改變開發用環境的硬體
Project B 另一個較大的專案
並非所有 Kanban 的白板看起來都一樣. 但是一開始都是從簡單的草圖出發, 然後不斷
的演進.

63. 63
24. 設定第一次的 WIP 限制
我們第一次正在處理的工作項目(WIP)限制是寬鬆的. 我們的理由是因為藉由視覺化的
流程, 我們可以查看並體會到有什麼問題發生. 此外不可能一開始, 我們就能夠猜出最
正確的限制. 隨著時間的推移, 每當我們發現好的理由時, 我們就可以調整 WIP 的限
制值(我們要做的只是在白板上指明出來).
我們使用的第一個 WIP 限制是用 2n-1(n=團隊成員的個數, -1 則是鼓勵要做合作事宜的
工作). 為什麼是這樣呢? 簡單地說, 我們沒有更好的主意. 並且這樣開始看起來也沒有
爭議. 對於任何想把工作丟給團隊的人, 這個公式提供了一個簡單, 並且合乎邏輯的解
釋: "...當我們考慮到每個團隊成員最多可以同時處理兩件工作: 一件正在處理, 一件在
等待. 那為什麼你會期待他們能夠承擔更多呢?" 回過頭來看, 任何寬鬆的限制在一開
始都會可行. 但藉由監控 Kanban 白板, 在沿路上可以很容易指出正確的限制為何.
圖 4. 我們如何應用 WIP 到 DBA 和系統管理的團隊, 所有工作種類只有一種限制.
我們觀察到, 對故事點數定義 WIP 的限制是沒有用的, 因為這太難去追蹤. 唯一夠簡
單去追蹤的作法, 就是單純地計算項目的個數(=同時執行的任務).

64. 64
25. 實踐 WIP 的限制
在理論上, 遵守 WIP 的限制聽起來很簡單. 但在實務上, 實踐 WIP 的限制是一件棘手
的事情. 它意味著在某些階段需要說"不". 我們有嚐試過各種方法來應對.
在白板上討論
如果有違背的狀況發生, 我們會帶利益關係人到白板面前, 詢問什麼是他們想要實現的
目標. 一開始, 之所以違背最常見的理由, 只是因為經驗的問題. 在某些情況下, 我們
發現對於優先順序有不同的看法. 一個典型的案例, 是將一個專家小組的成員, 限制在
只處理某個特定領域的問題. 這是唯一我們有遇到摩擦的時機點. 在大部分的時間, 問
題都可以被找到, 並且在白板前被討論.
分配超出的部份
如果說"不"有點太對立, 或者不容易去刪除項目, 我們可以在 WIP 限制超過時, 把優先
順序低的項目移到白板上"超出"的區域. 有兩個規則可以適用於超出的任務:
1. 他們並沒有被遺忘, 每當我們有時間, 我們就會處理它們
2. 如果我們要放棄它們, 你將會被告知.
只要兩個星期後, 就會很明顯地超過的項目不會被處理到, 所以和支援團隊的經理協調
後, 最終它們會被刪除.

65. 65
圖 5. 有關支援團隊的白板草圖; 超出的部分在最右邊.

66. 66
26. 那些任務要放在白板上?
我們早就決定, 不要把團隊所有所做的工作放在白板上. 監督像打電話或是倒咖啡這些
事情, 會把 Kanban 變成一個管理的怪物. 在這裡我們是要去解決問題, 而不是要去產
生問題, 對不對? 所以我們決定只把大於 1 小時的任務放到白板中, 而小於一小時的視
為是"白噪音(white noise)". 這一小時的限制, 運作的相當不錯, 是這裡少數沒有改變
的事情.
圖 6. 我們一開始假設總共的生產力大部分是消耗在兩類型的工作, 大的(與專案有關)
和小的(與支援有關)工作. 追蹤專案的速度, 可以給我們交貨日期一個指示, 如果這是
必要的話. "白噪音(white noise)"(較小的支援工作 < 1 小時, 倒咖啡, 幫助同事)的工作
通常會預期隨時都會有.

67. 67
27. 如何評估?
這是一個不斷發展的議題, 當然一定會有一個以上的作法:
# 定期評估
# 當有需要時進行評估
# 使用理想天數評估(ideal days estimates)/故事點數
# 評估是不準確的, 使用 T-shirt size(小, 中, 大)
# 不要評估, 或者證明有延遲的成本才評估它.
受到 Scrum 輕微的影響(畢竟這是我們一開始所會的), 我們決定首先要使用故事點數.
但是實務上, 團隊把故事點數視為和工時(man-hours)相等(這會讓他們感覺到更自然).
在一開始時, 所有的故事都要被評估. 隨著時間的推移, 經理們會學習到, 如果他們讓
同時進行的專案個數變少, 他們將不會使利益關係人能等待下去. 他們也會學習到, 如
果突然改變, 他們可以重新改變優先順序, 來解決問題.
對於專案交付時間的需求不再會是大的問題. 這些 lead manager 會停止要求預先的估
計, 只有當他們害怕, 會讓有些人因此而等待時, 才會進行估計.
之前有一次, 有位經理, 強調是在電話中, 答應專案的交付是在"這個禮拜結束的時候".
可是由 Kanban 白板中的內容, 它很容易估算出進度(計算被完成的故事). 目前推斷出
一星期後大約完成了 25%, 因此還需要額外的 3 個禮拜. 面對這一個事實, 經理改變了
專案的優先順序, 停止了同時在進行的工作, 好讓交付日期變得比較可能.
評估的大小代表什麼意思呢? 是前置時間, 或是工作時間
呢?
我們的故事點數所反映的是工作時間, 也就是要花多久時間不間斷的工作, 才能完成我
們所想要的故事. 所以它不是前置時間(或者是日曆時間, 或者多少等待的小時). 藉由
測量每週有多少故事點數達到"做完"的地步(速度), 我們可以推論出前置時間.

68. 68
對於每個新的故事, 我們只評估一次. 在執行的過程中, 我們沒有修改故事的評估. 這
會讓我們減少團隊在評估所花的時間.

69. 69
28. 因此, 我們是怎樣真的在運作呢?
Kanban 真的是非常不受限制, 你可以把它運用在各種類型的事情上. 你可以讓團隊根
據事先預定的活動來運作; 或者你可以根據是否有足夠的動力, 來選擇自己要做的活
動.
圖 7 當有 3 個任務放到 backlog 中, 這將會觸發一個規劃/評估的事件發生
我們選擇把兩個經常性的事件列入計畫:
* 每日站立 - 和團隊站在白板面前去處理問題. 並幫助其他團隊成員的任務, 建立
“split vision view”.
* 每週的迭代計畫, 是為了規劃和持續改進的目的.

70. 70
這對我們來說是有效的
每日站立
每日站立會議和 daily Scrum 和雷同的. 它是在和所有團隊(開發, 測試, 營運)開完
"Scrum of Scrums"會議後舉行的. "Scrum of Scrums" 會帶給 Kanban 團隊重要的訊
息, 像是哪些問題應該要先被處理, 或者哪個開發團隊現在是在痛苦的時刻. 在一開始
時, 經理們會經常參加每日站立會議, 提出一些解決方案和優先順序的決定. 經過一段
時間, 當團隊在自我組織方面成長的不錯, 經理們會較少參加會議(但是會在不遠處, 如
果需要的話)
迭代規劃
每週我們舉行迭代規劃會議一次. 並且我們在每週同一時間舉行舉行, 這是因為我們發
現如果我們沒有把它計算在內, 這段時間可能被其它項目所佔用. 並且我們要求更多團
隊交談. 典型的議程會像是:
* 更新圖表和白板. (已經做完的專案會移到"Wall of Done"的區域)

71. 71
* 查詢上週的內容, 看看發生了什麼事? 為什麼會這樣?怎樣做才能改善呢?
* 重新調整 WIP 限制值(如果需要的話)
* 任務分解和新的專案的評估(如果有需要它的話)
基本上, 迭代計畫是一個結合評估和持續改進的脈動. 小型到中型的問題, 可經由第一
線經理在現場解決. 但是有些基本架構有關的問題, 是個很艱難的考驗. 為了處理這些
問題, 我們讓團隊有這樣的能力, 可以指派兩個"團隊的障礙"給他們的經理
其中的規則是
1. 經理可以在任何時間點處理這兩個事情
2. 如果已經兩個了, 只要你移掉較不重要的一個, 你便可以增加一個新的
3. 團隊決定這個問題是否被解決
這是一個很正面的改變. 忽然間, 團隊能知道經理正在幫助他們, 即使是很困難的問題.
他們可以指著問題問說"究竟這是怎麼回事?", 但他們不能因為有一個新的較高優先順
序的事情, 因而忘記或是拒絕處理.
這裡有個嚴重障礙的例子. 當營運團隊懷疑有個 bug 時, 營運團隊沒有從開發人員那邊
獲得他們所需要的幫助. 他們需要幫忙去指出系統哪個部份造成這個問題, 但是因為開
發人員忙碌於開發 sprint 中的新項目, 所以問題一直被堆放著. 無疑地, 營運團隊會認
為開發人員不夠關心品質的問題.

72. 72

73. 73
29. 找到一個可行的規劃概念
一個故事
我記得其中一個團隊的轉淚點. 在第二次的估算會議, 我和他們坐在一起. 團隊陷入一
個狀況, 他們不知道要如何估算. 他們有太多不知道, 所以整個估算陷入停頓. 與其介
入和接手, 我要求他們去改善流程已去找到更好的解法. 在他們經理的帶領之下, 他們
重拾挑戰, 並且開始設計自己的解決方案. 這個事件是重要的轉淚點, 一個重要的勝利
讓他們建立團隊的信心. 在此之後, 他們開始發展的很迅速, 我們已經讓他們走出自己
的路.
兩個月後, 在回顧會議後, 他們的經理來找我. 他說"我有一個問題", 指著他團隊
Kanban 的白板說: "我們沒有真正的問題, 我們該怎麼辦?"
再造計劃
規劃撲克牌評估會議, 邀請無法和營運團隊合作很好的所有團隊成員, 其理由如下:
1. 知識在團隊中並沒有很均勻被傳播
2. 多數情況下只有一人發言
3. 團隊成員都是在處裡他們的緊急事項
但是, 根據實驗, 團隊分別提出了兩種不同的估計流程. 每一種對各自的團隊都運作的
不錯.

74. 74
方法 1 - 交換和審查
* 對於每個專案/故事, 指派一個資深 + 資淺的一組成員去評估它. (也就是, 一個是已
經對這個特定的故事知道的非常詳細, 而另一個則不知道), 這將有助於傳播知識.
* 其餘團隊成員選擇他們想要幫助評估的故事(但是每個故事最多限制四個人, 以保持
討論的有效性)
* 每個評估地小組將他們的故事作任務的拆解, 如果需要的話, 然後評估它.
* 接著小組交換故事, 並且審查彼此的工作(每組有一個人"被留下", 以解釋他們這組的
工作給審查的人聽)
* 完成
通常, 整個迭代規劃會議大約要花 45 分鐘, 並且在整個會議過程中維持很高的幹勁.
當故事被交換並由新的一組人審查, 通常會有 1-2 個調整會發生.
方法 2 - 由資深批准大方向, 然後再評估
在規劃前, 兩個資深的團隊人員對故事/專案進行大方向的審查. 他們分析架構上的解
決方案, 並且為問題決定出一個解法. 一旦解決, 團隊將進來, 採用所提議的解法把故
事分解成任務, 來當做出發點.

75. 75
圖 8. 在迭代規劃會議中, 拆解的任務被另一個團隊的同事審查

76. 76
30. 要度量什麼?
很多事情事可能可以被度量的 - 迭代時間, 速度, 序列, 燃燒狀況... 重要的問題是哪
個數據是可以被用來改進流程. 我的建議是去做實驗, 然後看哪個適合你. 我們了解到,
燃燒圖對於小於四週的專案來說是殺雞用牛刀. 基本的進展狀況是藉由查看 Kanban 的
白板來判斷(有多少故事在白板上, 以及有多少已經做完)
我們從度量"每種工作種類的速度"和"序列長度"開始. "每種工作種類的速度"是很容易
去度量. "序列長度"則是一個非常好的領先指標, 因為她們可以立即被指出(一但你知道
去哪裡去找到它們)

77. 77
圖 9. 瓶頸和機會. 紅色的區域顯示了怎樣的序列被建立, 會導致一個測試的瓶頸. 在
"Support"欄位的 backlog 內沒有任何項目, 指出了對於新的 support 工作沒有任何的
等待時間. 對於高水準的服務來說, 這是一個很好的跡象.
我們沒有使用累積的流程圖(cumulative flow diagrams), 但是那也是很有趣的資料.
我們沒有使用累積的流程圖是因為 Kanban 的白板和速度圖表已經給我們足夠的資訊,
至少在我們早期階段的成熟度是這樣子的. 在前六個月, 瓶頸, 不穩定和過分勞累仍然
容易被找到,並且解決這些事情已經讓我們很忙碌了.

78. 78
31. 事情如何開始改變
在導入 Kanban 三個月後, 系統管理團隊在 IT 的部門中, 被管理階層評為"表現最好的
團隊". 同時, 系統管理團隊在公司回顧會議中被評選為, 前三個"建設性經驗"中的其中
一個. 公司的回顧會議是一個全公司性的事件, 每六週舉行一次. 這是團隊第一次出現
在前三名的清單中! 誰想得到三個月前, 團隊曾處於瓶頸狀態, 並且很多人還一直在抱
怨.
服務的品質已經增加了, 因此, 這是怎麼發生的?
這不可或缺的關頭是當大家開始通力合作, 經理提供了一個明確的重點, 並且保護團隊
免於其它不屬於這裡工作的打擾, 因此團隊可以確保品質和交付期限. 我們大約花了三
到四個月才出現這樣的狀況, 可是之後就暢通無阻. 不過不可能所有問題都消失了(那
將會使我們都失去工作, 對吧??) - 我們現在面臨了新的挑戰: "我們如何讓團隊保持動
力去改進(當他們已經不再是瓶頸之後)?"
在自我組織中一個重要的部份是, 導入"每個團隊有一個營運的聯絡人"的概念. 這意味
著每個開發團隊在營運團隊中, 有一個他們屬於他們自己的聯絡人. 藉由允許營運團隊
成員自己組織他們自己的工作, 預防過度操勞, 並且持續改進, Kanban 讓這一切變成可
能. 在此之前, 隨意一個人從序列中抽出一個工作, 盡他自己能力去解決它, 然後再處
理下一個. 若是有任何誤解, 則意味一切需要重頭開始, 重新提出一個新的需求. 當一
對一的觀念被部署後, 在不良的投入以及品質問題威脅到系統時, 支援的團隊會意外地
有機會迅速做出反應
經過一段時間, 自訂的溝通協定逐漸形成. 營運人員開始使用即時通訊和他們交情良好
的開發人員交談, 而用 email 跟哪些用寫會比用說好的人溝通. 如果要以最快的方式來
解決問題, 則會使用電話.
改變之前

79. 79
圖 10. 改變之前: 第一線經理人是團隊主要的連絡人. 任何重要的事情都需要經過他
才能完成. 較小的問題, 通常程式開發人員的問題, 是經由問題追蹤系統來記錄. 很少
有人與人直接互動.
改變之後
圖 11. 改變之後: "每個團隊有一個營運的聯絡人"的概念被部署. 開發團隊直接和營運
團隊中的規劃好的聯絡人對話. 許多人對人的互動. 營運團隊成員會利用 Kanban 白板
去自我組織他們的工作. 經理可以轉移焦點到大型專案的優先順序, 並且在當他們遇到
困難時提供支援

80. 80
那會怎樣影響團隊的表現?
圖 12. 每週度量故事點數"完成"的量, 來得到"Total velocity"和"project velocity".
"Total velocity"的值是所有行加起來的總和, 而"project velocity"則代表是"所有專案
". (較大型的工作, 例如升級硬體平台). 有兩個下降是關於 1)這個禮拜幾乎所有團隊成
員都在旅行, 以及 2)開發團隊有一個主要的版本發行
因此, 團隊表現出整體的積極趨勢. 同時團隊大量利用撘檔編程來達到知識的分享.
圖 13. "Total velocity"和"Small support tasks". 中間這個下降是對應到聖誕節的時
候.

81. 81
雖然差異性很大, 但是"Total velocity"的趨勢是向上的. 差異性的大小激發了團隊去監
控"Small support tasks"的個數(這些任務通常太小, 以至於沒有把他們放在 kanban 的
白板上). 正如你所看到的, 這圖表指出了"Small support tasks"的個數和"Total
velocity", 有明確的逆相關關係.
支援團隊比其他兩個團隊還要慢開始使用 Kanban, 所以我們還沒有很多可靠的數據.
成熟度的成長
當我們一開始時, 要發現問題的地方是非常容易, 但是要找出能改進的最佳機會卻是很
難. Kanban 白板給我們一個前所未有的透明度. 不止更容易指出問題所在, 並且重要的
問題會被在流程, 變異和序列中提到. 我們開始把序列視為一個工具來發現問題. 在使
用 Kanban 的四個月後, 經理們已經能找出傷害他們團隊的變異來源.
當團隊演化到由個人到成為自我組織的單位, 管理人員意識到, 她們正面臨著一連串新
的領導挑戰. 她們需要處理更多人的問題 - 處理抱怨, 定義共同的目標, 化解衝突, 以
及談判協議. 這並不是無痛的轉移 - 他們公開地表示, 學習這些需要技巧和精力, 但是
他們願意承擔這樣的挑戰和最終成為更好的領導人.

82. 82
32. 一般的經驗教訓
隨著工作的進展緩慢, 約制開始出現.
所有的團隊一開始, 都是採用相當一般化的 WIP 現制. 在那個時候, 大部分的精力都
花費在試圖去建立流程, 以及確保該組織能獲得它所需要的支援.
起初, 經理們希望有很多專案可以同時進行. 但是在幾週內, 很明顯地發現到, 他們只
能快速看一下白板上, 還沒被處理的優先順序低的項目, 可是卻沒有額外的能力來處理
優先順序較低的專案. 因此, 這將會促使經理們減少每個團隊的專案個數.
經過一段時間之後, 流程對於優先順序較高的工作變得比較穩定, 所以我們開始緊縮
WIP 的限制, 將正在進行中的專案個數(欄位個數)由三個, 兩個變到一個. 當這件事發
生後, 團隊之外的約制開始浮現. 團隊成員開始回報說, 他們沒有及時得到其他人的幫
助, 所以經理們把注意力轉換到處理這樣的事情.
另外其它的問題, 是其他團隊的事情來危害到團隊的效能. 當進來的項目持續變動時,
這將會很難保持流程的平穩, 以及加速流程的進行.
這些問題在我們開始行動前並不明顯. 這個問題相當於是"什麼問題我們應該要先處理
", 並且要對此達成共識. 在 Kanban 白板上, 每個人可以看見某個特定的問題如何影響
工作流暢度, 可讓我們容易去聚集力量, 來處理橫跨組織邊界的問題.

83. 83
白板將會持續演進, 不要讓版面設計都不變
所有的 Kanban 白板的內容會持續被改變. 在團隊找出真正可行的方法前, 通常都要花
兩到三次重新設計. 所以在第一次版面設計時, 會花很多時間來規劃, 以確保之後能很
容易重新安排白板的內容. 我們利用黑色的膠布來設計版面, 這些都是很容易重新安
排, 並且在牆上或是白板上都適用. 另一種我所看到的方法, 是利用粗的麥克筆來繪製
白板的線條(但是要確保他們是可以被擦掉的!?)
下面是一個版面設計優化的典型例子. 在一開始時, 優線順序通常容易被變, 因此為了
避免把整行的內容來來回回的移動, 團隊會在每一行上面放上其優先順序的號碼.
圖 14. 早期 Kanban 白板用便利貼來表示目前的優先順序
不要害怕嘗試和失敗
從這次的冒險活動中, 我所獲得的經驗是學無止境. 我們當初會失敗是因為我們認為會
有個終點, 但是事實上它是個無窮止盡的實驗與學習. 若是從未失敗, 則代表沒有學習.

84. 84
在整個過程中, 我們遭遇到了很多次的失敗(不好的白板設計, 不準確的評估, 和多餘的
burndown 圖等等..) - 但是每次我們都有學到一些全新並且重要的東西. 所以如果我們
停止去嘗試, 那我們如何能學習到新的東西呢?
Kanban 的成功, 現在已經激勵了管理團隊和 Scrum 開發團隊, 開始去嘗試使用 Kanban
的白板. 或許這本書能有幫助!

85. 85
最後的賣點
由回顧開始!
很多選擇和事情需要思考吧? 希望這本書能有助於釐清一些困惑. 至少它對我們來說是
可行的 :o)
如果你有興趣想改變和改進你的流程, 讓我們幫你做出決定吧. 如果你沒有定期執行回
顧會議, 現在就開始吧! 並且確定它能帶來真正的變化. 如果有必要的話, 找外面的引
導員來幫忙.
一但你能夠進行有效的回顧會議, 你已經開始上路了, 依照你的狀況逐步產生出正確的
流程 - 無論它是根據 Scrum, XP, Kanban, 或是這些的組合, 或者是其他.
永不停止嘗試
Kanbam 或是 Scrum 都不是我們的目標, 不斷學習才是. 對於軟體來說, 其中一件最重
要的事情是快速回饋迴路, 這是學習的關鍵. 因此, 要善用這樣的回饋迴路! 懷疑任何
事情, 嘗試, 遭遇失敗, 學習, 然後再嘗試一次. 不用擔心會一開始就做正確, 因為這是
不可能. 只要有開始的地方, 之後便從哪裡不斷的演進.
唯一真正的失敗是沒有從失敗中學習到教訓.
但是, 嘿, 你可以從失敗中學習的東西實在太多.
祝你好運, 並且享受你的旅程
/Henrik & Mattias, 斯德哥爾摩 2009-06-24

86. 86
H: 這就是我們所得到的所有經驗嗎?
M: 我想是的. 讓我們到此為止吧.
H: 或許我們應該告訴他們我們是誰?
M: 好主意. 如果我們要把它弄成讓我們看起來像是好好先生, 也許我們需要找顧問公
司來幫忙.
H: 就讓我們就這樣做吧! 然後我們就可以收手了.
M: 是的, 我們還有其他工作要做, 讀者也是.
H: 事實上, 我的假期現在剛剛開始 :o)
M: 嘿, 不要刺激我了

87. 87
關於作者
Henrik Kniberg 和 Mattias Skarin 是位於斯德哥爾摩的 Crisp 這家公司的顧問. 他
們樂於幫助公司的技術和人員和在軟體開發方面取得成功. 並且他們已經讓數十家公
司, 把精益和敏捷原則能付諸實踐.
Henrik Kniberg
在過去十年中, Henrik 曾經擔任瑞典 3 家 IT 公司的 CTO, 幫助很多客
戶改善他們的流程. 他是一名 Certified Scrum Trainer, 經常和精益和敏
捷的先驅合作, 像是 Jeff Sutherland, Mary Poppendieck, 和 David
Anderson.
Henrik 的上一本書 “Scrum and XP from the Trenches”, 已經超過 150,000 人看過,
它是這個話題中最流行的書籍. 他曾經多次在國際研討會中獲得最佳講師.
Henrik 在東京長大, 現在和他老婆 Sophia 和 3 個小孩居住於斯德哥爾摩. 他在休閒
時間喜歡玩音樂和作曲, 並且在當地樂團中擔任貝斯和鍵盤手.
henrik.kniberg@crisp.se
http://blog.crisp.se/henrikkniberg
http://www.crisp.se/henrik.kniberg

88. 88
Mattias Skarin
Mattias 是一名精益教練, 幫助軟體公司享受精益和敏捷的好處. 他指導
的範圍涵蓋開發人員到管理階層全部. 他曾幫助一家遊戲開發公司, 把開
發週期從 24 個月縮短到 4 個月, 使得大家從新再建立對開發部門的信
任. 他也是看板最早期的先驅者之一.
身為創業者, 他曾經和他人經營過 2 家公司.
Mattias 擁有品質管理學的碩士學位. 並且在核心關鍵系統中擔任開發人員十年.
他居住於斯德哥爾摩, 喜歡搖滾樂, 跳舞, 賽車, 和滑雪.
mattias.skarin@crisp.se
http://blog.crisp.se/mattiasskarin
http://www.crisp.se/mattias.skarin