Ruddy Lee 分享空間

Emergent Design 演化設計

Archive for 九月 2014

看板方法: 科技企業漸進變革成功之道

with 30 comments

book_0

今天要介紹看板方法的由來, 上面這本書是由看板方法之父 David J. Anderson 於: 2010年 4月所著。簡字版是 2014 年2月出版。這篇文章在我上 TechDays 課程時就想登出來了,想把好書介紹給大家。但由於台灣的書商都沒有進口,所以一直等到我拿到第一批書後,肯定大家可以在坊間買到書時才把他登出來。原文書名: Kanban: Successful Evolutionary Change for Your Technology Business.

看板方法

它是敏捷陣營中實施起來阻力最小,生產力又能大幅提升、前置時間大幅下降,而可預測性又絕佳的敏捷解決方案之一。好神奇喔 … 哈哈! 確實如此,所以我才會這麼急切的推薦給大家。另一個原因是Kanban Method 現在在美國正熱烈風行中,而我們現在開始追正是時候。為此放下了許多手上正在做的工作(包括一本 Scrum的教本),努力開始推廣希望大家能受用。首先說明: 為何他推廣起來阻力最小?

※ 實施起來阻力最小:

因為David J. Anderson 本身是一個微軟的 PM出身,他跟大家一樣知道變革會讓許多人害怕,人們會認為自己的技術是否落伍了,開始擔心害怕變革會對自己的工作事業帶來不利,這種恐懼常常會帶來一種莫名的對立,因此在還沒開始變革之前就已經採取抵制的態度了。所以他創始的看板方法選擇從哪裡開始實施呢? 就從現在既有的流程開始。由工作者本身最熟悉的地方開始。起步的秘訣是甚麼呢? 是精實精神中從豐田系統中學來的原則,先從不浪費開始,作法: 在識別浪費後消除浪費

※ 如何能讓生產力大幅提升?

由審視既有流程,依據 Little’s law的最大產出方法,接著找出阻礙最大產能的瓶頸所在,然後正視這個造成瓶頸的問題,把它顯現在看板上面,讓大家一起站在看板前面討論如何解決它,解決之後再持續進行改善的作業。

※ 前置時間大幅下降

過去我們都以為唯有透過良好的規劃及配合才能夠讓前置作業時間下降,但豐田企業的及時(Just In Time)備料讓庫存降至最低,讓半成品減至最少改變了工作流程的前置時間(Lead time),因此得到大幅下降。

看板還是看板方法 (Kanban or Kanban Method)

英文叫 Kanban,上網去搜尋會得到一大堆有關製造業的看板資料。所以請使用 Kanban Method去搜尋,因此中文就該叫做「看板方法」。簡體版的作者有用心在翻譯因此翻對了,值得買來閱讀。全書分成四部分:

※ 第一部分;導讀:  作者說出他的想法,以及創作看板方法的原由。

※ 第二部分;談使用看板方法的好處:  這裡有他個人做顧問時的經驗談,值得仔細閱讀。

※ 第三部分;開始談實施看板方法的步驟了。(由六到十五章,好長又夠完整)

※ 第四部分;談持續改進。在這裡你終於可以感受到精實軟體開發對作者的影響,以及作者由經濟學的角度來看精實軟體開發的第一原則: 消除浪費

接下來我就不在多說了,請讀者自己去看吧!(透漏一下,為了共襄盛舉,我正在寫一本有關精實開發的書,內容除了看板方法之外會大幅談到精實軟體開發,在這裡不想打廣告,因此書名就等出版後再說了!)

廣告

Written by ruddyllee

2014 年 09 月 30 日 at 15:09:20

正確提升團隊開發效能的方法

leave a comment »

進度來不及了,我們是否要考慮增加人手?

運用CFD圖示,探討哪裡出問題了?

運用CFD圖示,探討哪裡出問題了? (分析工作流程的結果運用 Cumulative Flow Diagram 效果最佳)

三十年前的老書《人月神話,作者 Brooks 就已經跟我們說得很清楚了: 千萬不要盲目增加人手,因為加入新手只會讓專案延遲得更兇。但反觀許多的IT部門則依然喜愛如此,專案會延遲… 增加人手便是,一種只要是一個蘿蔔一個坑,問題就好像解決了的觀念依然存在。

