l

2017年5月26日 星期五

當Pattern遇到Scrum(1):Daily Scrum

May 26 00:58~02:30; 13:00~13:42

屏幕截图 2017-05-26 01.25.01


四月Teddy跑去葡萄牙、西班牙「考察」了十幾天,回國後忙著上課沒時間寫部落格。五月家裡有些事要處理,所剩的其他時間都拿來寫程式,也沒心思寫部落格文章。眼看五月即將結束,本月份部落格「產能」少的可憐,還是想辦法擠點東西出來。

Teddy在北科資工所兼任五年「軟體生命週期管理」課程,今年是最後一次教這門課,明年春天改教「軟體架構」。衝著最後一年特別紀念,今年改了新的上課方式,先用一半的時間講BDD/TDD,再用另一半時間講Scrum。以往教Scrum會請學生跑3~4個sprints開發一個專案,今年原本也是計畫如此,但今年修課的全部學生在實驗室做計劃的時候都已經在跑Scrum,在課堂上再跑另一個Scrum專案意義不大,於是幾個禮拜前決定用其他的方式來介紹Scrum。

這禮拜四上課前一天傳了〈Daily Scrum〉pattern給學生,請他們先把這個pattern讀過。禮拜四上課Teddy告訴學生如何用pattern的角度來理解Scrum,先從大家都很熟悉的Daily Scrum這個活動開始。

***

步驟1:找結構

Teddy把〈Daily Scrum〉pattern印出來,給學生20~30分鐘的時間,用筆圈出pattern的六大元素:

  • Name
  • Context
  • Problem
  • Forces
  • Solution
  • Resulting Context

***

步驟2:找問題

找出 〈Daily Scrum〉pattern六大元素之後,優先思考Daily Scrum要解決什麼問題。以下是 〈Daily Scrum〉pattern原文中對於problem的描述:

The team makes progress in a Sprint by finishing Sprint Backlog Items, but given the complexity of the work, the characteristics, size and quantity of tasks change frequently — sometimes minute by minute.

Teddy請學生練習把problem改寫成一個問句。下圖是學生所整理出來的各種problem問句,經過學生投票之後選出票數最高的描述為—Problem:如何在最短的時間內理解需求並揭露可能發生的阻礙?

屏幕截图 2017-05-26 01.31.51

***

步驟3:找解法

接下來請學生找出 〈Daily Scrum〉pattern的解法,以下是 〈Daily Scrum〉pattern原文中對於solution的描述片段,只要看Therefore之後第一個粗體字的句子就好—Solution:Have a short meeting every day to replan the Sprint. Strictly time-box the meeting to keep focus on the daily plan and to avoid robbing time from development

屏幕截图 2017-05-26 01.39.32

***

步驟4:修正問題

現在把剛剛整理好的problem-solution拿出來一起看,請學生判斷一下剛剛整理的problem有對應到solution嗎?

Problem:如何在最短的時間內理解需求並揭露可能發生的阻礙?

Solution:Have a short meeting every day to replan the Sprint. Strictly time-box the meeting to keep focus on the daily plan and to avoid robbing time from development

經過一番討論之後,學生整理出第二版的problem:

Problem(v2):如何有效率地重新計畫Sprint?

***

步驟5:找Forces

下一個步驟請學生把forces找出來。剛剛才發現忘了拍學生找出來的forces,只有把forces寫在黑板的照片…Orz。

屏幕截图 2017-05-26 01.49.24

直接講結論,經過投票之後留下三點forces

Forces:

  • Alternative solutions, needed but unknown knowledge, hidden tasks, misunderstood requirements, requirements requiring further elaboration, dependencies among developers, or problems in the form of blockages may emerge in the team's day-to-day work.
  • Too much re-planning and re-estimating wastes time and suffocates developers. But too little re-planning and re-estimating leads to blockages that cause delays or obsolete plans that no longer represent reality.
  • An individual may need to bring up an issue to the team. But it may be difficult to find an opportunity to do so. In particular, issues continue to be impediments until they are fixed.

