Ruddy Lee 分享空間

Emergent Design 演化設計

Archive for 十月 2014

持續改善的秘訣

leave a comment »

治標還是治本: 另類的改善

我經常到處演講或作顧問,空閒的時候就拚命看書,哈哈!是真的用拚命的方式在追求知識。新知或較舊的新知都有,太多太吸引人的知識了,看著看著常常會引發你無限的連想,就這樣把半天、一天給耗掉了。有時我會好奇,為什麼上一次的顧問案自己沒能先看到這篇文章或想到用這種方法呢?!總是事後才找到好的解答,真是太愚蠢了。有一種想要再重作一次的衝動,但有趣的是,很少有完全一樣的情形可以把剛剛學到的經驗再來一次的機會。所以呢!只好把它寫下來了,寫下來或許還有機會幫到別人。

“顧問案"就是想辦法解決問題,把已經形成的問題化解掉,有時它是可以度量的,但許多情形根本沒得評估,業主也不曉得我們作了半天的成果,只知道看不到問題了(其實看不到才可怕,看到了才有機會治本,例如: 看板方法就是藉由視覺化的方式,一直在想辦法看到阻礙,然後再針對阻礙來做改善的一種持續改善的過程),更別談後續要怎麼銜接了! 其實,顧問案的後續動作才是治根,剛剛渡過的危機是治標的行為。但是;主管們,你真正該在意的是後續,只是很少很少有主管來跟我談後續該如何如何處理。一般就是謝謝,再聯絡! 不幸的是很少有再聯絡的。他們很少想到,這一趟顧問之後,我又學到了多少經驗,下一回再來的話,一定會更好的(投資報酬率會好上許多的)! 但,大多都沒有下一回了。

所以我總是喜歡留一手(別誤會了,留一手是指留下許多路徑,讓有興趣的工程師可以有所依循的),留下一些足跡讓團隊有許多改善的機會,那些送書的行為也是製造這種改善機會的一種方法。

改善的密訣 : 人跟流程

救急的時候通常只有事,為什麼會發生這種事! 應該怎麼來處理。何時可以處裡完畢…。當下,解決問題才是當務之急。但是真正產生問題的是人跟流程。一旦問題消失了,接著該處理的就是流程了。這一點很有趣,明明人才是最大的問題但偏偏必須留到最後才能處理,而通常你也沒有能力做到的,即使做到了,你也沒得知道結果。

怎麼處理流程的問題呢? 我的決定一向就是朝品質的方向做決策。這是不敗的原則,一般專案總因為時間的不足,就輕易的選擇犧牲品質,所以有很多決策都只為了快,快一點得到產品,快一點上市,快一點賺到錢。為了求快而偏離了正確的方向,所以該做的第一件事就是保證品質,讓產品或程式變得勘用,勘用才是不敗之地,只有勘用了它才值得我們去維護,所以就成了「從品質開始」。也就是;處理流程的問題就從品質開始。

怎麼處理人的問題呢? 只有少數的機會讓我有時間處理人的問題。人要如何來改善呢? 有一回雇主希望我跟所有部門的工程師一個一個進行面談,這真是千載難得的機會! 但我不知道工程師的心理是怎麼想的,所以我做面談時的第一句話是: 「我是來幫你的」。我們就從你的人生規劃開始談起吧! 在長年的顧問日子裡,我發覺只有當公司給予你的任務跟你的人生方向有越多交集時,工程師工作的效果才會越好。若能夠說服工程師在處理手上任務的短暫日子裡,能夠立志並全力以赴,大家才有雙贏的機會。

一種成功的秘訣 by David J. Anderson

跟大家分享我演講時常常引用的看板之父David J. Anderson的成功敏捷化的秘訣(A recipe for success)六步驟:

  • 專注於質量。

  • 減少進行中的工作 WIP。

  • 頻繁交付。

  • 根據交付速率(throughput)來平衡需求(demand)請求量。

  • 進行優先及排序。

  • 消除變異性的根源,提升可預測性。

(這一段資料在 Anderson 所著的"看板方法" 一書的第三章成功敏捷化的秘訣中)

廣告

Written by ruddyllee

2014 年 10 月 27 日 at 11:40:22

看板方法: 持續修正系統的方法 — TOC 限制理論

with one comment

限制理論 Theory of constraints TOC,高德拉特  Eliyahu M. Goldratt

