如何提升個人工作效率

效能並不能為你換來滿足感的,人生也不見得會因產能的增加而變得更美好。

史蒂芬.柯維《時間有約

目錄

  1. 澄清Lean跟Lean Startup

  2. 運用精實原則來提升個人工作效能

  3. 結語

.

1. 澄清Lean跟Lean Startup

我們先來澄清一些觀念: 所謂的Lean跟Lean Startup 其實是二回事。

.

精實精神跟「好點子」無關

精實精神可以幫你提高效能。但它跟精實創業所謂的好點子,還真是沒有太多關係。常常聽到有研究生在報告裡說到:「創新的成功方程式就隱藏在敏捷(Agile)和精實創業(Lean Startup)裡。」看得人一頭霧水,實在會吐出血來。網路社會上這類的錯誤報告真是多得難以言喻,在這裡陳清一下。

 .

Lean的由來: 精實Lean這個詞彙為John Krafcik,1988 年在他的一篇文章 “Triumph of the Lean Production System"裡所首先提出來的。他稱之為精實製造Lean production,指的是製造業的精實理論。你一定猜得到,這是典型豐田製造的成果,沒錯!它們都來自於製造業,這些精神基本上都是在追求高產能的管理原則。這幾十年來一直被其它非製造業的行業所學習與模仿著。軟體界的精實軟體開發便是其中的一個例子。老實說;它跟創意無關。明確的說;應該說精實精神就是藉由持續改善而達到追求高效能的一種精神。精實創業Lean Startup則是一種發展商業模式與開發產品的方法,是由Eric Ries在2011年首次提出了企業開發產品的方法。很多人把他們連想在一起,但實際上是無關的。

.

2. 運用精實原則來提升個人工作效能

如果你急著嘗試的話,做法如下:

步驟一、排序你的 To do list –運用電子看板把它依序排列好。

步驟二、加入狀態欄,形成基本看板牆–To do list 放在第一欄。

步驟三、提供現實的緩衝區,以反應等待狀態–讓流程的欄位盡量符合實際的工作流程。

步驟四、加入多工(WIP: 半成品)限額 –為實際上的工作量設定限制數量。

步驟五、啟動拉動系統 Pull System –只又在前面流程有空間的時候 才可以拉入新的工作項目,稱之為拉動系統。

步驟六、每日解讀,持續改善–必須持續對看板系統進行檢討與改善,才會持續維持在高效能狀態。

.

步驟一、排序你的 To do list。

把自己的日常工作用to do list 陳列出來,然後依照優先順序由上往下排列。切記;沒有必要一口氣把整個星期的工作都排好,因為那樣作就太不切實際了,要熟悉如何去應付變化才是生存之道,生活會因為你的高適應性而顯現得更美好,你周遭的人也會更快樂。這樣的思維方式就稱之為敏捷Agile。

1
這個 To-do 稍稍大了些

步驟二、加入狀態欄,形成基本看板牆。

基本的看板具有三個欄位: 代辦事項、進行中及完成。這三個欄位是用來充分反映準備衝刺時的人性面。這好比我們跑百米時的「各就各位-預備-鳴槍」。人性面所指的是我們足夠預備好做好衝刺的準備。

2
基本的看板具有三個欄位: 代辦事項、進行中及完成

步驟三、提供現實的緩衝區,以反應等待狀態。

在真實的世界裡,即使整個案子就是你一個人,等待還是難以避免的現象。而處理這種無法控制的現象,則是設法在看板上留下明顯的痕跡(例如:起始的時間),讓我們可以較清楚的知道狀態。此時規劃緩衝區是一個好選擇。可以讓我們一目了然作業的狀態。

3
緩衝區讓我們知道工作已經完成,正在等待拉動的行為

步驟四、加入多工(WIP: 半成品)限額。

眾所皆知,同時做好幾件事會造成效率的下降,尤其在交換工作的時候,不但會浪費時間,還容易產生錯誤。但是做人就是這樣,單工作業是理想的狀態。所以我們必須做(1) 有意義的多工(對產能有實質幫助,而不是只增加了半成品量)。 (2) 合理的多工(只在必要的時候做多工作業)。所以我們在欄位上設定限制半成品的數目,強制規定可以獲得最佳產出的半成品WIP限額。(請參考利特爾法則 Little’s law)

