8件事，精實開發非用看板方法不可

看板方法想要達成：

1. 實踐工程師能夠在敏捷開發中以一種持續的步調下工作，而不會被無窮無盡的需求所困擾，搞得精疲力盡（希望工程師能夠在正常工作下，活得快樂些！）。

2. 在最小的阻力之下，將敏捷方法成功地推廣到整個企業（希望能夠順暢且成功的推廣敏捷開發）。

這是看板方法之父David J. Anderson第一次採用看板方法的時候，他心裡所想達成的二件事。2004年當Anderson收到上級指派去一家微軟子公司負責推行敏捷開發法，那時候的他擔任產品經理人的職務，由於已經有著相當豐富的專案經理經驗，也知道子公司的工程師們大概會有甚麼樣的反應，因此他選擇了阻力最小的方式，也就是讓工程師們自己主動進行改善的方式。但是卻沒有料想到，看板方法具有如此強大的效能及改善的能力，從此以後，提到採用看板方法時，大家想到的就是流程效能的極致化，也就是持續地追求效能改進的方法。看板方法能夠協助我們做到一個首要目標，七個次要目標：

首要目標：優化現有的流程

高質量交付

提升前置時間的可預測性

提升員工滿意度

為改善留出盈餘時間

簡化優先級排序

使系統設計及運作透明化

設計能夠打造高成熟度組織的流程

首要目標：優化現有的流程

視覺化的貢獻：透過看得到流程、看得到瓶頸、看得到問題、看得到浪費……，針對這類只要看到之後就容易進行調整的症狀，運用視覺化流程做到持續改善、繼續調整流程的貢獻。雖然看得見（Visualize）不是萬靈丹，但卻是一種不折不扣的最佳做法。舉例來說測試的工作，與其大量做猜測式的測試，還不如在開發之初就針對需求把測試案例寫好，讓看板方法協助在文件階段就開始偵錯，讓測試計畫與開發計畫一起透明化展現在看板上面，此時產品的品質自然也會滲入其中。這是它正面的部分，但還是有負面的地方值得注意，就是那些看不見的地方，要知道不是做完了所有的測試案例之後產品就沒有缺陷了，還有許多在測試案例之外的缺陷是看不見的，也同樣需要我們擔心。

設限半成品（WIP）數量：透過限制半成品數量來取得「盈餘時間」，是平衡多工浪費的最佳解題法，也就是讓工程師去做對產能有幫助的事，比做一大堆半成品要有價值多了。這一點最有意義的地方是，工程師可以利用盈餘時間來進行撰寫文件或是交互測試的工作，另外，拿盈餘時間來做學習成長也是很好的投資。

調整就是持續改進：將看板上所顯現出來的問題，透過團隊一起分析、討論找出解決的方式，然後嘗試調整改進，這正是敏捷開發所追求的漸進式的開發方式。豐田式管理認為只有在生產線上的工作者才是對流程最熟悉的人，如果可以讓他們自行視狀況做決策的話，應該是最合適、最正確的決策了。同樣的道理，只有撰寫程式的工程師才知道程式目前的狀態，何時必須做怎樣的調整，程式的作者才是最適合做調整的人了，能夠讓他們自主的調整才是最具有效能的改善。

高質量交付

想要產品有好的質量怎麼辦呢？「重視它」是提升品質最有效的方法！是的，就只是重視它，品質就會開始變好了，這正是所謂的霍桑效應 （Hawthorne Effect）──只要你一開始重視它，質量就開始會變好。看板方法是直接把它（測試、驗收）當成一個開發流程的欄位，然後進行流程控制，每完成一個工作項目就立刻做測試，摒除傳統測試必須凍結程式開發，然後排定時間進行α測試及β測試的方式。讓測試與程式開發並行，自然就會強化交付的品質（要提升品質，我通常會建議客戶由重視品質開始做起，運用的方法是犧牲所有會議的前五分鐘來討論缺陷bug，不管開甚麼會議，會議開始時一律硬性規定這麼做：先來討論五分鐘如何改善缺陷，不用多久品質就自然的改善了）。