高德拉特(以色列物理學家)

高德拉特(以色列物理學家)

目標是解決問題並持續改善

從小到大我們就一直學習著要如何解題,考試;就是一個又一個的問題,想到就會讓人又討厭又害怕,擔心的當然是結果會讓人受逞罰,所以除了老師以外可能根本沒人愛考試。一直到畢業以後我們才知道這些只是練習而已,讓我們學習如何去解決更複雜更難的問題的簡單練習。「限制理論」是高德拉特想出來解決系統問題的方法。他的解題步驟是(Five Focusing Steps,五步聚焦法):

步驟一、找出系統的瓶頸。

步驟二、決定如何利用瓶頸。

步驟三、根據上述的決定,調整其他的一切。

步驟四、把系統的的瓶頸鬆綁。(就是解決它)

步驟五、假如步驟四打破了系統原有的瓶頸,那麼就回到步驟一。

(如果你正在看"目標"這本書的話,它是用小說的方式來說明理論,請耐心把它看完,上面這段步驟在第36回…)

這樣簡單的步驟有效嗎? 實話實說,還真有效!  在解釋何謂"限制"之前,先跟大家分享一下自己使用的例子: 偵錯五步驟!

偵錯也是一種解題的過程。當我們收到使用者找到缺陷Bug的回報時,第一步、先找出重現系統Bug的步驟或方法。第二步、最大化Bug來確認它的邊界限制。第三步、由邊界限制的狀態設法解決它。第四步、確認Bug解決之後,沒有造成其他的影響(產生其他的Bug)。步驟五、持續修正其它問題。

哈哈! 你也是這麼解題的嗎! 這不是巧合,而是一種思維,針對複雜的系統,千頭萬緒,你該從哪裡下手呢? 自然很直覺的問下列三個問題:

  1. 什麼需要改變?(What to change?):首要之務就是找到阻礙其達到更高的績效的限制或核心問題。然後把他弄清楚了。

  2. 改變成什麼?(What to change to?):針對上述之核心問題,尋找解決方案,希望能夠真正達到消除阻礙,讓系統達到高績效。

  3. 如何產生變動?(How to cause the change?):當找到解決方案後則必需進一步分析其障礙為何,並轉換成實施步驟讓大家都弄清楚了,以期順利推行變動。

TOC 直覺架構

限制理論的直覺架構

「限制」是甚麼?

它是在一個系統中,為了要達到他的目標,所遭遇到的障礙,稱之為限制 Constraints。也就是說任何一個會妨礙系統達到更高績效目標的要件或因素。都可稱之為「限制」。

高德拉特以為;任何一個系統,不管是實體的,如機器中心、物料的缺乏,或是管理方面的,如策略或程序等,皆有限制存在。如果沒有其限制,則此系統的產出或績效將會無窮大,不過在真實社會中這是不可能的。而限制理論 TOC 是一種管理的科學,它是一種應用在科學的方法,一種物理學的方法,適用在一般生活上問題的管理。看板方法之父 David J. Anderson 則把它拿來運用在軟體的開發上,而成為了看板方法實踐持續改善流程的理論基礎之一。他的說明如下:

五步聚焦法 Five Focusing Steps 是一種創建持續改善過程的簡單方法:

  1. 識別(identify) 限制。

  2. 做出決定,以最大化利用(exploit) 限制。

  3. 使系統中的其餘我有部分都服從於(subordinate)在第二步中所做出的決定。

  4. 突破(elevate) 限制。

  5. 避免惰性;識別下一個限制,再持續到第二步。

步驟說明:

第一步、就是要求我們找到價值流中的瓶頸。

第二步、要求我們找出瓶頸潛在的最大產出,並和實際現況做比較(自問一下;該採取甚麼措施讓瓶頸的能力可以發揮出來)。

第三步、要求我們做出必要的改變,來完成第二步。

第四步、針對已經改善的瓶頸再進行強化,讓他充分的高效產出,以達到持續改善。此時瓶頸的限制應該已經轉移到價值流的其他地方去了。

第五步、則是等待改進的狀況穩定下來之後,再重複整個過程,用以打造一個可以持續改善的系統。

這些原則談起來,還是很抽象,採用案例說明的方式可能會好一些,下回再說。

Written by ruddyllee

2014 年 10 月 26 日 at 15:42:24

