l

2019年5月31日 星期五

如何用看板管理卡住的工作項目?

May 31 10:30~11:53


狀況分析

使用看板的團隊經常會遇到工作做到一半卡住的問題,卡住的原因不外乎:

  • 遇到技術困難不知道該怎麼做下去。
  • 遇到相依性問題,需要等待其他資源(工作、人、設備、材料)完成才可以繼續。

依據卡住的時間長短,卡住的狀況又可分為:

  • 短期:團隊投入資源想辦法排除卡住的原因,每日站立會議追蹤卡住工作的進度,儘量讓工作可以順利往下游移動。
  • 遙遙無期:預期工作會卡住很久,或是在特定時間才有辦法處理該工作。不需要在每日站立會議追蹤卡住工作的進度,一周、兩周甚至一個月更新一次進度即可。

***

用看板管理卡住的工作項目

▼針對短期卡住的工作,在該工作卡片上面貼上一張粉紅色便利貼,提醒團隊該工作項目發生阻礙,需要特別關注排除阻礙讓工作順利流動。


▼每日站立會議時追蹤阻礙項目的狀況,如果尚未排除則在該阻礙項目上用筆點一點,類似progress bar的概念。如果阻礙卡片上的progress bar越長,表示該阻礙停留時間越久。

***

針對被卡住「遙遙無期」的工作項目,短時間團隊並不會也沒辦法去處理它。如果直接把它放在看板上不管,會佔據一個WIP,這樣也不好。

▼一種常見的作法是在看板上建立一個獨立的Ice Box(冰箱)工作階段,把卡住遙遙無期的工作項目移入Ice Box。如此一來原本的工作階段便空出一個WIP,而團隊只需要定期檢視Ice Box裡面的工作卡片有沒有「臭酸」或「超出保存期限」即可。

當Ice Box中的工作項目其卡住的原因排除之後,只要原本的工作階段未達WIP上限,便可移回原本的工作階段繼續施工。

***

如果怕整個看板只有一個Ice Box不容易分類不同工作階段卡住的工作項目,可以參考《Agile Project Management with Kanban》書中的做法,直接在工作階段增加一個追蹤(Track)欄位。

▼如下圖所示,追蹤欄位和Ice Box類似,(通常)沒有WIP限制,放在其中的工作項目數量不會佔據實作工作階段(WIP Limit  = 5)的WIP。

***

結論

看板透過小批量生產消除變異性讓工作流動得更順暢,縮短產品交期。卡住的工作代表產生阻礙,也就是工作流程產生變異,需要特別關注,才不會發生「人進不來,貨出不去,公司發不了財」的問題。

***

友藏內心獨白:貨暢其流。

2019年5月29日 星期三

設定看板的WIP

May 29 11:52~13:41


前言

很多剛開始跑看板的鄉民都有一個疑問:「要如何設定每個工作階段的WIP?」今天介紹《Agile Project Management with Kanban》書中提到的方法。

***

準備工作

要決定如何設定WIP,以下資料需要先準備好:

  • 視覺化工作流程,例如分析、開發、測試。
  • 知道每個工作項目(work item)完成的平均時間,例如分析工作一周完成六個,開發工作一周完成兩個,測試工作一周完成三個。
  • 每個工作階段有多少人負責,特別是瓶頸工作階段的人數(詳見下面說明)。

***

開始計算

有了以上資訊,就可以計算初始看板的WIP。參考下表,計算步驟如下:

分析

實作

測試

平均每人完成工作速度

6/week

2/week

3/week

工作階段人數


3


產能


6/week


WIP


3 * 1.5 = 5


  • 找出瓶頸,也就是速度最慢的工作階段,在這個例子中實作速度最慢。
  • 算出瓶頸的產能:平均每人完成工作速度 * 工作階段人數,2 * 3 = 6,代表實作階段每周可完成6個工作項目。
  • 將實作的WIP訂為:工作階段人數 * 1.5 (四捨五入),實作階段的開發人員有3人,3 * 1.5 = 5。乘上1.5的目的是讓每個人手邊有1.5件工作可以做,以免WIP太小任何一件工作卡住就必須等待。但也不會因為WIP太高導致context switch的浪費。這個技巧在《Kanban in Action》書中也有介紹。
  • 其他工作階段配合瓶頸速度:由於屬於瓶頸的實作階段每周只可完成6件工作,因此分析只需要1人即可搭配實作階段的消耗工作速度。同理,而測試階段只需要兩人。