Brooks又說:「其實,進度延誤應該是經常會發生的事情,我想不盲目加人是個關鍵,更重要的是大家坐下來檢討進度落後之因透過分析找出趕上進度的方式,是否有哪些功能規劃有缺失,或者是工程師對於需求的掌控度有落差,這才是根本的解決之道…」

我們就來談談,大家坐下來檢討進度落後之因
看板方法請我們從現在的系統出了甚麼問題開始? 先畫出目前的Value Stream Mapping價值流映射圖來,從檢討目前的工作流程開始,先看問題在哪裡才好對症下藥。我的習慣是讓工程師在現在的開發流程中找出盈餘的時間。這不是很矛盾嗎?! 不是已經來不及了,怎會還有空閒的時間呢? (依據精實軟體開發中的看板方法說)請透過審視現有的工作流程,運用限制半成品(Work-In-Process)的方法找出那些不影響產能的空閒時間(請回憶上一篇麥當勞Drive-Through的話題)。簡單來說;就是我們提前製造了一堆半成品(Work-In-Process)對產量是沒有幫助的(半成品,例如: BUG 缺陷、使用者故事、需求變更…等)。找出流程中最大輸出的半成品WIP數,然後對它設限制,也就是當達到數目時就不能再做了,被強迫停下來時便是獲得盈餘時間了。而盈餘時間可以拿來做甚麼呢? 當然是對產能有所幫助的事了。

採用精實軟體開發中的看板方法

視覺化工作流和設限半成品數( WIP值)都是看板方法的前置步驟,他藉著審視既有的工作流程,讓問題可以被視覺化,然後透過利特爾法則來限制半成品數量,盡量不改變現有工作方式之下,在有效的充分優化現有的工作流程。讓效率提升起來,這種採用檢討的方式獲得提升速度,自然比起增加人手必須重新學習要快得多了。有趣的是團隊可以藉由這個過程不斷的改善協作流程減少浪費。

減少浪費,這是精實軟體開發的第一原則,在豐田時代的製造業裡非常重要,引用在軟體開發上亦是如此,我們下回就來談這個主體: 如何減少浪費

(CFD: Dumulative Flow Diagrams累積流程圖,便利事後檢討的絕佳圖示方法)

Written by ruddyllee

2014 年 09 月 29 日 at 13:50:37

看板原理:談麥當勞Drive-Through點餐

leave a comment »

一般人都以為當客人排隊排得滿滿的時候銷售出去的量一定最大,但是事實上這是個錯誤的觀念,請看這個公式:

產品輸出率 = 半成品數 / 製造週期

它叫利特爾法則 Little’s Law,有趣的地方是當半成品的數量增加到某一個數量時,由於製造週期的時間被拉長了,反而讓輸出率下降了下來,接著我們就以麥當勞Drive-Through為範例,來找出當有幾輛車在排隊等候點餐的時候輸出率會有最高的表現。

產品輸出率 TH:看成是客戶拿到餐點離開的數目
半成品 WIP: 排隊的車輛數
製造週期 CT:指一輛車由開始排隊到拿完餐點的需要時間

此時公式變成:

客戶拿到餐點離開的數目比率 排隊的車輛數  由開始排隊到拿完餐點的需要時間

《前提環境》
共有三個窗口,第一個窗口接受訂單,需要20秒的時間。第二個窗口負責收費,需要30秒的時間。第三個窗口給餐,需要40秒的時間。

狀況一、當只有一輛車的時候:CT= 20+30+40秒=90秒, TH=0.01111 , ( CT 值為最小: 代表出餐速度快,但產能 TH 值不佳: 太小 )

狀況二、當同時有五輛車的時候: CT=200秒,TH=0.025,(CT 值不佳: 出餐的時間加長了許多,但產能 TH 值最大)

下面是排隊車輛由一到五輛的統計結果:

M_th1

 

上圖第一個欄位為WIP Work-In-Process 值即排隊的車輛數,當排隊車輛為2,3車時,產出量 TH及點餐週期時間 CT 表現的最佳(也就是;當2輛車在排隊時: 由開始排隊到拿完餐點的需要時間最短=90秒,3輛車在排隊時:此時擁有最佳的客戶拿到餐點離開的數目比率= 0.025)。至於其他排隊數目 1, 4, 5 輛車的意義也就不大了。Youtube 上有這段影片可以參考