深入談個人看板 Personal Kanban in deep

with 2 comments

如果你打算拿個人看板來做時間管理的話,請聽我說…

因為傳統的時間管理觀念認為:「透過追求高效能,就更能掌控生活,因而得到更高的成就感,人生自然會更美好」。所以你就拿個人看板作為時間管理的工具,把你用在公司裏執行看板方法的那套方法,拿來用在"個人看板"上頭,想要運用哪種以追求效率為首要目的的觀念用在生活上頭,讓我告訴你: 用在個人身上是行不通的。因為效能並不能為你換來滿足感的,人生也不見得會因產能的增加而變得更美好。

 

效能指標不是生活指標

你對事務的評判來自個人的價值觀。要知道效能指標不是生活指標,你必須試著找出眼前對你最重要的事來,然後努力去完成它,只有這麼做才能讓你覺得人生更有意義,活著是有價值的。所以我認為: 個人看板的目的是在讓你透過視覺化你的生活與工作,試著運用看板方法來找出甚麼才是你生活中最重要的事,排除那些其他的浪費,多花一些時間在你認為最重要的事情上面,因此而改善你的生活。

 

甚麼才是你生活中最重要的事

把最重要的事視為當務之急是人生的一大課題。我想我們每個人幾乎都曾被理想、責任及別人的期許弄得焦頭爛耳的。所以善用時間就成了每天的課題,要在最少浪費的情境下把精力花在最重要的事上頭。

「最重要的事」應該是多變的,隨著年齡、環境的不同,應該持續的在改變中。當我們生病感冒的時候,最想要做的可能是吃冰淇淋或喝冰可樂。牙疼的時候想得是啃著大塊牛排。那是一種失去的時候才想要得到的心靈滿足感。人生的目標則要大多了,它雖然也會改變但大方向則是一致的。因此運用個人看板的一個課題就是把方向弄對了。

 

做你最想做的事 vs. 做必須要做的事

運用個人看板你可以透過視覺化所有的工作事項,看到你"最想做的事“一直被停留在原地不動(blocked),而"必須要做的事“卻一樣一樣的一直被消化掉,這個時候你便可以決定是要繼續妥協呢?還是斷然的把他排進工作流程中,此時的"人生方向“就是看板方法所追求的最高產能了。沒必要考慮太多,直接排進來作就是了。唯一要注意的是,若出現了流程狀況不順暢的時候,請記得立刻做檢討,再進行"調整"就好了。沒必要猶豫不前因為他們都是一種浪費,應該要消除浪費。

 

個人看板

有朋友回應給我,他在運用個人看板的時候,不管多麼努力,只要一忙就會忘記把工作持續記錄在個人看板上頭,造成看板長得零零碎碎的樣子,很是氣喪(註1)。我回應:何必在意! 個人看板與一般看板之間最大的差異在於所謂的〝自然法則〞的考量。而不是硬邦邦的數據與效能。那;什麼是自然法則的考量呢?

例如:你作了那些事,為什麼作這些事?
所以真正該在意的是方向,而不是一般看板上面所記錄的:我作得多快,花了多少時間才完成這些事的效能。個人看板;它是讓你拿來檢視個人的生活,什麼事情對你是最重要的。那些數據化的流程指標還有用嗎?

是的,有用的。只是你依據數值所作判斷的方式需要改變。它給你最大的幫助是方向。對於那些你在意的事情,它們會一再擁有較高的優先級別,不斷優先的被執行著,這一點會忠實的反應在看板上,它不會錯的。有錯嗎? 這一點恐怕只有你自己知道,你才能決定重點是有需要調整嗎?是再加強還是減少,為什麼?!

如果你可以沈浸在這樣的自覺裡,個人看板對你的影響不管有多大或多小,你都已經開始改變了。

 

(對個人看板想多了解一點,請再參考: 運用個人看板做時間管理用來提升個人效能的「個人看板系統」。或是參考: 成功學大師.柯維的著作"與時間有約" First Things First, 這是我的一個好朋友David Dong所送的書,值的閱讀)

P_BP171

 

註 1. 實行個人看板時,最常收到的問題:[ 為什麼我無法「持之以恆」呢?]