分析

實作

測試

平均每人完成工作速度

6/week

2/week

3/week

工作階段人數

1

3

2

產能

6/week


6/week

6/week

WIP


3 * 1.5 = 5


  • 計算其他工作階段WIP:分析工作階段WIP = 1 * 1.5 = 2。測試階段WIP = 2 * 1.5 = 3。

分析

實作

測試

平均每人完成工作速度

6/week

2/week

3/week

工作階段人數

1

3

2

產能

6/week


6/week

6/week

WIP

2

3 * 1.5 = 5

3

***

人太多怎麼辦

剛剛的例子是由瓶頸階段的人數與平均每人完成工作的速度,回推其他工作階段需要多少人。但很多情況是團隊人數已經確定,例如分析、實作、測試各2人,請參考下表:

分析

實作

測試

平均每人完成工作速度

6/week

2/week

3/week

工作階段人數

2

2

2

產能


12/week


4/week

6/week

WIP

3

3

3


在這種情況下,因為一周完成12件分析工作但卻只能消化4件,因此分析階段的工作會累積在實作之前。而測試會沒有工作可做,導致人員閒置。

但是,幸好有WIP限制,分析工作不可能無限增加。如下圖所示,假設分析與實作階段已達WIP上限,此時分析人員便不可再從待辦事項中拉取工作來分析,只能停下來看看如何幫助工作流動得更順暢。

同理,測試階段可能沒有多餘的工作可以做,一樣需要思考如何幫助工作流動得更順暢。最直接的方式就是所謂的swarming,分析與測試階段的人到實作階段幫忙,提高實作階段,也就是瓶頸階段,的產能。

如果能夠從每個工作階段的產出可以互相匹配的角度來安排人力與設定WIP,會讓工作流動比較順暢。

當然,實務上平均每人完成工作速度變異性可能很高,受到品質、施工人員的技能與身心靈狀態、工作項目大小、需求不確定性等因素影響,導致需要控制的因素很多,因而需要時時檢討人力、WIP的設置是否恰當,以及透過流程改善來讓工作流動更加順暢,降低交期(lead time)。

***

友藏內心獨白:小批量生產與消除變異性。

2019年5月28日 星期二

不要只聽半套

May 28 23:11~23:54

▲這句怎麼都沒人聽進去XDD


故事一

有一個公司派了整個團隊來泰迪軟體上Scrum敏捷方法實作班,回公司之後團隊跑了一陣子Scrum。有一天因為產品出了包,非常緊急,Product Owner希望團隊加班趕緊把這個問題解決。沒想到,團隊中有成員居然回答PO:「我們去上Teddy的課,Teddy說跑Scrum不能加班。」

公司老闆得知後非常氣憤,有一次遇到Teddy,用開玩笑的語氣說:「我員工去上你的課,回來之後都不加班了」。

這,員工不想加班就大聲說「我不想加班」,幹嘛扯到Teddy頭上哩?!Teddy上課時是說:

敏捷開發講求「穩定的開發步驟」(sustainable pace),早期XP對於穩定開發步驟有一個簡單的說法,就是每週工作四十小時。我自己還在與Scrum團隊的時候,也是儘量利用上班專心把工作完成,以不加班為原則。

假設公司因為產品出問題都火燒屁股了,作為員工此時還在「我跑敏捷我不加班」,如果Teddy是老闆,也會發火啊。古語有云:「善戰者無赫赫之功」,這也是好的敏捷團隊期望達到的狀態。但是,天有不測風雲,總是會遇到需要「江湖救急」的時候。此時願不願意跳下來解決問題,就不是敏不敏捷的問題,而是心態的問題了。