***

步驟6:解法是否有呼應Forces

把剛剛整理出來的結果重新整理一下,接著請學生判斷solution是否有呼應這三點forces?

Problem:如何有效率地重新計畫Sprint?(How to keep your Scrum plan up-do-date?)

Forces:

  • Alternative solutions, needed but unknown knowledge, hidden tasks, misunderstood requirements, requirements requiring further elaboration, dependencies among developers, or problems in the form of blockages may emerge in the team's day-to-day work.
  • Too much re-planning and re-estimating wastes time and suffocates developers. But too little re-planning and re-estimating leads to blockages that cause delays or obsolete plans that no longer represent reality.
  • An individual may need to bring up an issue to the team. But it may be difficult to find an opportunity to do so. In particular, issues continue to be impediments until they are fixed.

Solution:Have a short meeting every day to replan the Sprint. Strictly time-box the meeting to keep focus on the daily plan and to avoid robbing time from development

第一個force說很多事情做了之後才會知道,所以即使團隊已經舉辦了sprint planning meeting,當sprint開始執行時,sprint backlog的內容就已經過期了。Solution建議每天舉辦一個會議來重新計畫,所以呼應了第一個force。

第二個force說太多重新計畫與重新估算會讓開發人員受不了,但太少也不行。Solution建議每天舉辦一次固定時間(15 分鐘)的會議,呼應了第二個force。

最後一個force說開發人員想提出議題討論,但很難找到合適的機會。例如大家都很忙,不好意思中斷所有人的工作,因此導致問題拖比較久才提出來(有開週會的團隊應該會有這樣的經驗,有人禮拜一、二就發現問題,但一直等到禮拜五開週會的時候才提出來)。藉由每天舉辦Daily Scrum,這個force也被關照了。

***

回答常見問題

姑且不看Context與Resulting Context,光是從Problem、Forces、Solution就可以回答一些常見有關Daily Scrum的問題,例如:

  • Daily Scrum一定要站著嗎,能不能坐著、趴著、躺著:Daily Scrum的預設版本是一種站立會議(Standup Meeting),其目的是為了呼應第二點force。如果你的Daily Scrum採用坐著甚至是趴著也可以達到相同的目的,也沒有什麼不可以(但請先思考一下為什麼預設方式會建議用站著,並確定感變形式之後原本的force真的還是有被關照到而不是讓force失去平衡)。
  • Daily Scrum一定要在實體Task Board(Scrum Board)前面嗎,能不能用電子Task Board:Scrum的Task Board是一種視覺化的計畫(或重新計畫,re-planning)工具,敏捷開發有一種說法:「Low tech, high touch. High tech, low touch.」。藉由在實體Task Board上移動task,以及作為一種information radiator(訊息發射器),實體Task Board很成功扮演者plan和re-plan的角色。同樣地,如果你確定改用電子Task Board之後原本的force仍然獲得平衡,也並無不可。
  • 一定要同步式的Daily Scrum嗎,能不能用非同步的方式進行Daily Scrum:同步或非同步的議題和第三與第一個force有直接的關係。標準版Daily Scrum要求舉辦會議需要在同一時間、同一地點、固定長度。團隊在相同時間聚在一起,除了提供一個儀式性的活動讓大家有機會可以提出各自的議題,面對面溝通也可以比較快速做出許多決定。但是,有些團隊分散在不同地點、不同時區,有可能不容易到一個大家都方便的Daily Scrum時間。在這種情況之下,使用電子系統,用非同步的方式更新自己的狀態以及想要提出的議題,也是常見的方式。但還是老話一句,原本Daily Scrum形式想要面對的forces在採用新的形式之後這些force是否依舊被照顧得好好的。如果沒有,就必須考慮改變之後的做法是否合適,或是要再套用其他pattern把沒平衡好的force好好地照顧一下。

***