4
設定限制半成品的數目

另類的多工顯示:

5
在泳道上顯示正在工作的專案,可以清楚知道專案的狀態

步驟五、啟動拉動系統。

看板系統遠遠勝過To do list的地方就在它是動態的,他以工作流程的方式將系統的行為顯示出來,而拉動的方式則是由左到右進行,只有在前方的欄位有空見時,才允許拉動新的工作來做。我們稱這種行為為拉動系統。它有別於一般直接指派工作的推動(Push)系統,可以具有即時性的半成品特性。

6

步驟六、每日解讀,持續改善

即時改善是拉動系統的一大特色。當你嘗試對看板進行調整的時候,各種工作狀態會一一反應在看板上面。這個時候你便可以透過解讀狀態,在作改善的措施來加強膩的工作效能。

7
阻塞的現象

3. 結語

你一定會困惑,看到看板上的種種現象後,該如何來應對呢? 答案是: 請依據精實軟體開發的七大原則,來做決策。

  1. 消除浪費 Eliminate waste

  2. 增強學習 Amplify learning

  3. 盡量延持決策 Decide as late as possible

  4. 盡快交付 Deliver as fast as possible

  5. 授權團隊 Empower the team

  6. 崁入完整性 Build integrity in

  7. 著眼整體 See the whole

看板方法第一個基本原則 : 從既有的流程開始 Start with existing process

看板方法能夠迅速崛起的最大要素,可能要歸功於這個第一原則了。

從既有的流程開始  Start with existing process

這個原則的目的是: 透過優化現有的過程來驅動改革。但這樣做就能保證會成功了嗎? 下面是實際做的時候的致勝訣竅。

※ 我們用一個例子來做說明。

首先假設你正在準備一場演講,這是一個50分鐘的演示,而你想在5鐘內就能迅速擄獲觀眾傾聽的心靈,請問要如何開始呢?

.

訣竅是從「認同」開始

你必須先取得聽眾的認同。OK! 5分鐘過了,你怎麼知道已經取得觀眾的認同了呢? 對演講而言,聽眾的眼神跟頻繁的點頭可能是最基礎的認同了,演講者在侃侃說明主題的時候就可以很容易的觀察到聽眾的反應,觀眾的眼神跟點頭正是告訴講者你得到基礎的認同了。(一種公認最佳、最快速取得聽眾認同的演講內容,便是講故事: 一個3分鐘的故事,可能是取得觀眾認同最快的方法。)

.

是講者也是聽眾

接著呢? 試著讓自己由主觀的第一人稱的演講者,走向客觀與聽眾成為相同的第三人稱。

讓聽眾感受到你跟他們站在同一陣線上,而你的任務是來協助他們盡快理解這個主題。協助與理解」是這個階段的主要目的。當聽眾意識到演講者是來協助自己理解這個主題時,戒心與防線就會大大的降低下來,所謂的"喝倒采"與"不以為然"的表情也會消失殆盡,你會發覺講者與聽眾已經站在同一陣線上了(當你聽見台下聽眾不經意地發出一些認同的聲音,例如:喔~原來如此! 便是了)。

.

愉快的共同合作與改善

然後呢? 用聽眾的掌聲來確定你們合作的默契,並盡可能讓聽眾吸收到最重要的資訊,這便是講者最後的責任了,就是繼續努力的改善聽眾的接受度。你的多一分努力聽者可以清楚的感覺到學習的愉悅,這就是了。(與主題有關的笑話可能是快速得到愉悅學習的最佳方法。)

這個例子跟第一個原則有甚麼關係呢?

上面的例子演示了成功演講的三部曲:

  • 取得認同。

  • 同一陣線的相互協助、增強理解。

  • 愉快的共同合作、持續改善學習效果。

