l

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。

沒有留言:

張貼留言