Scrum是一種流程框架,身為一個框架自然有很多可以讓人 上下其手 自行調整的空間。調整不是問題,因為每個公司、專案、團隊都不同,也就是說套用Scrum的情境(context)不一樣,自然會衍生出不同運行Scrum的形式(solution)出來。在調整的過程中,抽象的來說要注意調整後的做法是否還是符合Agile與Scrum精神。具體一點來看,原本Scrum設計的活動、角色與工件所要關注的作用力(forces),在調整新的做法之後「宇宙原力」是否依然保持著平衡 (觀察resulting context)。平衡性越高,解決方案就越合適(fit)每個人所處的情境。

***

友藏內心獨白:還有很多pattern可以練習喔。

2017年5月11日 星期四

Scrum的味道

May 11 01:32~02:41

屏幕截图 2017-05-11 02.40.12

▲半夢半醒之間

 

一年多前有某美商台灣分公司想找Teddy去當半年的ScrumMaster,當時因為還有另一個案子走不開,加上Teddy也不認同從外面抓一個人到團隊中當ScrumMaster的做法,所以案子就沒有談下去。後來他們四個Scrum團隊的成員分次陸陸續續來上泰迪軟體的Scrum和看板課程。上禮拜日Scrum課程結束後,他們公司的一位團隊主管留下來跟Teddy聊了一個多小時。他分享了這兩年來他們跑Scrum的經驗以及遇到的問題和各種嘗試的解決方法。雖然他覺得還是有很多可以改善的地方,但Teddy認為兩年的時間可以做到這種程度已經很棒了。

在聊天的過程中,Teddy腦袋中不斷地回想起這幾年來曾經接觸過的人、團隊和公司。今年七月二日泰迪軟體成立就滿五年了,這五年來有幸遇到很多對於敏捷開發,特別是Scrum,有興趣的朋友。在這其中有實際跑Scrum很成功的,有付出努力還在期待看到成果的,有跑過之後放棄的,有放棄之後還想跑的,有單純默默圍觀看熱鬧的,當然也有在旁邊「喊燒」意圖使人覺得自己好棒棒但根本沒什麼實際經驗的。漸漸地你會發現,比較成功的團隊具有相似的「好味道」,而還有很大成長空間的團隊也有不少共同的 「怪味道」。

常見的好味道包含:

  • 老闆(高階主管)的支持:Scrum,或更廣義的來說,敏捷方法,是一種需要改變思維、改變行動、改變組織的持續改善活動。改變就表示「和以前不一樣」,衝撞現有體制與行之有年的做法勢必遭遇到許多阻礙。如果沒有老闆或高階主管的支持,在變革的過程中一旦達到個人或團隊權限範圍邊界的時候就很可能卡住,以至於無法顯現出理想中的成效。
  • 有guts的ScrumMaster:改變現狀一定會遇到很多阻礙,作為落實Scrum的「觸媒劑」,一個好的ScrumMaster扮演著十分重要的角色。下圖節錄自《Essential Scrum》,說明ScrumMaster在兩周的sprint進行過程中,不同活動所佔的比例。除了第一天與最後一天參加會議以外,其他時間impediment removal(阻礙排除)佔了ScrumMaster最多時間。雖說Scrum團隊是自組織團隊,但在團隊達到這個目標可以自行解決與排除大部分阻礙之前,一個有guts的ScrumMaster可以幫忙排除阻礙(幫忙不等於自己動手做),對於初期Scrum的順利推行扮演著非常重要的功能。反之,一個沒有發揮作用,只會以「Scrum團隊是自組織團隊」為藉口把所有事情推的一乾二淨的ScrumMaster,則是許多失敗團隊的共同怪味道。