wip_th《半成品與產出比的曲線圖》

這是一個有趣的結果,他跟我們說的是排隊車輛在2,3輛車的時候,客戶可以最快拿到餐點,窗口的產出也最佳。所以呢?

※ 如果你是店長,請告知櫃台服務生,當連續點餐到第四位客戶時,你可以停下來去協助其他的工作(專業術語稱之為《盈餘時間》這是你可以善加運用而不會影響產出工作的,例如:拿來做備料或是整理工作 …等等,都可以),因為繼續點餐作業只會增加整個流程的作業時間,只會讓客戶等得更久。

※ 但如果客人已經排隊覺得不耐煩的時候,還是趕緊去服務他吧! 服務第一,畢竟讓客人感覺服務的好壞更重要(客人是不會在乎利特爾法則的)。

看板方法要跟我們說甚麼?

步驟一、首先;視覺化工作流程: 像上面的麥當勞 Drive-Through 一樣,把流程攤開來。

步驟二、再來呢;限制WIP值(設定一個數值,讓店員以此數目做限制,以獲取最佳產出)。

步驟三、適當地作相對調整: 因為完成工作的是人,人的因素相當多,例如: 有手腳快速但偶爾會犯錯的員工,也有細心不出錯但產出稍差的員工,因此必須依靠適時的調整來取得最佳的產能。

看板方法跟我們說:

不需要採用任何強烈的變更方式,只是透過正視平常的工作流程,試著找出問題點,再依據利特爾法則設限同時多工的工作數量,如此便可以讓產能適度的提升,然後再經過持續的改善讓它們變得更好。將這一招:

※ 運用在團隊開發上,可以讓團隊看到開發作業上真正的問題點,達到持續改善團隊開發效能。

※ 運用在個人身上,可以提升個人的生活品質增進個人的工作效能。(這句話說起來像江湖術士在賣藥丸,哈!)

看板方法 Kanban Method 要說的當然不只如此而以,請待續…

(下一篇;我想談專案開發來不及了,要如何正確提升團隊的效能來追上開發的期限。)

下面這一段默片用動畫說明上面的理論。

Written by ruddyllee

2014 年 09 月 24 日 at 12:22:53

張貼於未分類

Tagged with

運用個人看板做時間管理

with 4 comments

「如果無法管理時間,就無法管理其他事情!」彼得杜拉克留給後世的警語。

杜拉克曾說:⌈ 幾百年後,當歷史學家撰寫我們這個時代的歷史時,他們的重點將不會放在科技、不會放在網際網路,也不會放在電子商務。這是人類前所未有的改變。嚴格來說,這是人類第一次具有實在且立即的大量選擇。這導致人們必須管理自己,但是這個社會卻完全沒有準備好。⌋

.

To-Do Lists 還是 MindMap … Kanban!

想做好時間管理的人們,你應該試過To-Do lists了,那長長持續向下延伸的工作事項,讓人看了就不知道該從哪裡開始(在www.codeproject.com上頭的那個,他好像是2003 Nov 出來的,不用好奇,他就叫 ToDoList ,我用超過十年了,從 0.3版到現在 6.9版了,持續關注他完全是擔心維護的工程師少了他就會沒事做了 ♥  ),放著一天不用、放過二天⋯,等下次再打開來時就會有強烈的罪惡感了。最後;乾脆就不開了。建議你,扔掉吧!

todolist_m

你可能也試過 Mind map之類的分析工具,用起來比To-Do lists好太多了,好有成就感哦!每回當眾拿出來總會讓大家驚豔,除了覺得很過癮之外也很有成就感,這樣的思維結構化似乎對構思也很有些幫助,但作完了之後總覺得少了些什麼?悄悄跟你說:是流程,少了流程。一種現實生活不會缺少了的過程。是時候了,來!  試試個人看板吧!

.

看板風潮再起