「從既有的流程開始」,代表的是由認同走到協助與理解。先用肯定的方式:  認同既有的工作流程就是對原來團隊的付出予以肯定。肯定對方的貢獻可以降低在角色上的對立關係。 有了認同跟肯定再進一步才能夠產生合作與改善的關係,也就是不分你我大家一起來從事改革的工作。接著要讓團隊看得到可以改進的地方,並願意主動去從事改善的工作。就是這樣的過程讓大家很容易的去接受看板方法,進而能在阻力最小的情況下實施改革。

.

說穿了訣竅就是 Understanding。 當聽眾與演講者之間沒有間隙,當開發團隊與改革者之間站在同一陣線,接下來才有可能同心協力一起追求持續改善了。

.

(參考: Kanban from the Inside,Understanding很難只用一個字來翻譯它: 理解,懂得,熟知,通曉,獲知或是 諒解 )

先學 Scrum還是 Kanban?

先學寫程式還是先學測試?

對於初學者或新人而言由測試開始是再好不過的了。

一旦寫程式的功力夠了,製造缺陷的機率自然會下降些,這個時候再來寫程式,才不會害己害人。

原因很簡單;因為缺陷是程式沒寫好所造成的,所以要學寫好程式,先學如何測試別人的程式,先看懂別人的程式,再來嘗試寫好程式,似乎會好一些!

.

先學 Scrum還是 Kanban?

大部份的時候;你可能完全沒有選擇的餘地,這可不是老天能安排的,而是看老闆的安排。

從屬性上來看:

Scrum 容易探討未知,處理複雜專案,拿來開發新東西威力無比。

Kanban 是教我們如何自我檢討,可以迅速消除浪費,而得到好的效能。

如果你是開發團隊,當然是先從Kanban 開始。先檢討好團隊的基本動作,整頓好了再來開始作新的東西,從事開發的動作,自然少浪費。這是精實Lean 的好處。

(有太多開發團隊,只曉得一意往前衝刺,忽略了自己在開發上的浪費,這會造成很難走得久遠,尤其是Startup的團隊尤其如是。)

如果你是維護團隊,當然是先從Kanban 開始。視覺化是最大的亮點,團隊可以看見工作上的維護流程是一件相當有價值的事,針對個人亦是如此,人們常常因為養成習慣了,就一直持續做同樣的事情,很少會有機會回過頭來檢討,哪裡做得浪費了應該改進。看板方法的第一步: 視覺化。正是團隊可以拿來持續改進的基礎。這一點對維護工做更顯得珍貴。

如果你是測試團隊,當然是先從Kanban 開始。看的見以後才可以減少猜測的比例。測試團隊在擬定測試計畫之前,一定要對待測的產品或程式有足夠的了解,才可能開出實用的測試案例,不至於浪費大量的測試資源。或做了過多的重複性測試。

.