讓行為科學來回答我們:《原來這樣做才有效》作者石田淳指出,人們之所以無法持續做某件事,並非因為個人「意志薄弱」「能力差」或「個性懶散」,原因只有一個:「行動失去焦點」。
一般人會想要持續進行的行動,大致可分為兩種模式:
一、是「增加不足的行為」,例如持續學習外語、長期運動等,以補強原本不足的部分。
二、是「減少過度的行為」,例如戒菸、減肥等,以根除原本超過標準的行動。

》如何讓行為持續呢?
石田淳建議,要讓行為能夠持續,有兩種方法:「控制目標行為的產生」和「控制阻礙目標行為的敵對行為產生」。換言之,想要強化某項行為,就得讓「目標行為」容易做到,並抑制會造成阻礙的「敵對行為」。

.

 

Written by ruddyllee

2014 年 10 月 25 日 at 22:36:42

看板方法: 度量 Metric

leave a comment »

我們在軟體的度量上做得太馬虎了,

大家經常用「看結果如何」就可以心知肚明了!

真的可以嗎?

沒有數據化,當然是假的。

軟體度量的目的

是獲得客觀、可以複製及量化的量測結果,依軟體度量性質及特性的不同,可以分別應用在軟體開發的時程及預算規劃、成本估算、品質保證測試、軟體偵錯、軟體效能最佳化或計畫人員配置的最佳化等領域。

度量的重要性

看板方法的目標是"追求優化現有流程並持續進行改善“,所以度量指標就變得十分重要了。因為必須要有簡單又可靠的度量方式來產生可靠的指標,我們才可能持續追蹤改善。

.

看板方法依靠那些指標來做到持續改進的依據呢? 

有形指標:

  • 半成品數 WIP( Work-In-Process)

    尚未完成的軟體功能。看板團隊為看板上每列中的工作項數目設定限制。 WIP 限制旨在代表團隊的能力,且限制通常會隨著團隊對哪些工作最好能平衡平穩流程及縮短週期時間的深入瞭解而發生改變。

  • 前置時間 Lead Time

 由客戶提出需求後一直到團隊正式交付的時間總和。如圖:由客戶開列出需求 Ticket,一直到這張Ticket的完成謂之。(被誤解的最多的指標,請注意 Lead time 一定大於 Cycle time)

leadtime cycletime

  • 工作時間 Cycle time

       由開始工作到完成工作的所需時間(如上圖)。

  • 服務層級協議(Service Level AgreementSLA)

       在雲端服務的時代裡,最常見的客戶服務品質保證就是 SLA了。因為它代表的是信譽,所以大家一向給予它最高的優先權。是必須優先考量的指標。

SLA

       利特爾法則 Little’s Law 是計算的依據,累積流程圖 CFD 則是表現出來的結果。

無形指標:

  • 訊息發光體 Information Radiator

            看板本身就透露出效能與浪費的種種訊息。調整時請依據LEAN的精實精神七原則。

  • 持續改善的經驗

             追求最高產出與有效工時是進行調整動作時所追求的目標。實質上就是一種不斷追求平衡的動作。也能讓參與的團隊累積很好的經驗。

度量數據的意義

過度的追求數據還不如沒有數據,適度的抽象化是必要的。千萬要記住,數據是用來作調整用的依據,有時候讓範圍加大更能得到平衡的效果。這些設定可以參考需求排序的方法,例如: 三層式的高、中、低。 或是MoSCoW( 必須要有Must have、應該要有Should have、能有很好Could have、不必要有Won’t have)也可行。由累積流程圖 CFD圖所讀取的數據,則是用來作調整以求取曲線的平滑度,追求的是越平滑的曲線可預測性就越佳。

實施看板方法在持續追求流程能夠順暢且高效的流動,而不是報告專案的某個項目是否"準時",重要的是要展示看板系統是可預測的,並且是可以按照原先的設計方式健康的運行,同時也提供了整個組織的敏捷性及戰力的提升。

Written by ruddyllee

2014 年 10 月 24 日 at 14:05:04

看板方法: 目標 The Goal for Kanban System

leave a comment »

 看板方法 kanban Method 想達成甚麼?  我們又能運用它做到些甚麼?

(我想說的是,使用看板方法對大家能有甚麼好處? )

看板方法的主要目標是實施變革管理(Change Management)。這一點反應在他的原著書名上頭:  Kanban: Successful Evolution Change for Your Technology Business.

— David J. Anderson

 s27174102