1931年日本人大野耐一開創了豐田時代TPS的美譽,成就了上個世紀人們追求的工業效能的表率。類似的精神也延燒到軟體界我們稱之精益精神 lean development,在敏捷開發 Agile Development 成為軟體開發的主流之後,精實開發也融入了 Agile 的團隊,其中以 Tom & Mary Poppendieck 夫婦在Lean development的創作最為廣受人知,到了 2004年 David J. Anderson 才在思考要如何達到: 1) 希望開發團隊能夠擁有好的敏捷開發節奏,不會在需求不斷變更下從事疲於奔命的開發做業。  2) 找到一種能夠不會給人認為是巨大衝擊,而是漸近式的敏捷變革方式。他的努力成就便是近代軟體"看板方法"的由來。 正確的命名應該是“Kanban Method" 看板方法(Kanban、Kanban Method … 網路上用法不一,但 Anderson 在2012年出書時做了正名 Kanban Method,只要講成軟體界的看板,指的便是看板方法了)。它的確達成了 Anderson的期望,簡單、好實施,這幾年來深受軟體界的喜愛,一時間所謂的 Kanbanize成為軟體開發的風潮。然而 Kanban Method 的本意: 是在 (1) 透過視覺化流程之後,運用 (2)限制半成品的管制方式來一方面獲取最大產出率,另一方面又能獲得盈餘時間可以休息養生(其實是進修或互助)。然後 (3)依靠持續改善開發流程來不斷敏捷化。 這套方法真是簡單好用,拿來用在個人的時間管理上,就成了"個人看板" Personal Kanban。(話說;應該所有的老闆都會要求團隊具有高效能吧,而提升團隊效能的方式不外提升個人效能,跟加強團隊協作方法。所以有趣的個人看板不只對個人有益,對團隊也有十分意義。)

.

個人看板做時間管理

個人看板是由Jim Benson 所推廣,他和 Tonianne DeMaria Barry合寫了一本書叫 Personal Kanban: Mapping Work | Navigating Life 出版於2011年2月在Amazon 上很受歡迎,一直維持在四顆星的水準。這幾位人士和軟體界的看板之父 David J. Anderson 都是同一時期致力於推廣看板方法的人物,只是他個人以為看板方法也可以在個人的運用上得到非常好的效能,是一個絕佳的時間管理系統,因此就將時間、精力致力於既可用來提升個人工作效能又能改進生活方向的個人看板上頭(對提升工程人員的效率而言,真是貢獻巨大!)。而我個人則覺得這是工程師必學之術,它是敏捷開法的一員沒錯,屬於 Lean 精益開發的精神,它想做到的是教我們如何不浪費,藉著不浪費自己的生活工作及日常來提高效能。

.

現在就下載 Kanban 的 App 到你的平板、手機上

就從今天開始用吧!  我有一系列的個人看板教學資料,大部分是自己做的,歡迎參考。 一開始執行個人看板,你會以為很複雜,但實際上相當簡單。就這麼簡單! 你反而會以為它這麼簡單,所以也不可能有太多功效,那你可就錯了。試試看,感受它的強大效果吧!  Little’s law 是它的工作原理,多了解一些有益無害! 想進階: 請參考 Kanban: Successful Evolutionary Change for Your Technology Business,是看板之父: David J. Anderson 的著作,值得一讀。簡體書為 华中科技大学出版社出版 ,看板方法:科技企业渐进变革成功之道 (因為9月以後空閒的很,經紀公司沒給通告,閒閒沒事做在家,除了早、晚騎車之外就花了許多時間在Kanban Method上頭,打算出書了…,才怪,又想到 Dann 一副不相信的表情,老實說:我也不相信)。在這裡先貼出一些教材來,有時間在把說明加進去(等不及的人,來找我講課就說給你聽)。 ※ 原理如下: (Jim 在書上說的二個步驟,所指的是二步就能做出個人看板了,在這裡我所說的三步驟則是包含回顧之後,進行改善自己的流程。別罵我多事,由於 Lean 精實開發的基本精神就是持續改善,所以就很自然地把第三步加上來了。)

.

投影片23

.

※ 從哪裡開始,就從製作第一個個人看板開始: (起步要越簡單越好,運用看板方法,很容易就會越做越複雜,越做越大,請記得經常思考可以再簡單些嗎?如果可以的話就少掉這個欄位吧!不要擔心會改壞了,不會的… ,請按照以下這些步驟慢慢走完它)

投影片24

.