(你可能覺得奇怪,為什麼都是 Kanban Method 先行呢? 其實原因很簡單,因為它"單純“,不是簡單喔! 它沒有想像上的簡單,因為它可以演進得很有深度,但是它的目的很單純,就是追求效能。不像 Scrum 的目的,是要來應付複雜的專案開作業,基本的方向就完全不一樣的)

.

將看板方法融入Scrum的開發過程才是上策

看板方法是一種流程控制,他不是一種具有完備基礎的方法學,雖然他的潛在發展相當可觀,但目前他仍只是一種提供我們產出高效能的流程控制法而已。他缺少需求描述、沒有完備的會議規畫、少了團隊職責分配,少了很多很多軟體開發上該有的措施,這一點讓他看起來十分空泛,但就是這個特性也讓他十分適合融入其它開法方法中,尤其是 Scrum。

看板方法之父 David J. Anderson 是在Microsoft 公司推行敏捷開發法 Scrum 的時候發明看板方法的。他原本的目的只是要求能夠在最少阻力之下順利在組職中推行敏捷式的開發法而已。卻由於他熟悉限制理論的運作而開創了看板方法Kanban Method。做出了對敏捷開發的精實Lean 一支的重大貢獻。也就是這樣的典故,讓看板方法Kanban Method可以十分容易的融入到Scrum的開發過程。

著名的《 Essential Scrum 》 的作者Kenneth S. Rubin(它是2013年Amazon 敏捷理論最暢銷書),書中就大量的採用 WIP(Work-In-Process)的觀念,實際的運用在工作看板上面。讓Scrum在開發流程上減少了許多的浪費現象。

 .

※ 看板方法先行

因為它可以減少組職在推行敏捷上的阻力,它能讓工程師以最好的節奏持續進行開發工作。又能將精實觀念帶入團隊運作。

※ 融入Scrum的開發過程

因為看板方法的流程控制方式是用來提升Scrum運行迭代開發時的效能。讓 Scrum 能真正用來克服複雜的軟體程式開發過程。

.

Scrum 的目的在解決複雜的軟體開發作業

許多人誤把Scrum 當成加速軟體開發的銀子彈。這是錯的! 他的目的不在加速開發(加速開發工作是開發工具的廣告詞),它的目的是在解決複雜的軟體開發作業,讓它提高成功率。在協助團隊能夠提供給客戶真正要的產品,且讓他在市場上具有實際的競爭力。這一點也正好是看板方法所缺少的。

開發團隊千萬別因為實施了看板方法而誤以為需要把 Scrum 拋棄了,這是一種錯誤的想法,讓他們相輔相成才能有更大的效益。下一回就來談"運用看板方法的十個不應該放棄 Scrum的理由"。

.

測試難還是寫程式難

讓我們回到一開始的主題,到底是測試難還是寫程式難? 其實正確的說法應該是寫出正確無缺陷的程式難! 實際上程式設計人員在寫出程式之後,也必須透過測試,才知道他是否能正確運行。因此"寫跟測"實質上是一體的二面,一樣重要。

至於Scrum 與 Kanban Method 之間,則都是通往敏捷開發的路徑。已經在使用 Scrum 作開發工作的人士,學習 Kanban Method 可以讓他們進入精實的領域,有所依據的持續追求更好的效能。先學會Kanban Method 再跨足 Scrum 的人呢? 則可以看到敏捷開發在處理複雜問題上的具體方法,真正懂得去追求效能之外的正確性與方向。

先學 Scrum還是 Kanban? 二者之間並沒有衝突存在,端看你現在最需要的是那一樣,那一樣就先來吧!

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

 看板方法 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的基本特色了。

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

為看板方法制定簡單的規範 Simple rules to Interpret Kanban

David J. ANDERSON 在創始看板方法之初只寫下了三條實務(Core Practices):

  1. 視覺化
  2. 限制WIP數量
  3. 管理工作流程

沒有特定的角色? 沒有特定會議(下回就來討論看板方法的會議)的規劃? 只有如何運用看板的方法。但是有趣的是;幾乎所有實施看板方法的團隊都有站立會議。這一點難免造成了大家對會議的疑惑: 這個站立會議要怎麼開呢? 怎麼開才能像scrum 的每日站立會議一樣: 大家都知道要做甚麼呢?

(Scrum 站立會議固定要由每一個成員描述三件事: 1.我昨天做了甚麼? 2.今天準備做甚麼? 3.有沒有遇到障礙? 但對實施看板方法的團隊而言這三件事都已經寫在看板上了,當然就不用由成員再做描述了。那麼看板方法的站立會議有必要招開嗎? 要開甚麼呢?)

» 我習慣的作法是訂定簡單的規則讓團隊有所遵循,也就是團隊運用"簡單規則法“來制定一般性、簡單的、容易遵循的規範。讓團隊成員依循規範在站立會議上能夠像scrum 的每日站立會議一樣,大家都知道要說些甚麼? 依據怎樣的程序進行。

實施看板方法最怕的就是團隊的成員,對正面臨到的阻塞問題一知半解,一臉茫然的樣子

— 團隊成員沒有跟上流程進度是看板效能不彰的最大原因

.

由於;看板團隊並沒有像Scrum Master這樣的特定角色,來負責保證實施看板方法的過程都能夠符合看板精實的精神。因此一般的看板團隊在督導這件事上;就很自然的由專案經理或產品經理來負起這個責任。但這是不符合Lean的精神的,團隊應該要學習如何做到自我管理。一個能夠自我管理的團隊在處理工作事項時,它的動作是高效能的、由下向上的,成員們能自動做到拖拉工作事項的行為,這才是看板方法精實的精神所在。該如何來解決這個問題呢?

.

解法;我們不但不能讓成員對看板上的狀態一知半解,更要要求每一個成員都能主動解讀看板上所發生的狀態,怎麼做呢? 透過訂定簡單的規則來實現。所謂的簡單規則;我稱它為「看板解讀四部曲」: RIQA: 它們分別是;更新 Renew、解讀 Interpret、提問 Question 以及調整 Adjust。

Kanban 解讀四部曲

.

【作法】

四部曲是一個循環,強迫規定在每次站立會議的時候由團隊成員以輪流的方式來帶領執行這四個步驟。目的是讓今天擔任執行解讀的成員,在會議開始之前就能先弄清楚看板的狀態,並能夠帶領團隊學習解決流程上發生的問題。從此以後大家便都能夠清清楚楚知道看板上所展現的狀態。這種透過每個人輪流帶隊作解讀的工作就不會有人一知半解了。

» 二人一組的解讀方式也是可行的,如果是 Scrum 的團隊,就讓Scrum Master陪伴一個成員進行四部曲,非Scrum 的團隊則以一次二個人解讀,但每次更新其中一人的方式來進行。讓團隊在合作的狀態下來進行解讀作業效果會好很多。我有過太多次的經驗,就是團隊成員始終表現的一知半解的;或是你也弄不清楚他是否知道自己要做甚麼。怎麼辦呢?只有一個方法可以弄清楚,那就讓他來講囉! 這也是我發明「看板解讀四部曲」的由來。

.

【看板解讀四部曲】

  • 更新 Renew: 更新工作事項、依據拉動原理更新看板。

  • 解讀 Interpret: 依據工作事項的類型、服務類別、到期日或是工作事項在queue內停留的時間來進行分析、了解。

  • 提問 Question : 對工作事項、對優先順序、對瓶頸 …都可以提問,但重點是要問對人。

  • 調整 Adjust: 針對執行上面三個步驟所得到的結果進行分析討論並決定如何解決(是對工作事項進行合併、分解呢? 還是調整 WIP值),運用調整的方式漸進的讓流程得到更順暢的改善。

四部曲是一個持續的循環,它的功能是讓團隊每個人都確實參與解讀的工作並能夠做到不斷的追蹤(tracking) 看板的狀態變化,隨後在用漸進的方式來解決問題。

.

SCRUM的每日站立會議

來談一下站立會議,對實施 SCRUM的團隊而言,站立會議對團隊或個人都是相當明確的事,大家都知道時間到了要做甚麼。工程師在自己的座位上從站起來,到走來開會的地點(Task Board 前面),一路上的思緒就不斷的圍繞在那三件事上頭,所有的人都是如此,因此開會的效率也就變得極佳。

會議是由 Scrum Master住持,但話說得最少的可能就是他了。每個人在說出自己昨天做了甚麼的時候,是個人自我審視、自我反省的最佳時刻了,他代表著你對團隊的貢獻度。而由你自己說出來,來贏得別人的尊重及喝采。因此大家自然都會十分重視這一刻的到來。得到喝采的人會繼續追求,失落的人會痛定思痛避免再次犯錯。以此做為一天的開始真是有百益而無害。

太多單位喜歡開站立會議了,即使在團隊沒在Run Sprint的時候,也會偶爾實行一下站立會議。沒開站立會議,好像一天就沒了開始。提不起勁來!

※ 讓看板團隊在沒有 Scrum Master 的督導下,也能自動自發的依循"簡單的規則"來順利的進行高效的站立會議。能夠自我管理的團隊,經常是透過制訂大家共同遵循的「簡單規則」來取得協同一致的成果的。而簡單規則怎麼來制訂呢? 歡迎參考我的《看板解讀四部曲》。 老實說;我總覺得四部曲好像多了些,如果可以訂得像起跑時的口令: 「各就各位 – 預備 – Go 」那就太棒了!

(看板方法是流程控制系統,它不是一個完整的軟體開發方法(至少現在還不是),從軟體工程的角度來看它,真的是相當不完備,缺少了不少的東西。所以當我們學習開始運用它的時候,請基於目前所採用的開發方法為考量,然後盡量去參考精實(Lean)的軟體開發原則來作決策,千萬不要把它拿來當做是一個完整的開發方法,也就是說;凡是它沒說到的我們就不做,真的這樣就錯得離譜了)

看板方法: 四個基本原則 Four Foundational Principles

 

看板方法 Kanban Method 定義:

看板是一種改變管理方針的途徑。它不是軟體發展、專案管理的生命週期或者流程。它是給現有的軟體發展生命週期或者專案管理方法中引入變化的途徑。

Is an approach to incremental, evolutionary process and systems change for organizations.

看板是一種透過漸進、演化過程來改變組織系統的方法。

David J. Anderson

看板的本质是一個很單純的想法,那就是半成品(work-in-progress,WIP)必须被限制。 

David J. Anderson

 

所以我們可以簡單的描述"看板方法" 為WIP約束系統。

 

.

想要實施看板方法或進一步了解看板方法,請依照這四個原則去思考:

四個基本原則(Foundational Principles):

原則1 : 從既有的流程開始 (Start with existing process)

目的是;透過優化現有的過程來驅動改革。因為這樣做一方面所承受的阻力較小,另一方面又容易看到成果。如果今天負責推動改革的人是我們,你會怎麼做呢? 或許你會先擬定好改革的步驟,然後按部就班的實行他。但是經驗豐富的 David J. Anderson 卻選擇先找出改革最大的阻力是甚麼? 就從這裡開始。

改革最大的阻力是人,因此他將啟動看板方法的關鍵放在變化要越少越好。他說:「你必須要抵制住改變工作流程、職位名稱、角色及職責,以及當前在用的具體實踐的誘惑。不要試圖去改變這些。要改的是半成品(WIP)的數量、與上下游的接口及互動的方式。」而那就是把現有的價值流程圖畫出來,不要試圖去改變它或重新發明一種理想的新過程。

 

原則2 : 同意繼續增量,漸進的變化 (Agree to pursue incremental, evolutionary change)

因為前提是在阻力最小的清況下做變革,因此不做較巨大的變化,依循敏捷開發小量遞增的精神,讓所有成員同意處於小阻力之下進行變革。

 

原則3 : 尊重當前的流程、角色、職責和頭銜 (Respect the current process, roles, responsibilities and titles)

對於現有的流程、角色、職責和頭銜應該給予肯定,避免去做太大的改變。目的是能夠順利的推行看板方法,讓原本的組織能夠在微量變化之下,開始接受看板方法。

 

※ 前面三個原則在提醒你避開人為的阻力,目的是讓看板方法能夠順利展開。避免在還沒進行改革之前就先遭遇到阻力。

原則4 : 鼓勵各級在實務上的領導行為 (Leadership at all levels)

應該關注的重點在大家是否能夠對現有工作流程具有持續改善的精神,才是最重要的事了。這個原則在強調推行看板方法並沒有特定的領導人,能由各個階層真正去了解看板方法,並自動出來擔任領導的角色,這才是領導人物最好的選擇。

 

 

四個基本原則Four Foundational Principles的意義

這四個基本原則的最大意義在追求一個好的開始,前三個原則在提醒你避開人為的阻力,第四個原則責告訴你,讓對現有工作有改進熱情的人浮現出來 ,讓團隊自己能夠過審視自己現有的工作流程,並找出哪裡可以改進的地方,經過討論後能夠改善缺點變得更好。他想說的是: 請正視你現有的流程,在團隊和諧的情境下,透過改善讓它的價值可以凸顯出來。

實施看板方法一些注意事項

TechDays 2014 上了一堂看板方法課程

看到許多來參加課程的主管及工程師們紛紛起了嘗試 Kanban Method的興趣,真是讓人欣慰(也開始擔心起來)。要知道;看板方法十分簡單,實施起來只有簡單的規則,但它是屬於經驗主義之下的過程控制方法,經驗在這裡佔據成敗的最大成分,因此趕緊補上有關看板方法執行失敗的一些注意事項:

not simple

規則簡單但需要持續的改善才會成功!

作為一種漸進式變革管理工具的看板已逐漸為人熟知,它是精益敏捷陣營中適應性最強大的方法(如上圖,Kanban Method 只有3個產出物),這也就意味著它的標準化程度最低(如下圖,很少有長得一模一樣的看板)。所以一些團隊雖然參加了《看板方法課程》的培訓,實際應用時卻十分容易流於形式。大家雖都能把規則倒背如流,看板具有的6大核心實踐:視覺化、限制WIP、管理工作流、過程規則化、要落實回饋、協作式改進,但需要知道的是;達不到這六點就稱不上成功實施看板方法? ! 因為他們是息息相關的。( 其實;看板方法實施起來一點都不簡單。在 David J. Anderson 的看板方法一書裡頭,第六到第十五章講的正是實施看板的方法,初次看的人一定會頭昏腦脹,更別說後面談到模式的那幾章了,但話雖如此;有料的書應該買得讓人有比較值得的感覺吧!)

( 在課程中,舉了個人看板作為範例,請注意: 個人看板主要談的是持續改善進而確定人生的方向,人們很少用硬梆梆的數據來描述自己的行為的,反倒是能否容忍自己的作為表現才是重點。團隊的看板就不只如此了。)

  • 第一要忠實分析你的價值流程圖 Value Stream

     (這是精益精神的基礎,不要去看當初公司制定的制式規範,要透過團隊一起確認工作方式才是真正的工作流程。別忘了讓團隊自我管理,多畫幾次…)

  • 千萬不要本末倒置,讓流程反過來去配合看板 😦這是初次運用看板方法的必經過程)
  • 不要畫得太詳盡,要適度的抽象化,千萬不要什麼都想放上去(我的第一次失敗經驗)
  • 一定要實體與數位看板並行。讓團隊自己討論,讓他們自己挑出合用的工具,RUN 它一個星期之後再來個大PK(讓團隊自已做抉擇,這種經過團隊用心討論出來的東西,最有價值不過了)。

  • 要有個十分明確的目標,讓站在看板前面的人可以說得出來,問題(會阻礙達成目標的種種因素)自然也會呈現出來。
  • 千萬不要讓自己掩埋在Buffer裏頭,勇於嘗試! 想辦法看到瓶頸才是真正的目的,不要老是用小小的加加減減來欺瞞自己,因為要看到現象才能對症下藥,所以盡可大膽的嘗試。
  • 注意,在以能夠達到最大產能的原則下, WIP Work-In-Process 半成品的數值要越小越好,不需要分出多餘的Column時,就把它刪掉,若是刪錯了,別太擔心,最多就這一、二天問題自然會跑出來的(有問題出現,透過討論找出解決之道,看板自然就又改進了一步,持續改善是看板方法最重要的精神)

  • 千萬不能讓成員打迷糊仗: 如果一大早在Kanban 前的會議,有團隊的成員始終沒有進入狀況,也就是對看板上所出現的現象一知半解的,請務必花時間進行充份溝通,這是"經驗之談"。因為一旦有人脫鉤了,接著下去的整個 Sprint 他都會始終在狀況外。這是最最要不得的。 Scrum Master 一定要加以輔導盡到職責。

  • 遇到瓶頸基本上的因應之道可以考慮增加 WIP 的額度或是增加緩衝區的大小。但不要忘了 WIP 和 Buffer 都是越小越好的東西

  • 看板是一個實驗性的過程,因此WIP的限額需要視狀況進行適當的調整(請參考TOC的五步聚焦法)。

下面是一個實務化的看板,圖片的下半部有一些說明是用來提醒工程師在每個階段該做的事!

實例化看板

還有些話要說,等下次了…