***

故事二

某PO質問Teddy:「為什麼你跟團隊成員說retrospective沒用?」聽到這樣的質問,Teddy也是滿頭黑人問號???

細問之下,原來是Teddy和團隊成員聊天時提到:

如果retrospective會議沒有訂定具體的改善執行計畫(action plan),或是改善計畫都沒有落實,相同的問題便會一再出現,導致每次retrospective都討論一樣的議題。有迭代沒有增量,久了之後團隊就會覺得retrospective沒有用。

不知道這位團隊成員是不是buffer不夠,只擷取到「retrospective沒有用」這幾個字。也未免斷章取義的太厲害了一點吧。

***

問題是自己狀況的投射

相信很多人都有這樣的經驗,聽了一場演講,或是經過一次對話,腦袋中留下來最深刻的只有「與自己現況不滿相關的記憶」。因為這些不滿的力量非常強大,強大到足以「扭曲力場」,把別人的意思曲解成自己的內心獨白,然後採用「借刀殺人」的手段,將自己一直想說卻不敢說出口的話,假借「別人的名義」說出來。

這種斷章取義、扭曲本意、沒有脈絡(context)的引用,並非全無意義。它往往透露出講話者內心真正的感受,只不過平常不敢說出來罷了。

為什麼敏捷開發的始祖XP要提「勇敢」?因為太多人不敢面對自己,不敢正視問題。真、善、美,只有真誠的表達自己的感受,改善才有可能發生。只有改善發生,才有可能逐步趨近完美。

***

友藏內心獨白:Teddy有說多讀書你怎麼都沒聽進去?!

2019年5月24日 星期五

一個Scrum各自表述

May 24 00:40~01:27

▲每個component team都在跑Scrum,啊不就好棒棒…Orz


沒事不要找Teddy聊天XD

去年在某個演講場合,演講結束後某位鄉民找Teddy聊天….

鄉民:Teddy你好,我是你部落格的忠實讀者。

Teddy:你好、你好,謝謝捧場。

Teddy:你看我的部落格,是因為你們有跑Scrum嗎?

鄉民:對,我在用戶研究團隊跑Scrum。

Teddy:喔……用戶研究團隊跑Scrum…..這麼神奇。這是什麼意思?

鄉民:就是我們團隊會在專案開始前期用迭代、增量的方式,跑幾個sprint產出用戶研究報告。

Teddy:然後把產出的報告交給開發團隊去實作?

鄉民:對。

Teddy:怎麼我聽起來好像是瀑布式開發?

鄉民:不是、不是,我們是跑Scrum。

Teddy:你們做出用戶研究報告交給開發團隊之後,需求都不會改變嗎?

鄉民:會啊。

Teddy:那之前花時間所做的用戶研究報告需要重做嗎?

鄉民:這……….

Teddy:你們就是waterfall啊。

鄉民:我們是Scrum啦……至少在公司內我們要說我們在跑Scrum。

Teddy:那你們當初為什麼想「跑Scrum」?

鄉民:因為總經理下令說要跑Scrum。

Teddy:喔,對、對。幾個月前我有看過你們公司發的新聞稿,說你們Scrum跑得很成功。


▲有功大家練,有敏大家捷。

***

高興就好

▲圖片來源在此


陳近南:反清復明 敏捷只不過是個口號,跟阿彌陀佛其實是一樣的。Waterfall一直欺壓我們公司,浪費我們的銀兩,所以我們要反Waterfall!

韋小寶:要反Waterfall搶回我們的錢,是不是?說來說去敏不敏捷根本就是脫褲子放屁!關人鳥事呀?行了,大家聰明人,了解!繼續!

陳近南:嗯。總之,如果成功的話,就有無數的銀兩,你願不願意去呀?

韋小寶:願意~!只不過你剛剛那句九死一生太嚇人了。

***

友藏內心獨白:敏捷就是專案出得去,錢進得來,公司發大財XD。


2019年5月20日 星期一

2019 iMac 27吋開箱

May 20 20:58~22:31