※ 接著是把工作用卡片的內容也做出來: 你一定有許多想做的事,還有很多不想做也得要做的事,都列出來吧! 不用怕會漏掉,有漏掉的再補上可以了,天天看天天都能再補上就OK了。 我個人是列有年度看板、月看板及星期看板。有空就從年度看板搬一些到月看板,再搬到星期看板,便可以開始每天的作業了。請記得: Multitasking is evil! 雖然人類很會多工,但如果你想把一件事做得有效率,勸你;還是乖乖一次做一件事,然後全力以赴吧! 填卡片,一定要寫那麼多嗎? 當然沒必要,不夠的時候再加就可以了! 很抱歉,我列多了…,隨意就好。

投影片25

※ 接下來,該做一些符合自己作息的修改了(在這裡我只是舉自己的例子做說明而已)。 Buffering 緩衝區法,運用增減 Buffer 大小的控制方式,正是 Kanban Method 的威力所在,請依據利特爾法則 Little’s law (下面會講解這個法則的),來追求最大的產出。(對個人而言最大的產出是甚麼? 這一點很容易讓人疑惑,我的定義是;我還能夠做得更好嗎? 好多少? 有意義嗎? 對個人而言,改善就是做得比上次好。但通常是不被抱怨就好了。) 緩衝區法很好用,但一旦用了WIP值就增加了,也就是說又增加浪費了,所以使用緩衝區法需要節制些。

.投影片26

.

※ 如果看板不能跟我們真實的生活或工作狀態接軌,那不管利特爾法則有多大效用,在我們身上它都是沒有意義的。經過上面的幾個步驟後,我想大家應該都能輕易上手了,但為了讓個人看板真正能提升我們的效能,只有讓工作能真實的反應在看板的流程上頭,才可能獲得實質的改善。所以用心一點,讓流程真實得顯現出來吧! 我舉以下的〈等待〉為例。 等待是最沒有產能的工作,即使在個人的看板系統裡頭,你仍然會發現它充滿了人與人之間的合作關係,這正是所謂的人是群體的動物,是不可能離群索居的。那些與其他人相互關聯的工作,往往不僅僅是效能的問題它可能還牽扯到彼此之間的滿意和信任的程度,這些或許才是你真正在意的。因此把你認為重要的工作呈現出來,已經是一個好的開始了。

.投影片27

.

為什麼要限制半成品數呢?

在軟體發展中,利特爾法則是這樣描述的:半成品數量(WIP) = 產能( TH) * 開發週期時間( CT)

  • 半成品數量(WIP: Work in Process): 開發系統中,未完成項目的平均數量(例如: 缺陷、使用者故事、變更請求…等)。
  • 產能(TH: THroughput):  團隊在單位時間內的產出。
  • 開發週期時間( CT: Cycle Time): 團隊完成一個項目所花費的平均時間。

利特爾法則的動態性是令人驚奇的。說明如下: 如果依照公式,為了提高產能 TH,有二種方式可以做到,一是減少開發的週期時間,另一個方法則是增加半成品數量。看起來很簡單,但是有趣的是這二者並非獨立數據,它們有相依的關係,如下圖:

wip_th

也就是說: 通過增加更多的半成品數量提高的產能有一個極限,產能在到達極限之後會開始下降。(最有名的範例是麥當勞的 driver-through點餐,有興趣的人請自行參考。) 因此如何來限制半成品 WIP數與獲取最大的產能TH值,便成了 Kanban方法不斷從看板上做調整以追求開發瓶頸的工作了。

這便是步驟五所在追求的事情,也就是透過限制 WIP的數值觀察產能是否提升,以尋求最佳平衡點。 (說得稍微簡單了些,這裡有較深入的分析)

投影片28

※ 任何事情總都會有例外,當IT部門遇到緊急的事件時,通常就會啟動所謂的標準作業程序(SOP),用來處理發生的緊急狀況。在個人的日常生活上,恐怕很少人會給自己制定SOP守則,但遭遇到緊急事故;看板方法該如何來規劃呢? 就在看板下方另外開闢一條渠道來單獨處理它,我們稱之為:新增渠道的處理方法。這正是所謂的多工,對效能而言是很不好的,但事出必有因,再怎麼無奈也得做。而且必須盡快做完,需要 WIP值時可以直接寫在橫向的第一個欄位上(我用紅色工作項的卡片來代表)。

投影片28