看板方法想要達成:

  1. 實踐工程師能夠在敏捷開發中以一種持續的步調下工作,而不會被無窮無盡的需求所困擾,搞得精疲力盡。(希望工程師能夠在正常工作下,活得快樂些!)
  2. 在最小的阻力之下,將敏捷方法成功的推廣到整個企業。(希望能夠順暢且成功的推廣敏捷開發)

 看板方法能夠做到(一個首要目標,七個次要目標):

  • 首要目標: 優化現有的流程

» 視覺化的貢獻: 透過看得到流程、看得到瓶頸、看得到問題、看得到浪費。針對這類只要看到之後就容易進行調整的症狀。運用視覺化流程,作到持續改善、繼續調整流程的貢獻。

» 設限半成品WIP數量: 透過限制半成品數量來取得「盈餘時間」是平衡多工浪費的最佳解題法。也就是;讓工程師去作對產能有幫助的事,比做一大堆半成品要有意義的多了。

» 調整就是持續改進:  將看板上所顯現出來的問題,透過團隊一起分析、討論找出解決的方式,然後嘗試調整改進。這正是敏捷開發所追求的漸進式的開發方式。

  • 高質量交付

» 想要產品有好的質量怎麼辦呢? 「重視它」! 應該是最有效的方法。對的,就是重視它。只要你一開始重視它,質量就開始會變好。看板方法是直接把它(測試、驗收) 當成一個開發流程的欄位,然後進行流程控制,自然就會強化了交付的品質。(提升品質,我常用的方法是犧牲所有會議的前5分鐘來討論缺陷BUG,不管開的甚麼會議,一開始一律硬性規定這麼做:先來討論5分鐘如何改善缺陷,不用多就品質就自然的改善了)

  • 提升前置時間的可預測性

» 這裡的可預測性指的是經由穩定的 WIP值,表現在CFD圖示上面的曲線就會顯得平滑,因此我們就可以比較容易去預估它。對主管而言這種好的可預測性是再珍貴不過的了。

» 前置時間越長會引起缺陷率呈非線性的增長(這是現象,目前尚待理論的佐證)但絕對值得避免。

  • 提升員工滿意度

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

  • 為改善留出盈餘時間

» 平衡員工的生活與在不影響產能之下的適當盈餘時間,能讓員工有更多時間做成長、學習的機會,公司也會因為員工的成長而間接提升了戰力。(下一回我們再來談盈餘時間 Slack,Anderson 稱它是 Create Slack 產生盈餘時間)

  • 簡化優先級排序

» 並非所有的東西都能用精確的數據來表達他的重要性的。當我們刻意或過度的追求這些數據時,反而容易適得其反。一個現實的例子是Sony 的員工考績評估,由於過度得追求精確度,因而造成公司戰力大幅度的下滑,以至於在市場上無法與對手競爭,並造成了上百億的虧損。因此適度的抽象化各個功能之間的優先順序是一個又簡潔,又可以節省時間的動作。 例如: 對各個工作事項,採用 “高"、"中"、"低" 三種層級的分類。或是參考 Scrum在計畫會議時常常採用的MoSCoW( 必須要有Must have、應該要有Should have、能有很好Could have、不必要有Won’t have)也相當可行。

  • 使系統設計及運作透明化

» 透明化幾乎是所有敏捷開發方法都強調的重點。看板方法實施的第一步驟:視覺化,就已經奠定了極度明確的透明化基礎了,而更進步的是它把靜態的透明化演進成為動態化的運作透明化。讓不只是主管而是全體成員都能知道整個流程的運作,這一點使得團隊成員容易發揮自我管理的效能。對管理而言彌足珍貴。

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

» 看板方法的拉動系統Pull System,能夠適度的在組織管理上頭顯現出團隊自我運作的獨立性。提生了組織運作的成熟度,而逐漸影響到企業的精神文化。漸進的影響企業的文化;這一點早已是精實軟體開發Lean software Development的基本特色了。

再強調一下;看板方法雖然神奇,但只是一個流程控制系統,它不是一個完整的軟體開發方法,至少現在還不是,至於未來;則還有相當大的發展空間。

Written by ruddyllee

2014 年 10 月 21 日 at 23:18:37

看板方法: 拉動系統 Pull System

leave a comment »