敏捷測試的精髓在能將品質持續注入到產品的開發過程中，它的做法就是讓每個開發的工作項目都用測試來做驗證，只有通過驗證後才算真正「完成（done）」。由圖2-3可以發現，開發作業與測試都是一項工作，這也說明了測試與程式的開發工作是同樣重要的事情。

提升前置時間的可預測性

這裡的「可預測性」是指經由穩定的半成品（WIP）數值，使得記錄在累積流程圖（Cumulative Flow Diagram，CFD）上的曲線顯得平滑，因此我們就可以比較容易去預估它。對主管而言，這種好的可預測性是再珍貴不過 了。圖2-4的左圖中有四條曲線，分別描述單位時間裡待辦事項（Backlog）的減少量、單位時間裡的開發工作量（Dev）、單位時間裡的測試量（Test）及單位時間的產出量（Production），當曲線越平滑則相對的可預測性就越高。右圖則是描述理想中的看板流程圖，讀者可以很清楚的看出固定斜率的斜線就是我們預估的理想狀態（WIP值始終不變）。二張圖示相比較之下，你可以體會到現實跟理想的差距，還真是不容易去預測。

前置時間越長會引起缺陷率呈非線性的增長（這是觀察到的普遍現象，目前尚待理論的佐證），但避免前置時間太長是必要的措施之一。

提升員工滿意度

看板方法從一開始的出發點便認為，被壓迫的員工不見得能有高效能的表現；反之，員工在滿意的環境下容易受到激勵而有高效能表現。

我們已經提到過幾次看板方法如何來增加團隊的效能，它們大都是數據化、可以透過度量的方式，這一點是看板方法能被製造業所接受的地方。但其實在施行精實原則的時候，精實的精神同樣具有相當大的影響，一個能夠讓員工滿意的企業，經營成功的機會自然會上升；同樣的原則可以延伸到開發團隊身上，一個滿意度高的團隊，自然會有較好的輸出效能，因此提升員工滿意度也是增進團隊的方法之一。

為改善留出盈餘時間

平衡員工的生活與在不影響產能之下的適當盈餘時間，能讓員工有更多的時間與機會學習成長，公司也會因為員工的成長而間接提升了戰力。

資訊快速起飛的時代大家都更忙碌了，更沒有時間做學習與成長，所以企業會隨著潮流的變化快起快落，過去所謂的「十年河東十年河西」的變化，現在可能要縮短成一、二年之間就會有大起大落的改變了。敏捷方法所帶來的競爭力提升，是一種改善開發方式的良方，而看板方法則透過改善流程所產出的盈餘時間，來提供團隊成員的最佳直接貢獻。

我過去做顧問的經驗中，在引入新改革方法的時候，首先要做的便是為團隊找時間，要知道一個沒有時間的團隊根本很難再去學習新的東西。秉持著「要找時間」這種想法，我的第一步動作通常是先進行流程改善的作業，想辦法在實質上透過流程的改善給團隊找時間，當找出可以運用的時間，團隊才可能學好一種新的東西，相對地我的顧問成功率才會提升，這一點還需要組織領導者的配合才可能成功。

簡化優先級排序

並非所有的東西都能用精確的數據來表達它的重要性，當我們刻意或過度的追求這些數據時，反而容易適得其反。一個現實的例子是Sony的員工考績評估，由於過度追求精確度（這是典型的政策執行複雜化，造成戰力的大量消耗所帶來的後果），因而造成公司戰力大幅度下滑，以至於在市場上無法與對手競爭，並造成了上百億的虧損。因此，適度的抽象化各個功能之間的優先順序是一個既簡潔又可以節省時間的動作，例如：對各個工作事項採用「高、中、低」三種層級的分類，或是參考Scrum在計畫會議時常常採用的MSCW（必須要有Must have、應該要有Should have、能有很好Could have、不必要有Won't have）也相當可行。當然施行的方式影響也相當大，不能只有抽象化考績的評等，施行細節的簡單化更是不可或缺的要素。