※  事後的檢討作業是獲取經驗的最佳方式。雖然自我檢討很容易流於一廂情願。但仍然不能失去這個寶貴的機會,讓回顧成為邁向更好的明天的基礎。在回顧完畢後便可以清除完成的工作項目了。

投影片30

個人看板可以讓我們生活得更有效率,透過視覺化自己的日常生活處理事務的方式,讓原本可能渾渾噩噩度過的一些日子變得看得見又明確許多。透過設定WIP值來限定可以工作的事項,會讓我們擁有更多盈餘的時間來做更多的事,生活的更美好。而透過不斷的檢討,可以改善人與人之間的關係,真是一舉數得。

投影片31

.

思考問題:

● 限制WIP 在個人看板有用嗎? 在團隊協作的製程上限制半成品數量wip很有意義,效果可以很快看到。但個人看板;針對自己一個人的工作事項,有意義嗎?

● 是甚麼原因讓看板奏效的?

是因為畫出來就可以做視覺化的追蹤嗎? 還是因為限制了半成品(work in progress)的數量,並且減少了浪費在任務切換上所消耗的精力? 或是因為通過簡單的測量,例如: 開發的週期時間(cycle time)和產能(Throughput)給自己提供了頻繁和有力的回饋檢討呢?

● 這就是 Kanban Method看板方法,好像蠻簡單的?

下面張圖是 David J. Anderson 在倫敦精益大會 Kanban 日使用的Slide,主旨在說明如何由淺入深的運用 Kanban Method。

deep kanban

 .

持續改善

看板方法是典型的改善工程,它的改進方式強烈的依靠經驗,因此問題成了你最佳的導師,所以成長的過程就變成: 發覺問題 -> 思考如何改善並嘗試改善它 -> 在解決問題後,繼續再來…。因此持續改善便成為了他的座右銘。

.

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

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

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

.

換言之,就是想辦法把它變成「習慣」,運用行為科學的理論,製造「線索(一種提示型的徵兆 – 產生規則行為- 作到了就給獎勵」,設法引導自己吧!

 

 

 

Written by ruddyllee

2014 年 09 月 21 日 at 14:13:30

張貼於未分類

Tagged with ,

實施看板方法的步驟

leave a comment »

看板方法成功的訣竅 — 不能容許有狀況外的成員存在!

看板方法介紹

一旦開始實施看板方法之後,接下來便是持續改善的過程

因為看板方法讓我們透過審視流程看到問題,看到問題就能夠持續改善。話說:

看到問題了,這就好比工程師看到 BUG 一樣,接下來呢? (當然是進入偵錯模式)

  • 首先;要能重現問題

  • 接著最大化問題(由最大邊界值來逐步縮小問題的邊界,一直到肯定問題所在)

  • 接著尋找移除問題的方法

  • 然後嘗試各種解題的方法

  • 問題解決了嗎? 回到第一步試著重現我們的問題,肯定問題消失了。

這五個步驟跟著名的約束理論 Theory of Constraints, TOC 的解題核心方法: 聚焦五步法幾乎不謀而合。正可以用來解決看板方法所浮現的瓶頸問題。

1. 識別約束 identify constraint

2. 做出決定,以最大化利用約束

3. 讓系統均服從最大化的約束

4. 突破約束

5. 避免惰性:識別下一個約束,go to 2 進行持續改善 。

可貴的經驗主義在這裡又出現了,又好比程式員進行偵錯一般,經驗常常可以讓我們很快找到問題。這一點讓人又不知不覺地想到 教練跟新進球員一起坐在看台上觀看同 一場比賽的問題。如何迅速找到重點呢?

答案是: 觀察力。

透過持續的改善過程不斷的累積經驗來加強敏銳的觀察力。

(沒有那麼多時間怎麼辦? 還是有方法的: 就是減少變異性,增加可預測性, 讓系統變得簡單些,這也行 … )

下回談了 …

 

Written by ruddyllee

2014 年 09 月 18 日 at 22:39:04

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

leave a comment »

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的五步聚焦法)。

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

實例化看板

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

Written by ruddyllee

2014 年 09 月 17 日 at 15:43:35

張貼於未分類

Tagged with , ,

Scrum & Kanban 桌面

with one comment

BG scrum

Written by ruddyllee

2014 年 09 月 11 日 at 10:52:13

張貼於未分類