屏幕截图 2017-05-11 01.46.58

  • 平衡業務與技術的工作內容:專案的價值來自於「產品作對(Do the right thing)」、「品質做好(Do the thing right)」,兩者取得平衡專案或產品才可長可久。站在老闆或高階主管的角度,對於Scrum的期望很可能是「快」,希望產品可以及時上市搶得市場先機,但他們對於技術面如何支持「快」則興趣缺缺。反之,開發團隊雖然也需要關注業務目標,但實際上既然身為技術人員,他們的內心中更重視的則是技術精進所帶來的可能價值(例如做出高品質產品)與成就感,至於產品能不能賺錢則比較無立即感受。好的團隊不會偏向任何一者,因為只重視速度和只重視品質都是一種「區域優化」的思維,沒有關注全局。從業務面與軟體生命週期的角度來看,唯有 宇宙原力獲得平衡 長期保持兩者平衡(短期可能業務面多一點或技術面多一點,但長期來看要兼顧兩者),才不至於造成優秀的開發人員跑光(只關注業務不在乎技術)或公司賠錢甚至倒閉(只管技術不在乎業務)。
  • 一步一腳印解決問題的團隊:Scrum期望團隊可以自組織、自我管理,這麼大的一頂帽子戴下來,不是每個人都可以承受。現實世界中專案的問題那麼多,需求、時程壓力、客戶、公司政治、開發能力、人員互動等,在以往每個人各做各的,可以假裝不去面對。Scrum身為一面忠實的「照妖鏡」,將問題暴露出來。有些人無法接受選擇繼續裝睡或假裝被喚醒(夢遊狀態?),有些人受不了把鏡子打破(不跑Scrum)。成功團隊則是堅持持續改善精神,腳踏實地解決問題。

***

以上是Teddy觀察到的Scrum好味道。至於怪味道,有機會遇到你的「鼻子」自然會告訴你。

***


友藏內心獨白:鼻子不通就聞不到味道了。

2017年5月8日 星期一

無我(2)

May 07 23:11~00:00

屏幕截图 2017-05-08 00.02.37

▲吃飯的時候真的目中「無我」啊XD

 

Teddy有兩位只有「一面之緣」的Facebook好友,在此稱為小明和小美,他們兩位在現實世界中彼此熟識,有工作上的往來。

有一天在Facebook上看到小明不斷地在抱怨小美,大概就是指責小美在一件工作中搶了他的功勞,讓小明非常氣憤,到最後兩個人絕交。

針對小明的指控,小美在網路上倒是沒什麼激烈回應,一副「清者自清」的態度。

作為一位圍觀的鄉民,Teddy原本覺得小明好奇怪,怎麼為了一件小事吵成這樣,而且公開嗆聲好像也解決不了問題,只是在拉取同情票而已。

***

幾個月之後,在一個偶然的機會中,小美請Teddy幫他review他的某個設計作品。後來在某個場合中,小美對他人說:「我的那個作品獲得不錯的評價,客戶也很認同我作品的價值……..」。

當時Teddy人就在「犯罪現場」,聽完小美對其他人所說的話,友藏心中覺得:「耶,你那個作品要不是我幫你review還給你那麼多修改的意見,根本離堪用還差一大截好不好。怎麼,過河拆橋啊,我人都在現場你也好意思提都不提我幫你review這件事。」

此時Teddy才想起小明在Facebook上對於小美的指控,大概就是這種感覺吧。

***

但是,當下信念一轉,想說:「噯呀,當初答應幫小美review,本來就是出自於希望他的作品可以更好。現在這個目的已經達到了,對方有沒有提起自己,其實一點也不重要,根本無須有任何情緒上的反應。」

***

自己的價值,如果要靠「別人來證明」,日子會很難過。

***

友藏內心獨白:知識只會越用越多。

2017年5月5日 星期五

魔戒

May 04 15:41~16:37

屏幕截图 2017-05-04 16.23.21

▲  畫面節錄自Google搜尋結果

 

電影《魔戒首部曲:魔戒現身》有一個橋段,佛羅多一行人來到黃金森林,當天晚上佛羅多被黃金森林女王凱蘭崔爾引到一個大水盆邊。佛羅多從水盆中看到魔戒遠征隊分崩離析的未來,他一時承受不了告訴凱蘭崔爾說:「只要妳開口,我就把至尊魔戒給妳。