使系統設計及運作透明化

「透明化」幾乎是所有敏捷開發方法都強調的重點，原因是敏捷開發強調團隊自我管理，而團隊要能夠做到自我管理必須要有一個先決條件，那便是專案開發流程的透明化。團隊成員必須要知道自己在做些甚麼？這些工作它們對團隊的影響為何？弄清楚了才能夠發揮自己在團隊中的影響來做出貢獻。所以專案的透明化是團隊運作的基礎。看板方法實施的第一步驟是「視覺化」。視覺化無疑的就已經奠定了極度透明化的基礎了，而更進步的是它把「靜態」 的透明化演進成為「動態」的運作透明化，讓不只是主管而是全體成員都能知道整個流程的運作，這一點使得團隊成員容易發揮自我管理的效能，對管理而言彌足珍貴。

靜態的透明化 VS. 動態的透明化

透明化應該只有多寡、深淺之分，哪來靜態跟動態的區分呢？請聽我說，我們往往假設團隊的成員都有一定的技術程度，對敏捷開發法也有著相當的認知，但這種假設通常都與事實不符，因為很少有團隊能夠做到陣容整齊劃一的。團隊的陣容總是有強有弱、有資深的和資淺的、有剛進來的也有一直想出去的、有科班出身的也有轉行過來的、有熟資料庫的也有只會處理使用者介面的前端工程師，各式各樣的工程師你都可能遇到，而大家所看到的專案透明化也一定不會相同，至少不會跟看螢幕上圖片的透明度一樣。

當大家一起站在看板的前面時，所有的資訊都寫在看板上面（包括了Scrum著名的站立會議的三個問題），但每一個人的解讀就可能不太一樣了！所以看板上所提供的資訊對大家或許是相同的，這種陳列在看板上的資訊我稱之為「靜態的透明化」；而有人認知較深、有人則意會得較膚淺，這種超越視覺的、在認知上的差異我稱之為「動態的透明化」。

我們可以讓團隊透過站立會議一起在看板前面討論工作流程，但你很難去想像工程師的腦子裡到底在想些甚麼？也不可能做到團隊成員對看板上的資訊都有相同的認知。透過看板我們可以很容易的做到靜態的透明化，但是必須想法子讓工程師透過討論或互動教學等等方式，讓成員做到動態的透明化。要知道透明化不是主管單方面的責任，若是要達到團隊自我管理則一定要想法子邁向動態的透明化，才可能發揮看板方法持續改善的效果。

設計能夠打造高成熟度組織的流程

看板方法的拉動系統（Pull System），能夠適度的在組織管理上顯現出團隊自我運作的獨立性，提升了組織運作的成熟度，而逐漸影響到企業的精神文化。「能夠漸進地影響企業的文化」這一點早已是精實軟體開發（Lean software Development）的基本特色了。豐田精神被軟體界的先驅Mary Poppendieck 和Tom Poppendieck解讀成精實軟體開發的七大原則，這七個原則最大的目的就是在透過精實的精神， 讓組織底層的工程人員能夠學習到一種自主式的拉動精神，曉得在工作流程裡扮演好自己的角色，主動做好自己的工作，藉此由下而上的改善企業的成熟度。雖然我們都知道，改革的動作通常都是由上而下運作才容易獲得成功，但精實的精神則告訴我們要透過持續的改善，不止是由上往下，更要由下往上才能形成自我管理的團隊，並獲得全面性的成功。

看板方法運用在軟體業

運用在「軟體開發」上