Teddy手邊2016年購買的MBP 15”用了兩年半,已略顯老態。平常上網、文書處理是沒什麼問題,但只要同時開啟Parallels與IntelliJ,加上數十個分頁的Chrome,整台電腦跑起來就會有點卡卡的。

今年決定不要再買筆電,改買桌機。本來考慮iMac或是Mac Pro,但Mac Pro遲遲未上市,最近寫程式的頻率比較高,等不及Mac Pro決定先買2019年iMac。


▼美國今年三月就上市,台灣等到五月七日才開放訂購。這次狠下心來攻頂,購買最高階i9版本。


▼記憶體選擇最基本的8GB,自己另外購買4條OWC 32GB RAM,擴充為128GB。


上禮拜六(5/18)11點多iMac送到家裡,但我人卻在台南。隔天下午回台北後,趕緊開箱。


▼打開後包裝很簡潔。


▼把螢幕撲倒準備加裝記憶體,後來發現其實螢幕立著也可以裝記憶體,不用撲倒。


▼連接電源線的位置有一個按鈕,用十字起子用尖尖的東西刺一下,記憶體被蓋就會彈出。


▼兩條內建的4GB記憶體。


▼鍵盤、滑鼠、觸控板。原本考慮是否要買附數字鍵的鍵盤,但顧及桌面空間,以及之前已經用了六年多的無數字鍵的鍵盤也還算習慣,最後還是選擇無數字鍵鍵盤。這一代的鍵盤、滑鼠、觸控板都內建鋰電池,可以直接充電,方便很多。


▼開機後開始設定。


▼2019 iMac 27” 可以安裝128GB記憶體,Apple Store最多只可客制到64GB,而且價格比自己到外面購買要貴一倍。如果需要擴充記憶體,還是自己動手比較省錢。


▼因為經常需要使用Windows,此次特別買了專業版的Parallels,可以設定比較大的記憶體給VM使用。

***

剛拿到iMac兩天,目前只有一個問題,就是iMac不能調高低,Teddy覺得iMac螢幕高度太高,和以前使用的螢幕高度比較來脖子要稍微抬高,有點不舒服。

桌機的速度還是比筆電快很多,價格也比較便宜。像Teddy這種使用習慣,應該老早買桌機才對。只要搭配一台輕巧、長效的Windows筆電外出使用即可。

***

友藏內心獨白:爽度破表XDD。

2019年5月14日 星期二

三小故事之這不是多型,什麼才是多型

April 14 09:55~10:33

▲貓也是多型的生物


多型的定義

一個訊息的含義,是由訊息接收者所決定,不是由訊息發出者所決定。

***

故事一

幾年前有一個外商網通公司的HR找Teddy去他們公司擔任半年的Scrum Master。當時因為有顧問案在身,只能婉拒。

HR退而求其次,希望Teddy幫他們介紹合適的人選。Teddy請對方提供徵人資格條件,看了之後Teddy委婉的說:「你們要求的標準很高啊!」。沒想到對方居然說:「對啊,我覺得好像在找聖人一樣。」

這個故事Teddy講過好幾次,主要是要強調「好的ScrumMaster難尋」。沒想到有一次跟客戶講到這個故事,對方好幾個人居然異口同聲的說:「Teddy你是說你是聖人嗎!」

冤枉啊,包大人。小的從來都沒這麼想。也許客戶是跟Teddy開玩笑,不過還真沒想到這個故事可以被這樣解讀啊。

***

故事二

好幾年前在一個介紹Scrum的演講中,休息時間有聽眾問Teddy…

聽眾:在跑Scrum的時候怎麼設計軟體架構?

Teddy:這個問題很多人都有疑惑,我以前去上Bas的CSM課程也問過她同樣的問題。我問他,跑RUP會建議在elaboration階段產生architecture baseline,跑Scrum要怎麼設計軟體架構?

聽眾:他怎麼說?

Teddy:他反問我…什麼是architecture baseline?

聽眾:你是說Bas不懂軟體架構?