此時凱蘭崔爾說:「我不否認內心對於魔戒的強烈渴望,黑暗魔君將被取代,世界將迎來一位女王。」

話說完之後凱蘭崔爾突然整個人發光,聲音和臉孔都扭曲起來,狀似快要發狂的樣子。幾秒後她平靜下來,並說:「我通過了測試,我將離開退隱西方,繼續當凱蘭崔爾女王。」

***

Teddy當年看電影的時候覺得好奇怪,妳都身為黃金森林女王,官位如此之高,如果覺得魔戒不應該拿就不要拿,為什麼還要上演這段「總統拒拿紅包表示自己很清廉」的橋段哩?

幾年後讀了《你要如何衡量你的人生?:哈佛商學院最重要的一堂課》這本書,書中提到透過三個問題來檢視自己的人生:

  1. 如何知道我的工作生涯可以成功、快樂?
  2. 如何知道我與配偶、兒女與朋友的關係可以成為快樂的泉源?
  3. 如何知道我這一生會堅守原則,以免除牢獄之災?

凱蘭崔爾女王遇到的課題就是第三條:「如何一生堅守原則,以免除牢獄之災。」經常在電視上看到公務人員因為收紅包或貪汙被起訴的案例,或是私人公司員工帶著公司機密跳巢到競爭對手公司,或是員工收取協力廠的的回扣。很多人都會說:「真是該死,為了一點點錢(有時候是很多錢)葬送自己的前途,要是我才不會那麼笨。」

實際情況很可能並不是你比較聰明或操守好,而只是沒有人要送錢給你。當一個人沒有機會貪汙的時候,當然看起來就很清廉。但是一旦白花花的銀子擺在你面前,又有多少人可以大聲的說不?!這種事,沒有發生永遠都不知道。所以凱蘭崔爾女王才會在「魔戒自己送上門來卻能控制住自己不拿」的情況下,說出「我通過了測試」。

***

電影中的「魔戒」是一種象徵,每一個人的生命中,或多或少都有遇到「魔戒」的機會。小到「警察不在的時候要不要遵守交通規則」、「撿到別人的錢包要不要還」、「蓋棉被是否能夠純聊天」,大到「有官商勾結的機會能不能守住底線」。唯有真的發生的當下自己做出選擇,才是判斷是否通過測試的唯一標準。

***

友藏內心獨白:很多人的出發點都是想拿魔戒作好事啊。

2017年5月4日 星期四

你的抄襲有包含學習嗎?

May 04 04:35~17:26

屏幕截图 2017-05-04 04.42.23

 

前兩周花了五個小時的上課時間review同學的程式作業,這學期只有七個同學修「軟體生命週期管理」,人數很少所以可以利用上課時間詳細的和學生討論程式內容。經過兩周「地毯式」的討論,發現全班七個人所寫的程式可以分成三大類,人數分布剛好是2-2-1。前兩個分類裡面的兩位同學,只要把類別名稱重新命名一下,程式的結構基本上是相同的。

發現這個現象之後Teddy開玩笑地說:「被我抓到抄襲了喔」。聽到抄襲二字學生奮力反駁,表示程式雖然看起來有點像但是內容細節有許多不同之處。

Teddy告訴學生:

「其實我一點也不在乎你們是否抄襲同學的程式作業,因為『抄襲』本來就是軟體開發不可分割的一部分。寫程式遇到問題的時候怎麼辦?就拜一下Google大神或到Stack Overflow上找資料,然後把找到的範例程式直接複製、貼上,最後略做修改變成自己軟體的一部分,這是很正常的行為。就算你抄襲同學作業甚至請同學幫你寫(一種外包的概念!?)都沒關係,只要你有能力可以在我跟你review作業的時候解釋你的程式為什麼這樣設計並且沒被問倒就可以了。否則,就算全部的程式都是你寫的,看起來也可以動,但你卻無法回答為什麼要這樣做,那也是白搭。」

***