拉動系統 Pull System: 是一種流程的控制方式,限制只有在工作項目被完成的時候,新的項目才可以被拉動近來。

pull system

如上圖所示,當有工作項目Work Item被完成時,系統就會發出拉動的信號 Pull Signal,啟動拉動過程 Pull Process拉入新的工作項目,並開始工作直到完成時,才再繼續下一個循環。目的很明顯的寫在中間,就是為了消除浪費,消除備料、預做排程…等浪費。它是屬於即時處理的系統模式,也就是只有在有空的時候才會拉入新的工作來做。是豐田系統的理論支柱之一,也運用在看板方法上頭。也就是說,在看板的垂直欄位內,只有在前面欄位出現工作項目被完成,並移動出去的時候,新的工作項目才可以被拉動近來,如果沒有空缺出現,流程便無法進行下去,發生阻塞的現象,而解決這種阻塞讓流程能進續順暢進行的工作,正是看板方法的目標。

拉動系統挑戰傳統的思維模式

傳統的工作模式;是當有工作進來了,就把它分配下去做。這是一種主動分配的工作模式,稱之為"Push System"。它看起來非常適合一般的IT作業方式, 當工作需要完成時,就由主管來進行工作的分配。這種方式一開始都是一個蘿菠一個坑開始的,屬於單工的作業,效率很好。但隨著事情逐漸累積下來,再加上開始有維護的需求時,很快就變成能者多勞的方式,也就是工作能力強的人就開始同時負責多件工作,變成50-50 (一個人負責二件事)或 30-30-40(一個人負責三件事),工作很快便開始失去平衡了。此時管理工作就開始面臨挑戰了。

相反的;拉動系統 Pull System;是當有空、做完其他工作的時候,才會去拿取新的工作。例如: Scrum 的每日站立會議,團隊成員只有在完成了手上現有的工作時,才會去拿取新的代辦事項(sprint backlog)來做,因此工作效率較好,是一種典型的拉動作業。但是;難到拉動系統就沒有多工的問題了嗎? 答案是:有的。採用看板系統可以協助你在某些方面得到改善。

對看板方法而言;如果你希望底下的工作人員可以同時作多件事的話,也就是進行多工作業。那就用WIP來限制它,它的好處是運用WIP的限制來避免底下的工程師工作負荷過量。同時它也能夠作為度量工作效率的參考(請參考:限制半成品限額 Limit Work-In-Progress )。

.

採用拉動系統會影響到我們的工作方式,他不只是作法上的改變,對企業文化也是一種改變。它成功的在豐田企業製造了豐田奇蹟,但在軟體業的運用上則還很新穎,看板方法是目前為止最成功的一個例子。這也證明了精實軟體開發Lean software development 雖然講述的只有原則而沒有開發方法, 但對企業的影響卻更勝於其他敏捷的開發方法。

Written by ruddyllee

2014 年 10 月 19 日 at 19:59:57

看板方法: 限制半成品限額 Limit Work-In-Progress

with one comment

當我們依據利特爾法則在追求最高產出時,才豁然發覺實際上我們是在追求「平衡點」。

追求工作數量 workload 與 工作能力 Capacity 的平衡點。

 

MyKanbanBoard_wip

 

「平衡點 」Balance

看著看板上的各個欄位,為了要追求流程的最高產出,我們必須在每一個欄位的最上方做設定,設定這個欄位所允許的「工作事項的限額」,我們稱它為半成品 WIP: Work-In-Progress。這個限制半成品數量的動作,可以讓我們藉著調整工作的需要時間(Cycle time)來改變生產率(依據利特爾法則),因此而得到最佳的產能。(其實沒有所謂最佳的產能,它只是我們不斷在追求的一個目標。而我們一直在作的只是在調整平衡點而已,並希望藉由這樣的調整能獲得讓我們滿意的產能,更接近最佳產能。)

這個平衡點看起來蠻單純的,但執行起來還需要多考慮、多取得工作上的溝通跟認可,處理人的共識有時候比找出平衡點還重要,必須先與上下游之間有共識以後實施起來才不至於造成困擾。接著我們就來走一回最基本的WIP制定原則。

 

※ 單工的考量