Teddy:不是啦,我是說,Scrum根本不管這些,跑敏捷的人會告訴你,軟體架構是長出來的,不是事先設計出來的。該怎麼長就怎麼長,你自己慢慢長吧你XD。

怎麼會解讀成Bas不懂軟體架構哩…

***

故事三

有一次在 C C Agile介紹TDD/BDD/SBE,Teddy提到…

很多TDD的例子,都有兩個特色。第一,domain model很簡單,只有1~2個類別。其次,都有非常清楚的商業邏輯, 這樣子學習者才可以在很短的時間內體驗TDD。例如,保齡球計分、網球記分、電子商務系統結帳計價、郵寄系統。

但是,回家之後發現,自己手邊的案子,domain model都很複雜,商業邏輯不太清楚,所以都D不太出來。

結果回家後,有鄉民又私下問Teddy…

鄉民:Teddy你剛剛是在暗指XXX的TDD例子都太簡單對不對?

Teddy:XXX?你說Uncle Bob嗎?我又沒上過他的課怎麼會知道他的例子長什麼樣子。

Teddy:我只是想指出,快速學習TDD所用的例子,和實際工作上會遇到的專案,有一些距離。而這些距離需要被克服才可以落實TDD,你想到那裏去了。

鄉民:!#!@$%

***

結論

年輕的時候,很怕被「誤會」。只要覺得別人誤解自己,就好像受到天大的冤屈,恨不得找包大人來主持公道。從某種角度看,這是一種沒有自信、缺少歸屬感的表現。

幾年前讀了幾本哲學、禪的書,越發體會Quality Without A Name 的道理。反正不管是真話、假話都無法驗證,那就不用管那麼多,全心專注在 Quality 上面。用自己的生命去展現這個 Quality,然後只要加強被討厭的勇氣就好了 XD。

***

友藏內心獨白:你今天被討厭了嗎XD。

2019年5月7日 星期二

尋找第一個Pattern

May 07 14:11~15:07


很久以前有一次Teddy在某場合介紹Alexander的pattern languages,談到這個方法是一種「由上而下」的設計過程,透過一次套用一個pattern(one pattern at a time)的方式逐次展開,採用pattern為基礎的方式解決一個大問題。就好像人類使用「語言」解決問題一樣,Alexander把這種方法稱為pattern language。

聽完演講之後有一個聽眾問我:「要如何選擇最上層的第一個pattern?」當下Teddy心裡覺得:「啊不就是你書讀得少,pattern認識沒幾個,所以才不知道要如何選擇第一個pattern。」

事實上Teddy的想法並不完全正確,對方也許真的不熟pattern,但這個問題首要的重點不在於對方懂多少個pattern,而是「最上層的第一個pattern,就是你要解決的那個大問題,也就是你想要達到的目標 (goal)」。


***

設計模式的例子

 

▲Mediator範例


上周末在上【Design Patterns這樣學就會了:進階實作班】,討論到Mediator模式的時候有學員問…

學員:如果Mediator的coordinating logic太複雜,我是不是可以把 Mediator + Strategy或是Mediator + Command混和一起使用?

Teddy:你先不要把問題複雜化,想著把A模式加B模式結合起來的可能性。「理論上」很多模式可以被「一起使用」,但如果只從解決方案來看設計模式,你會有太多排列組合都可以達到「相同功能」。這樣子學習者會無所適從,不知道怎麼套用pattern解決設計問題才合適,很容易變成為了套pattern而套pattern,變成過度設計(over design)。

Teddy:你要先問自己「目前你首要想解決的設計問題是什麼?」以Mediator的例子來看,因為你想拿掉Colleague與Colleague之間多對多的相依性,所以找一個中間人來負責協調與溝通。此時此刻,根本還沒有「Mediator的coordinating logic太複雜」的問題,所以不需要討論Mediator + Strategy或是Mediator + Command的可能性。

Teddy:當你套了第一個Mediator pattern,過了一段時間後,你發現coordinating logic太複雜。這個複雜性已經強大到讓你修改coordinating logic變得很困難,你的軟體慢慢變成了硬體。此時,你再來考慮要採取什麼方式來對付這個force。