以前念書的時候有些程式設計課程的助教很負責,改作業時會特別用心抓抄襲,而且非常自豪自己抓抄襲的功力高強。但現在想想如果抄襲行為可以經過加值之後「升級」成為一種學習,也沒什麼不好。從學術的角度來看,給定出處的「抄襲」就叫做「引用」(引用是否合理另當別論)。從學生學習的角度來看,最大的問題應該是在於傳統上班級人數太多,以及老師、助教 能力 時間有限,所以無法一對一當面檢視學生的程式作業(加上學生自己也不長進XD),只好透過間接的方式來打成績。這種「間接溝通方式」或「透過文件溝通方式」從敏捷開發的角度來看,都不是很好的學習回饋機制。但現實上逐一面對面review會花掉太多時間,Teddy光是和七位同學review一次作業就花了五個小時,的確是「成本很高」的學習方式。

學生抄襲作業問題不大,最大的問題在於過程中只有無腦抄襲,而沒有用腦學習。

***

友藏內心獨白:不要只當鸚鵡。

2017年5月2日 星期二

【Design Patterns這樣學就會了】入門與進階實作班(2017年6、7月)

May 02 10:11~11:21

IMG_2095

 

學習設計模式的難處

GoF提出的23個Design Patterns(設計模式)問世至今已經超過22個年頭,只要是從事軟體開發的朋友在工作上或多或少一定會接觸與使用到設計模式,不管是套用在自己的軟體設計上,或使用別人所開發的應用程式框架,到處都存在著設計模式。

Teddy從1997年開始接觸設計模式,至今也有20年的時間。剛開始自己是透過閱讀GoF的經典著作《Design Patterns: Elements of Reusable Object-Oriented Software》來學習,但因為這本書的內容讀起來讓人感覺「學術性質」的成分比較重,不是那麼容易讀懂。加上書中的範例只有程式片段,而且是C++和Smalltalk,更加深了學習困難。

▼GoF Design Patterns

image

 

後來陸續出版的設計模式書籍或是網路文章,提供了大量的程式範例。透過範例學習設計模式固然比較簡單,但是存在「建樹不見林」的問題,缺少對於設計模式性統化的全面性觀點雖然看懂了程式範例,但卻不知道要如何把設計模式應用在自己的專案。因此導致誤用設計模式,造成過度設計(over design)甚至是錯誤設計的問題。

***

從源頭了解設計模式

設計模式起源於建築師Alexander對於建築領域模式的研究,了解Alexander對於設計模式的定義與初衷,不但有助於學習GoF的23個設計模式,還可以輕鬆的判斷:

  • 套用模式的時機點。
  • 要如何套用模式。
  • 如何避免誤用模式。
  • 怎麼知道套用的設計模式已經足夠,避免過度設計的問題。
  • 套用模式的流程與步驟。
  • 如何套用設計模式重構既有系統。
  • 如何教導同事也一起使用設計模式。

 

***

設計模式這樣學就會了

Design Patterns這樣學就會了:入門實作班」與「Design Patterns這樣學就會了:進階實作班」從設計模式的源頭著手,在了解了Alexander的模式方法之後,讓你以前學習設計模式所遭遇的問題一掃而空。

上課實況參考:

螢幕快照 2012-12-14 下午10.45.02

從日常生活的例子當中,分組討論找出pattern的problem、force、solution。

螢幕快照 2012-12-14 下午10.47.02

動手練習寫出context、force與solution。

image
如果對寫程式不是很有把握的話,實作也可以採用pair programming的方式來練習喔。

螢幕快照 2012-12-14 下午10.54.33

***

報名優惠

本次課程的上課日期為6月3、4、10號(日、六、日)與7月22、23、29號(六、日、六)舉辦。為慶祝Teddy接觸設計模式滿20周年,特別推出:同時報名入門班與進階班可享定價69折優惠。

 

image

***

友藏內心獨白:機會難得,20年才一次XD。

2017年4月30日 星期日

分類是一門學問

April 30 21:56~23:20

