2015/03/23 出版
這本書是寫來供自己上看板方法課程用的教科書。過去我上課時都是採用看板之父David J. Anderson 所寫的《看板方法：科技企业渐进变革成功之道》這本Blue Print的簡字版作為教材(它是Amazon 2014 暢銷書)，現在終於有自己的教材了! 真是人生一大樂事。寫書的最大動機是因為看板之父的書(2010)內容沒有補充那些新增的資料，與其一直在做補充，不如自己辛苦一下了。
.
第一章寫的是精實軟體開發
看板方法隸屬於敏捷開發的精實Lean之下，但看板方法書裏頭卻沒有特別提到精實的原則，所以我在一開始就先來補足這一塊缺少的部分。首先簡述了一下Lean 的由來與敏捷軟體開發（Agile software development）的關係，然後就開始說明依據Mary and Tom Poppendieck 的名著《Lean Software Development An agile Toolkit》所整理出來的精實七原則。
- 消除浪費 Eliminate waste – 由識別浪費做起。
- 增強學習 Amplify learning – 如何表現的超越自身的能力的最佳方法就是學習。
- 盡量延持決策 Decide as late as possible – 盡量多思考清楚再作決策。
- 盡快交付 Deliver as fast as possible – 客戶需要。
- 授權團隊 Empower the team – 自主團隊擁有最佳的效能。
- 崁入完整性 Build integrity in – 在了解需求同時進行開發。
- 著眼整體 See the whole – 避免局部優化。
上面這七條原則，就是熟悉以後便可以受用不盡的「精實原則」。老實說，這樣的原則可以適用在所有的人類行為上頭(上ㄧ回問我精實lean要如何善加運用的人，是一位從事婚顧的專家，她覺得真的是好用極了)，是一種放之四海皆準的原則。我個人覺得是公司行號或組織團隊拿來醞釀企業文化的基礎規範。它們全部加起來只有31個字，卻宛如朱子家訓一般的終身受用。
.
》關於第二、三及第四章，足夠拿來做教學用了!
如果你要上一天8個小時的看板教學的話，這三章就擁有足夠的基礎資料了。第二章是簡介，第三章則是將相關的基本理論都納進來的一章，雖然是按步就班的描述，但資料繁多而比重也不均勻，一口氣都講完會有些個混亂，講師可以挑比較重要的部分做講解即可。第四章則是實作的開始，實作「看板牆」。
第二章看板方法 Kanban Method
- 解釋何謂看板方法: 是一種運用精實原則來控制流程的方法。它具有四個基本原則及六個實務。
- 為何要使用看板方法: 使用看板方法就是達到漸進式的敏捷改革之道。
- 哪些地方可以用到看板方法: 只要是有流程的地方就能適用，因為它是運用在流程管理和改進的一種高效能的方法。
第三章看板方法的六大核心實務(所有章節裏頭，東西最多，也是看起來最為雜亂的一章。)
建置看板方法的核心步驟，David J. Anderson 所寫的《看板方法：科技企业渐进变革成功之道》只描述了前三個步驟。後面三個則是後來才追加進來的。我把他們歸類為策略而非步驟。是你在實踐了前三個步驟之後，應該繼續完成的改善策略。
其中第一步是最重要的一步，「視覺化目前的工作流程」是讓自己能夠正視目前開發作業的流程步驟，這是作為接下來進行改善動作的基礎。這個動作我們稱之為繪製價值流程圖(Value stream mapping)，它是識別流程浪費的基礎，目的是在消除浪費之前，先行識別浪費的所在，才能對症下藥。但這裡僅僅是看板方法的第一步，因為我們在這裡只是先行識別目前的工作流程，最終的目的則是持續改善，追求最高產出。因此除了要消除浪費之外，一個大的前提是要能追求最高產能。所以必須對半成品數加以限制，而這是看板方法用來提升生產率的最佳方法。
繪製價值流程圖 VSM: Value Stream Mapping太重要了這裏我舉了三個例子:
- 範例一、BUG的修復作業流程圖示。
- 範例二、遊戲公司開發、上市作業流程圖示。
- 範例三、採用敏捷開發法SCRUM來運行ASP.NET的網頁開發流程。
這是開發團隊對照既有的工作流程到看板牆的重要步驟。如果換成談個人的工作效能的話，那就是個人的 To Do List 轉換到看板牆的作。
接下來；在描述半成品WIP的部分，借助了麥當勞的Drive Through取餐行為做了利特爾法則的第一次說明。然後談到看板方法處裡多工的方法，當然得責備一下「多工是不好的」Multitasking is evil，但是如何讓它更明確呢? 便是運用看板來清楚的區分工作渠道的方式。很快的進入「流程管理」的部分，目的在說明看板流程管理，追求平滑度，時效性，和良好的經濟成果，預測客戶的需求。
.
策略4、5、6是三個較抽象的部分，需要一些實戰經驗才能體會，如果你沒有實作的經驗，就把他們拿來做指導原則即可。
策略4 : 讓規則明確 Make policies explicit
從三個方向淺談了一下制定規則方法: 工作方式、遵循限制半成品的限制及為服務層級協議SLA設定明確的規範。
策略5 : 落實回饋循環 Implement feedback loops
由回饋的三個不同角色，說明它的內容:
- 來自團隊其他成員的回饋(這是普遍的團隊開發的浪費行為，始終忽略內部回櫃)。
- 來自接受你的工作人士的回饋。
- 來自客戶的回饋(外部回饋)。
策略6 : 由協作改善，經實驗演進 Improve collaboratively, evolve experimentally(using models and the scientific method)
說明看板方法是「漸進式的變革」evolutionary and incremental，而非一般敏捷開發法的「小增量的反覆運算方式」iterative and incremental。
持續改善所依據的科學方法:「休哈特循環」（Plan-Do-Check-Action， PDCA），一個四步的循環，來自愛德華.戴明博士。
.
第四章則是實作的開始，實作「看板牆」。
我們由實務開始，設計看板牆需要考量三個基本元素: 範圍(Scope)、工作項目粒度 (Granularity) 大小、工作項目狀態(States)。如果你採用的是電子看板的話，制式的設計通常會提供一些模板讓你套用，容易讓人忽略了這三個基本元素。所以理想的做法是先用草稿的方式設計你的看板牆，隨後再去找類似的模板迅速的改成自己的設計。完全套用看板模板總是會讓人有所遺漏的。
.
》應該用白板還是電子看板，如果用雲端是未來一切運作的基礎去思考的話，則電子看板是必然的選項，實體的看板牆反倒成了可有可無的選項。但這裡我想強調的是，不要忽略了「溝通」的效果，最佳的溝通方式依然是面對面站在白板前面的溝通方式，這樣子的溝通效率是不容忽視的。
.
有趣的SCRUM運作模式下的看板牆設計
使用看板一定要在SCRUM的運作模式下嗎? 答案是不用。
看板方法可以適用在傳統開發法與敏捷開發法之下，運作起來二者並沒有太大的差異。但在書裏頭我則一直偏向敏捷式的開發方式，原因很單純，因為我教授SCRUM課程，所以刻意的加入了「SCRUM運作模式下的看板牆設計」這一節。希望對已經在實行SCRUM的團隊能有所幫助。
.
SCRUM是一個絕佳的軟體開發架構，但它一直忽略了工作板的效能設計，所以長期以來大部分團隊始終是「To-do、Doing、Done」的形式在運做著，不但沒有與實際的工作流程相吻合，也沒能協助改善效能。許多人士的一個遺漏重點；就是始終沒有去設定WIP的上限。沒有設限WIP值就等同於沒有實行看板方法(這是David J. Anderson所強調的。而大部分的Scrum Master也都知道半成品WIP是什麼? 但就是沒勇氣嘗試，別忘了SCRUM的價值觀: 專注、尊重、承諾、勇氣、開放、誠實、授權與合作。拿出勇氣來嘗試吧!)。
.
第五章個人看板 Personal Kanban: 類專案管理
個人看板則是使用在個人或是小團隊用來提升效能的開發過程工具(這句話出自個人看板創始者Jim Benson)。尤其是軟體界有太多一人專案存在了。他無需跟其他程式設計人員合作，整個專案就自己一個人從頭做到尾，這一章是為他們而寫的。所以才有類專案、類文件這種四不像的東西。
.
「英雄再現」的時代 : 雲端運算對軟體開發的影響:「整合即是創造」
在雲端時代裡是一個「英雄再現」的時代。雲端的初期，諸事煩雜需要群策群力才足以建置這樣的雲端世界，但隨著雲端的逐漸發展成形，那些整體性的服務卻反而成為個人可以加以整合發揮的世界(我一度認為現在的軟體開發已經太複雜了，不太可能再有像早年的 DB3或是Clipper等一個人就做得出來的佳作，但雲端時代又有機會了)，因此我常鼓勵年輕工程師，未來十年將是一個「英雄再現」的時代。
過去我上敏捷開發課程時，經常被問到「一個人的專案管理」該怎麼運作呢? 答案是，就交給「看板方法」了。
所以就提出了類專案(Similar Project Management)的概念。也就是架構出一個看似完整又不是那麼在意它是否完整的專案管理過程。而那個可有可無的文件製作就稱之為類文件。
» 是可以再多花些精神更仔細的來探討這個「一個人的專案管理」他是一種未來會逐漸增多而無法避免的趨勢，在雲端時代裡是「英雄再現」的時代。就交給下一版本再來做補充吧!
.
這一章的重點在個人看板上頭，一個簡潔的個人看板製作。個人看板製作步驟如下:
步驟一、視覺化
- 建立你個人的價值流程(To do list)。
- 建立你的工作事項卡片(別忘了編排一下它們的優先順序)。
步驟二、設定WIP限額
步驟三、開始運行拖拉系統的動作(管理看板)。
.
第六章個人看板與生活讓生活與工作相得益彰(一個跟技術無關的章節)
談看板如何運用在個人身上。看板可以提升效能，不論是個人或是團隊或是企業。這一章純粹是為那些想提升個人工作效率的人士而寫的。在這一章裡面，沒有涉及任何開發方法純粹在談提升個人校能，由To do list 個人看板。強調的是「你想要的是什麼與你做了些什麼來達成它」。我參考了Jim Banson的分析作法。提出一些個自問:
透過個人看板的運作，你能看到:
- 你想要的是什麼? (What you want)
- 你做了些什麼? (What you do)
- 你是怎麼做到的? (How you do it)
- 你跟誰一起做的? (Who you do it with)
- 你完成了些什麼? (What you complete)
- 那些是你尚未完成的? (What you leave unfinished)
- 你做事情的速度如何? (How quickly you do things)
- 是什麼原因造成你的瓶頸? (What causes your bottlenecks)
- 是什麼時候?為了什麼造成拖延. (When and why you procrastinate)
- 是什麼事情會造成你著急. (When and why certain activities make you anxious)
- 你能承諾些什麼? (What you can promise)
- 什麼情形之下，你可以說不. (What you can say No to)
.
第七章預測未來 : 減少變異性，增加可預測度(談看板的好處)
本章是獻給主管們的。在我們每天努力的工作中，即便在事前已經花了那麼多時間在開會、做計劃、討論及協調，但事情卻往往還是表現得差強人意，到底要怎麼做才能表現得更好呢? 採用看板方法；嘗試將豐田傳奇的成功經驗分享到軟體的運用上，可以嗎? 看板是製造業的東西；製造業是製作、組裝東西的，進行的是穩定不變的自動化製造鏈，而軟體開發卻是知識工作者的創意結晶，之間的差異實在太大了，我們該如何來調適呢? 這是試著採用休哈特的變異性理論，針對內部變異性: 使用者故事的工作粒度及工作項目的分類。以及外部變異性:需求的捕獲及急迫需求的處理。理論還待進一步生成，請先做參考了。
.
第八章、持續改進
這一張圖(人月神話的封面)道盡了軟體40年來的緩慢成長。今年剛好是這本書40周年紀念，作者:佛瑞德.布魯克斯是IBM System/360系統之父。這張圖是當年的封面也是我第八章的封面，紀念一下偉人。隱喻的是沒有銀子彈的觀念，但一直到現在許多IT主管依然會犯這個錯誤。(哈哈!這一段的說明在第七章裏頭)
.
» 其實；原本有〈 第九章雲端運算對軟體開發的影響 〉，但為了省紙張而拿掉了，其實是為了替讀者省錢拿掉的(跟這篇導讀為何不在書的前面，而反而出現裡是一樣的)。但請放心；過幾天會陸續在Blog上登出來的。
.
« 最後 »
.
- 如果你是要拿來作為看板課程的教材使用，第二、三、四章就夠了(記得附錄也要參考一下)。
- 如果純粹看精實Lean的話，則只有第一章有較仔細的描述(如果你採用看板之父的書來上課的話，對精實Lean這部份我的書就可以變成補充教材了)。
- 沒有開發經驗的人請看第六章，裏頭完全沒有軟體開發的影子。
- 主管請參考一、七及八章，這幾章是專門為管理人員所寫的章節。
.
對精實理論而言；我講少了，也談得太簡單了，他可以是齊家治國平天下的東西，我卻只把它描述成看板方法做抉擇時的依據(真是該罵)。待下回改進!在這
.
全書的結構如下:
撰寫章節的時候，我是運用 FeatureMap 的 user story mapping 工具先行架構全書的章節的，就是下面這張圖。需要的讀者，把你的 email 給我，我會寄邀請給你，然後你便可以在網路上看到圖稿了。Featuremap工具在二個 Mapping 圖示以下是免費的，也可以將圖稿匯出來變成 image 檔(下面這一張圖就是這樣匯出來的)，它是我上 Scrum 及 Kanban 課程時必備的工具之一，可以安心使用。
.
.
廣告一下 我的看板課程，通常每二、三個月會開一次課程。這一回二本書都將提供，一本是我的新書(精實開發與看板方法）另一本是David J. Anderson的看板方法Blue print. 剛好拿來來比較一下效果如何？！
.
》 如果你有遠端團隊要教他們如何來使用看板方法的話，我的建議是用說故事的方式來描述一個實際的案例，這是最簡單又有效的方式了。
Ruddy Lee 分享空間 