一次一個pattern,第一個pattern解決你目前首要凸顯出來的問題。套完第一個pattern之後,如果沒有其他未被處理問題,那就沒事了。如果還有(例如Mediator的coordinating logic變得太複雜),你再進一步思考要如何解決。

***

道理很簡單但你不一定能活用

幾年前有一次到客戶端幫忙看Scrum團隊運作情況,客戶覺得他們跑的卡卡的,劈哩啪啦跟Teddy描述一大堆「可疑現象」。經過Teddy實地觀察之後,發現問題的確並不單純。

要從何開始著手?如果用pattern解題的方式來思考,要先套用哪一個pattern?

Teddy發現客戶的Scrum團隊最大的問題就是他們並不是真正的跨職能團隊(cross-functional team),團隊成員主要都是程式設計師,沒有測試專長的人,也沒有UI/UX的人。上游(UI/UX)的步調搭不上下游開發團隊的步調。經常發生UI/UX自己覺得效率很好,但他們完成的工作,開發團隊可能好幾個sprint之後才會用到,甚至也有完全沒用到的時候,最後直接丟到「垃圾桶」。

伴隨著這個根本原因,團隊產生了很多病症,必且試圖用各種有創意的方式來延緩這些病症,但都無法長期維持下去。

其實這個問題很簡單,先讓自己笨一點,既然是跑Scrum,為什麼不直接聽Scrum的話,組織一個真正的cross-functional team,先傻傻套用這個pattern「試看看」。套用之後,跑一陣子,如果有其他的問題浮現,再思考要如何解決。例如,之後可能發現需求管理很困難,團隊對於產品願景與sprint目標不明確,此時再討論嘗試套用impact mapping與user story mapping的可能性,才顯得有其意義。

***

友藏內心獨白:這麼簡單的道理居然這麼久才想通啊。

2019年5月1日 星期三

把你當作大學生

May 01 08:49~09:26

▲小屁孩時期的Ada


不打不成器

Teddy念國中的時代,體罰尚未被禁止。只要考試沒達到標準,吃板子是很常見的「改善執行計畫」。國二那年分班,新的國文老師是一位中年男士,身材略胖,學生幫他取個外號,叫做「大番薯」。

這位國文老師很「奇葩」,他幾乎不體罰。學生知道老師不打人,於是上課態度就比較隨便,考試成績也沒有表現很好。有一天,班導師語重心長地告訴我們…

班導師:國文老師把你們當成「大學生」對待,希望你們讀書要自動自發,不需要人家打你才讀書。大家不要欺負國文老師,不打人就不讀書。

班導師的一番話,並沒有感化太多學生。國中小屁孩,哪知道大學生是怎麼讀書的(以前的大學生應該比較認真,如果是現在的大學生就另當別論)。反正「沒有forces就沒有問題」,哪一科不打人,就輕鬆一點混過去就好。

***

為自己讀書

「把你們當成大學生對待」,一直到Teddy念碩士班之後,才慢慢體會這句話的真義(因為Teddy沒機會念大學XD)。學習、讀書,本當是個人的責任。學校、老師提供一個情境(context),讓學生有機會成型。至於成為哪一種形狀,只能由學生自己決定。

出社會之後,因為工作繁忙,有許多人的學習模式變成找名師。希望獲得名師加持,不須自己努力,就可以立刻頓悟。這種想法,很容易被利用。名師沒找到,詐神倒是遇到不少

有些學生,希望老師直接給他一個可以學習(抄襲)的例子,而不去管背後的理論基礎,也不去讀書。好像學會例子就可以快速變成該領域的專家,但這是不可能的,至少Teddy還沒發覺這種可能性。

真正把一門學問弄懂,除了找很多例子,也需要讀很多書學習背後的理論基礎。光看例子,很容易被例子所侷限,離開例子的脈絡就無法靈活運用。這種學習,不算真的學會。

***

結論

Specification and Example,Tell and Show,兩者相輔相成,缺一不可。

***

友藏內心獨白:我只有撿到貓。