屏幕截图 2017-04-30 23.19.59

 

Teddy的指導教授當年在美國念博士班的博士論文是研究「圖形識別」,而且是判斷一張圖中那些是直線、圓、橢圓這種基礎研究。因為這個關係Teddy在唸書的時候聽了不少學弟報告圖形識別領域的論文,論文的內容從來沒聽懂過,但依稀記得要辨識圖形之前需要先做「分類」(classification)的動作,例如把圖形中的訊號與雜訊分開來,才可以把資料丟給後面的演算法繼續處理。

有一次和指導教授聊天,他說「分類」在遠古時代對於人類就很重要,例如人類老祖先要能夠區分那些貝類可以吃,那些香菇有毒,如果分類錯誤吃到有毒的香菇可能連小命都不保。

以前從來沒想過「分類」這件事原來有那麼大的學問在,後來才意識到原來分類真的不容易,很多問題如果具備了分類的能力,答案也就呼之欲出了。

***

這幾天把去年買的《穀倉效應》讀完,幾個月前這本書經常出現在敏捷社群朋友的Facebook動態欄,因為書中所要傳達的觀點,像是「打破穀倉所造成的隔閡」、「系統性(全面性)的思考模式」、「從使用者的角度來重組協作關係」都直接展現在敏捷方法上面。例如敏捷開發經常提到的「跨職能團隊」、「交付end-to-end的價值」、「區域優化 VS 全域優化」等。

看完這本書之後Teddy覺得重點應該不是單純可以用一句「打破穀倉」就可以交代過去的,因為「打破一個穀倉勢必造成另一個穀倉」。以Scrum為例,把component team這個穀倉打掉組成cross-functional team,後者也是一個穀倉啊,只不過這個穀倉叫做cross-functional team,而敏捷開發的人認為cross-functional team這個穀倉是從交付對使用者價值的角度來重組協作關係,是一種比較好的穀倉。所以說,穀倉不死,只是以另一種形式存在。

Teddy覺得書中比穀倉更有趣的概念是「分類」(穀倉是一種分類的結果,和分類本身還是有點區隔),書中提到一個例子,在金融海嘯之前,西方的監管單位並沒有察覺到危機即將發生。其中有一個很重要的原因就是,很多新興的金融商品不屬於傳統監管單位的「分類」之中。傳統上監管單位注意銀行與對沖基金這種已知的金融體系,但對於「衍生性金融商品」卻不甚了解。

後來問題爆發之後,有人去研究原因,提出了影子銀行這個概念(分類),並分析由影子銀行所造成的金融投資其實高達數十兆美元。這是一個非常恐怖的金額,但在金融海嘯之前卻未被加以妥善監管。自從影子銀行被提出之後,很多人都採用這個分類加以研究,等於幫原本「未定義」的界線給了一個範圍。

***

影子銀行的故事讓Teddy想到另一個「設計模式(design pattern)」的故事。設計模式就是一種分類,許久以前有一位鄉民貼了一篇大陸同胞寫的文章給Teddy參考,作者是中國人,美國知名大學的電腦科學博士,專長好像是程式語言、編譯器之類的。這位大陸同胞提到GoF的23個設計模式根本沒什麼,就只是「取名字而已啊」,就好像「把空氣命名為空氣」,這有什麼了不起的嗎?

從「分類」的角度來看,取名字(分類)真的還是挺了不起的。現在回頭去看,Observer、Command、Visitor、Factory Method、State等設計模式,鄉民們可能會覺得很簡單啊,沒什麼學問,就好像現在回頭看影子銀行這個分類一樣。因為這些分類經過先人的努力,已經從未知變成已知,從隱性變成顯性。

穀倉效應》第七章敘述美國克里夫蘭臨床醫學中心打破穀倉的案例,Teddy認為其中很重要的一點就是如何用新的穀倉取代舊的穀倉。這種設計新穀倉的過程,是分類、取名字的過程!

***

友藏內心獨白:「設計就是決定form和context的界線」,這就是分類。