看板方法屬於敏捷開發的一員，但因為它只專注於流程的控管，因此也能夠適用於非敏捷的陣營，而且即使是運用在傳統的開發法當中，對於開發效能仍然能夠有顯著的幫助。

看板之父David J. Anderson稱看板方法為一種限制半成品（WIP）數目的流程管制，它不是一種開發方法（雖然它是在軟體開發的環境下被創造出來的），雖然它也很適合拿來管制軟體開發時的流程，但它仍然只是一種運用在精實原則之下的高效能流程管制。目前有許多開發法的專家正不斷地為它加入新的元素，希望它能成為一個完整的開發方法，因此就有了Scrum + Kanban = Scrumban等結合Scrum和看板的新開發方法誕生，這對於那些既熟悉Scrum的運作又想要取得Kanban Method效能的開發人員而言是一個莫大的幫助。

運用在「資訊中心」的時候

「維護作業」一直是看板方法表現得最好的一個領域，這也正好是其它許多敏捷開發法最受人質疑的地方。平心而論，維護作業就是接獲請求後，便去設法解決問題，然後在適當的時機做成部署，替換掉先前的問題。這種直接了當的工作，實在也沒有必要運用敏捷開發的漸進式開發方法或是切割成多個迭代來完成它，直覺地採用看板方法的流程控制方式，正是最能滿足客戶急著獲得改善的需求了。

「看得見的多工作業」這是我最喜歡推薦給IT部門主管的維運利器。它的功能是讓IT部門知道自己在忙些甚麼？一般的IT部門為了維持正常的運作，必然會產生工程師每個人同時背負多個任務的狀況，使得工程人員不得不經常性加班來克服這種忙碌的工作，工作常常因此而延誤。為什麼呢？有些工程師忙得要命，卻也有人輕鬆地閒在那裡，看板方法是解決這個問題的良方，就是讓忙碌被看得見，為什麼看得見呢？因為它們（所有的工作、由誰來做、誰負責些什麼）都陳列在看板上面，因此就無所遁形了。

運用在「軟體測試」的時候

所謂「看得見才能測試」，所指的是運用看板方法讓：一、開發流程與測試流程能夠透明化，讓我們看得見瓶頸所在，二、讓測試作業井然有序，讓主管及團隊成員都能知道整體的進度（這是拉動系統適用在測試作業上的一個最佳佐證）。

運用在個人方面：個人看板

看板方法也能夠運用在個人身上，值不值得採用呢？當然值得，因為團隊的效能絕對會因為個人效能的提升而得到改善。因此，不只是開發團隊應該採用看板方法，個人也應該將它來運用在生活上頭。個人看板（Personal Kanban）是運用在提升個人效能的敏捷方法。

運用在雲端：自動化流程控制

目前幾乎所有製作工作流程引擎的廠商都在考慮如何引入看板方法，原因很簡單，因為它可以讓整個團隊看到流程上的瓶頸，然後藉此來持續提升效能。這種觀念正逐漸侵入到自動化的領域，過去自動化流程就是一意地求快求精準，當進入到雲端的領域後大部分的人還以為就是朝向無邊界的方向去追求，甚至有人以為讓程式碼最佳化都是一種浪費，因為雲端太無 限了，應該足以忽略它。幾年過去了，對於雲端的錯誤觀念已經逐漸修正過來，對於效能的追求還是應該一步一腳印，只有仔細的計算才會有精確的數值，而看板方法限制半成品的數目反而能夠增加效能的理論，一樣適用在雲端的環境。（摘錄整理自第二章）

精實開發與看板方法

李智樺／著

悅知文化出版

售價：550元

作者簡介

李智樺（Ruddy Lee）

擁有超過30年的軟體開發工作資歷。微軟Windows Azure雲端及其它新開發技術的指定講師，擔任兩岸多屆TechDay、TechED等大型研討會主場演講。過去是資深的開發人員、大型系統及企業的總架構師，有長期同時帶領多個團隊的Scrum Master進行大型專案的經驗。