一個人同時只做一件事時效能最高(請參考: Multitasking is evil)。所以當團隊有三個開發人員,此時我們就可以考量把 In progress 欄位上面的 WIP值設為3。也就是每人最多同時做一件事。反過來說,當你在設定「個人看板」的時候,In Progress 欄位通常應該是 1。也就是說一次只作一件事,相信這個時候你的工作效能最好。可惜的是,我們很少能一次只作一件事,忙碌總是不請自來的! 因此考慮如何多工又能做得有高效能才是重點。

 

※ 多工的考量

當有限的資源遇到突如其來超過原有資源數量時,排隊現象(queuing)就產生了。如果我們不想要產生排隊現象怎麼辦? 那就只好增加人力資源。但,沒那麼多人可以加入怎麼辦? 那就只好要求一個人同時做好幾件事了,也就是進行多工作業(Multitasking)。雖然我們都知道多工對效能一定會有所損失(工作在做轉換的時候,一定多多少少會消耗人的精神跟時間的)。那看板方法又是如何來處理這種現象呢?

二種方法供選擇:

一、將WIP的數值調大到你願意承擔的 Queue 的最大值,然後再視狀況依次遞減下來。

二、預設每個人需要承擔的多工數目乘上人數作為WIP值,用最小值的方法作設定,然後再視狀況依次遞增上去。

二種方法都有人用,見仁見智,請視狀況嘗試看看。但選擇哪一種方法都沒關係,因為重點在調整的方法上頭。重點在嘗試調整到讓產值與一個循環所需要的時間能夠達到你滿意的數值,然後這就是你的「平衡點」了。

怎麼樣的數值會讓你滿意呢?

就是累積流程圖(CFD: Cumulative Flow Diagram)的曲線能達到平滑。上面的二種方法;一個是由大到小,一個是由小到大,目的都在不斷嘗試著找出產生阻塞時的WIP點。找出來之後再由現象作判斷考慮調上或調下(找到平衡點);也就是曲線能否達到平滑的地步來做WIP值的調整依據(CFD圖的解圖,請參考:累積流程圖)。

※ 無可避免的緩衝區(Buffer)設計

在瓶頸前設置緩衝區,這是一種充分利用瓶頸處資源的典型作法。緩衝區的大小很重要,他就跟排隊 Queue一樣,它會增加WIP的數量,請注意: 當WIP的數值越大,就表示前置的時間就越長,所以WIP數值越小越好。但這二個數值間接的改善了曲線的平滑度,也增加了曲線的可預測性,可以增加我們作決策時的準確度。它也使得工作流程不會停頓下來,加速了交付的速度。

緩衝區的運用可以確保瓶頸處的資源一直處於工作狀態,從而提高了資源的利用率,避免了阻塞。真是好用,但一樣的前提一再的提醒我們,千萬不要為求敏捷而犧牲了品質,主管們最想要的除了高產能之外可預測性應該也很重要。

 

到底排隊(Queue)的大小要設多大呢?

要你憑空去設定一個數值好像蠻難的,但其實RUN過一輪以後你就知道了。就把它設得比產出速率大一點點就可以了,目的當然是讓流程可以不會被中斷。例如: 團隊每周可以交付 5個工作事項,而針對排隊的補充速率是每周一次的話,那把它設成6 或7就都可以了,至於是 6還是 7就看交付速率的穩定度來決定了,一般而言 7應該比較好一點。至於甚麼時候才應該調整這個排隊大小的數值呢?

當團隊提前完成時,若是才過了星期三,團隊就已經達成7 個工作事項,接著就會產生了大的盈餘時間,團隊成員會覺得太輕鬆了(通常是老闆會看不下去),這就表示Queue的大小明顯的可以再調高到 8。調整的狀態,經常會受工作事項的困難程度而影響,到底哪個數值才好,應該是隨著工作的難易度動態的調整,運用即時的判斷來作調整就可以了,沒有必要太傷腦筋或執著於某一個數值,因為它是相對的。

 

看板上沒有設置WIP值的欄位

當產出能力遠比瓶頸處的產出時間大的時候,就可不用設定WIP值了。也就是說在那個節點上有相當得盈餘時間在,當然沒有必要再設WIP值了。哈哈! 如果你是主管的話,此刻想的應該是如何消除盈餘時間,對不對?!

 

還有,最後一個欄位通常都不會設定 WIP值,下回再說吧!

 

 

 

 

 

 

 

 

 

 

 

 

Written by ruddyllee

2014 年 10 月 19 日 at 15:31:53