l

2020年5月13日 星期三

學習總在下課後

May 13 18:11~18:59

▲別人的水總是比較甜,江山易改,喵性難移。


行為是否改變

成立泰迪軟體這幾年,遇到企業內訓課程,有些HR問Teddy:「能不能幫忙在課堂上看看誰比較認真,或是出考卷作為訓練成果評量,這樣學生才比較會專心上課。」

這些事當然都可以配合,但我總是跟對方說:「我覺得最好的評量就是同仁上完課之後行為有沒有改變,考試、打上課成績,頂多就是因應公司規定滿足交差的形式要求。」

上完課之後行為有沒有改變,是一件需要後續追蹤的工作,也是一件耗費時間與金錢的工作,絕大多數的公司都覺得:「公司已經出錢辦教育訓練,上完課之後同仁應該就具備那種能力才對。」

除非課程內容難易度不高,否則要求學員上完課之後立刻變成高手是不太可能的事情。不可諱言,有些天賦異稟或是努力很久終於時機成熟的同仁可以在上課當下「開悟」,課程結束之後行為為隨之改變,但大部分的同仁可以藉由上課「獲取新知」就已經很不容易了,要求他們上完課後立刻可以排除萬難做出有意義且持久的改變,實屬不易。就好像看了場精采的電影,觀眾(同仁)在心中對劇情與演員的表現留下深刻印象。但要讓觀眾看完電影之後就變身為導演,可以開工拍戲,那還需要長時間的努力。

下課之後回到工作上,面對的又是現實問題,被一大堆代辦事項追著跑,如果沒有外力協助,光靠員工自己很難有辦法靜下來思考如何改善。與其花錢辦大量的訓練課程,還不如思考是否有可能把部分上課費用拿來找顧問、教練,在課程結束之後和團隊一起,協助團隊改變行為,並且將改變後的行為固定下來,變成新的工作方式

***

終身學習

奧修在《草木自己生長》提到:「知識是借來的,而學習是你自己的;知識是透過文字、語言、和觀念,而學習是透過經驗;知識總是一個結束,你知道了它,它就結束了;學習永遠沒有結束,它總是在途中;學習是一個過程…」

上課可以獲得知識(收集名詞),但學習必須靠自己,它是一個終身的過程。很多教育訓練成效不彰,因為來上課的人頂多只想獲得(收集)知識,而不想學習。教的人也只是講述知識,沒有鼓勵學習。

Teddy相信:「學習在下課之後才真正開始。」所以教學的主要目的,應該是讓學習者具備下課後持續學習的能力。為了達到這個能力,需要介紹基本的領域知識以及設計適合的體驗活動,讓學習者在一個比較輕鬆的情境下獲得這些知識與體驗。

***

友藏內心獨白:學習是軟體開發的瓶頸。

2020年5月12日 星期二

等一個人春天

May 12 14:25~15:50

▲浪浪也會自己生長。


緣起

Domain-Driven Design: Tacking Complexity in the Heart of Software》這本書出版於2004年,當時Teddy正在念博士班,忙著準備資格考與論文,根本不知道有這本書。後來好像曾經聽過DDD這個名詞,當時自己一直把它腦補成MDA(Model-Driven Architecture)。因為自己對MDA沒什麼好感,當然對DDD也就沒興趣 Orz。

***

一面之緣

2013年,在這本書出版9年之後,Teddy忘了在什麼機緣之下買了它。翻了翻書的內容,覺得:

  • Model-Driven Design和以前學過的OOAD(物件導向分析與設計)建domain model的內容大同小異。
  • Ubiquitous Language是一個新名詞,但是它目的和Alexander的Pattern Language很像—A common ground for communication,而且比Pattern Language還要簡單。

以上這兩個模式(Patterns)算是DDD的核心,先被Teddy給「鄙視」一番。繼續往下看,覺得比較「有用」的模式是:

  • Aggregate,將一群緊密相依的物件放在一起,這是一種人為的模組化單位,可以彌補一般程式語言在Package與Class之間的空白。
  • Context Map,表達bounded context之間的關係。

然後呢?就沒有然後了,書就被Teddy丟在一邊。

***

再續前緣

三年前指導教授想把他手邊的軟體架構這門課交給Teddy來教,Teddy參考了近10本軟體架構的書,最後選了當時剛出版的《Clean Architecture: A Craftsman's Guide to Software Structure and Design》。教軟體架構和DDD原本沒什麼直接的關係,因為實作Clean Architecture核心層(Entity Layer)需要建立domain model,而Teddy又不想只是使用原本OOAD的方法,想起DDD關於建立domain model的一些設計模式,於是又回頭探索DDD。

又過了一年,有一天Teddy在YouTube聽一個DDD演講,內容和講者是誰已經忘了,但是聽到一句ubiquitous language in code,好像被雷打到一樣,突然醒過來。這種感覺,就好像當年六祖慧能聽到金剛經的「應無所住而生其心」一樣,當下頓悟XD。

Alexander的pattern language使用對象是,人用它來設計住宅以及都市規劃。如果將pattern language應用在軟體開發上,則可以想像成套用了一群(數個)設計模式來解決一個大的設計問題,這也是原本Teddy對於ubiquitous language的看法。

但是,ubiquitous language不只是這樣。DDD的Model-Driven Design與Ubiquitous Language這兩個模式是一體兩面,如果只把它們應用在「概念層次」,只用來作為領域專家與開發團隊溝通的工具,那就只發揮了DDD一半的功力。還有另一半,而且是打通任督二脈的另一半,就是要將Ubiquitous Language表達在程式碼裡面。所以光是只談ubiquitous language還不夠,加上in code,才是畫龍點睛,才是幫佛像開光。

***

自然生長

Ubiquitous language in code,同樣一句話,當時的Teddy聽了有感覺,換成別人就不一定。就算是Teddy本人,如果早個幾年聽到這句話,也不一定有感覺。

奧修在《草木自己生長:禪的真隨》引用禪師齊內林的話:「靜靜地坐著,什麼事都不做,當春天來臨,草木就自己生長。」雖說「什麼事都不做」,實際上並不是「什麼事都不做」。而是以平常心,認真去做好每一件該做的事情

等到時機成熟,春天到來,草木自然生長。

***

友藏內心獨白:不能揠苗助長啊。

2020年5月11日 星期一

主要的事

May 11 21:34~22:49

▲愛是主要的,品種是次要的。


先因,後果

活到這把年紀,很多事情都看得比較開,執念也越來越少。但因為尚未悟道,還是有一些看不開的關卡,其中就是一個。

俗話說:「錢不是萬能,但沒錢萬萬不能」,沒人會嫌錢太多。Teddy自認對於賺錢的慾望相對而言已經保持在比較低的狀態,三不五時還會因為理念的關係推掉送上門的案子。但當生意比較不好的時候,雖然減少的收入完全不會造成生活困難,但心中還是不免會嘀咕一下,經濟成長率怎麼變負數勒。

這一陣子讀了奧修的《禪宗十牛圖》,書中提到(pp.168~170):

  • 非主要的事,你想要先確定它們,而你以為主要的事將會跟著來。要改變那種態度:先想主要的事,非主要的事就會跟著來。先想主要的事!什麼是主要的事?果並不是主要的,因才是主要的;別人並不是主要的,你才是主要的。
  • 比方說,人們認為如果他們能夠賺足夠的錢,他們就能夠快樂,但事實上事情並非如此。如果你很快樂,你就會很富有……一個快樂的人不可能不是如此。他或許沒有大的皇宮,但他仍是富有的。他或許是一個街上的乞丐,但他仍是富有的。但是你先試著去擁有很多財富,然後你認為你就會快樂,它從來不以那樣的方式發生,因為財富不可能是快樂的一個原因。快樂一直都是財富的一個原因
  • 試著深入去看你的本質,並且想想主要的事情。要很快樂!就在這個片刻你就可以快樂,沒有人在擋你的路。如果你無法在這個片刻就快樂,你將永遠無法快樂。快樂跟未來無關。快樂不知道有明天,因為快樂並不依靠其他任何東西,它只是一種態度,就以你這樣,你現在就可以快樂。
  • 你可以根本沒有理由地快樂,因為快樂是很多事情的理由,它是基本的因。你可以快樂,試試看。你一直都從另外一端來嘗試,現在從基本的因來嘗試。首先有那個因—成為快樂的—然後果將會隨之而來。永遠都要記住不要去找代罪羔羊,那樣做一定會錯過你的生命。

為什麼要賺錢?如果是為了快樂,錢的確可以帶來快樂,但也有很多快樂是錢無法買得到的。錢應該是果,而不是因。是某種主要目標的副產品,但它不是,也不應該是主要的事。

***

價值驅動的極致

關於「錢不是一切」的相關說法已經聽過很多,但奧修的闡述方式,讓Teddy豁然開朗。錢只是一個例子,書中的重點是:弄清楚什麼才是主要的事什麼是因

泰迪軟體成立的是什麼?公司當然要獲利、要生存、要賺錢,但賺錢絕對不是它的因。如果賺錢是主要的因,Teddy應該要專研拍馬屁、欺上瞞下,這樣賺錢還更輕鬆。

回到Teddy的初衷,希望能找到一個讓自己可持續追求The Timeless Way of Software Development的生存模式:不用看老闆、主管、同事的臉色,沒有辦公室政治,只要專心對付(服務)客戶即可。只要這個「因」做對了,錢應該也會隨之而來。

這個道理可以應用在各種場合。以軟體開發而言,什麼是主要的事?人與互動是主要的事,還是流程與工具(敏捷宣言第一條)?軟體架構與設計模式是主要的事,還是程式語言與框架?願景與里程碑(目標)是主要的事,還是User Story以及Tasks?通用語言與領域模型是主要的事,還是Aggregate、Entity、Value Object與Repository?

弄清楚主要的事,才不會瞎忙,心才會靜下來做出正確的決定。

***

靜心

今年因為疫情的關係,泰迪軟體的很多課程都因為招生不足而停開。如果是往年Teddy多多少少都還是有點焦慮。但此時此刻,雖然收入比去年少很多,但內心卻異常平靜。

因為Teddy知道,自己持續在做主要的事。而且,想要快樂就可以快樂,不需要等賺大錢。

***

友藏內心獨白:這是一種阿Q精神勝利法嗎XD。

2020年5月4日 星期一

變成一個點

May 04 09:52~11:19

▲學習的過程就是填滿圖形。


加法

老子說:「為學日益」。學習者,心中有一個學習的標的物(目標),例如設計模式、敏捷開發、軟體架構、人工智慧、大數據、領域驅動開發、測試驅動開發等。

這個目標,在學習者的心中形成某種形狀form),它可能長得像圓形、三角形、不規則圖形。這個形狀的邊界(boundary)界定了學習者的守備範圍,邊界以內屬於學習內容,邊界以外屬於脈絡、背景知識(context)。隨著學習進程,範圍可能會改變,但它總是一個有邊界的形狀,不管這個形狀長得像什麼圖形。

這個形狀一開始是空的,因為學習者還沒學會所需的知識。他藉由讀書、上課、討論、Google、練習、參加社群聚會、模仿、實作等方式,充實自己,填滿這個圖形。

***

智光忽明忽滅

▲從某個角度來看,形狀好像已經填滿了。

在某些片刻,學習者一度以為自己已經完全掌握學習內容,他可以正確回答許多(特定)問題,相當於考試獲得100分的喜悅。他自得意滿地認為,形狀好像已經填滿了。

***

▲換個角度才發現空白處還很多。

但換個角度、換個環境、換個題目、換個發問方式、換個時間、換個專案、換個公司,此時才發現原來形狀之中空白之處還很多,還需要精進學習。

***

▲總是還有填不滿的空隙。

有一天,這位學習者越來越博學,領域知識的名詞幾乎都已經收集得差不多了,如果參加全國性考試一定可以得高分。但是,形狀還沒填滿,還是有一些空隙。

***

變成厲害的人

敏捷宣言說:

藉著親自協助他人進行軟體開發,
我們正致力於發掘更優良的軟體開發方法。

(We are uncovering better ways of developing
software by doing it and helping others do it.)

學習者自己變得厲害只是過程中的一個階段,他還需要練習幫助別人,讓別人在他的幫助之下,有能力完成原本認為很困難無法做到的事情,成為Kent Beck所說的那種「厲害的人」。

▲到了這個時候,形狀已經填滿。

***

減法

▲Quality without a name,特質本身非常具體,變成一個點。它沒有面積,不再是形狀。

老子的道德經在「為學日益」之後還有幾句:「為道日損,損之又損,以至於無為,無為而無不為。」知識的累積,越來越多,就算此時自己覺得已經「收穫滿滿」,但這個收穫滿滿轉眼間又變成空。因為環境改變、領域改變、競爭者改變、專案改變、團隊改變、慾望改變,你滿別人比你更滿,不滿之心因而升起。

心永遠靜不下來。

Alexander在《Timeless Way of Building》書中提到學習模式(pattern)的過程也是如此,透過學習模式來重拾人們設計與建造建築的能力。但這不是終點,不是目的。透過這個過程,喚回人原有之本性、本能。之後,這些模式都要忘記。

金剛經云:「知我說法,如筏喻者,法尚應捨,何況非法。」聽佛說法(學習pattern),是為了開悟(追求quality)。有了quality之後,那些names、那些patterns,就可以捨棄了。

***

友藏內心獨白:試求未開悟前之心理陰影面積。

2020年4月27日 星期一

怎麼當好一個ScrumMaster?

April 27 12:46~14:15


演給你看不好嗎?

接觸過Scrum鄉民應該都會同意,Scrum的三個角色:Product Owner、Development Team與ScrumMaster,其中ScrumMaste是最抽象、虛無飄渺的存在,最不容易了解,也最難扮演好這個角色。

曾經有幾位客戶要求Teddy到他們家去充當短期的ScrumMaster。這是一個很合理的速成方法,如果請有經驗的人來當ScrumMaster,團隊的新手ScrumMaster就有一個「具體的範本」可以參考。日後只要依樣畫葫蘆照著做,應該八九不離十差不到哪裡去。

但就算是在缺少業績的情況下,Teddy從來沒有答應過客戶去當短期的ScrumMaster。Teddy可以當敏捷顧問、敏捷教練、碎碎念講師(看你喜歡哪個稱呼),陪著PO、團隊與ScrumMaster一起成長,但無法擔任團隊的短期ScrumMaster。

為什麼?因為Teddy始終是個外人。ScrumMaster與Product Owner和Development Team之間是一種很緊密的團隊合作關係,唯有長期承諾,讓整個團隊知道「你是在玩真的」,這種關係才會是完整的。外在環境、專案特性、團隊成員等不斷地變化,沒有固定的公式可以遵循,很能靠一個外人「演給你看」就可以了解箇中精隨。

ScrumMaster必須現時現地去體驗各種作用力、各種限制、各種壓力、各種機會,並且不斷地嘗試、調整。只是短時間加入團隊的「外派」ScrumMaster頂多在敏捷形式提供團隊參考,但這種參考非常片面,也很容易讓人誤解。

***

動輒得咎

書上說,ScrumMaster要協助團隊排除阻礙,因此有些ScrumMaster從這一點著手,最後變成團隊有任何問題都找ScrumMaster來處理,團隊變成了媽寶,而ScrumMaster變成了寶媽

書上又說,ScrumMaster採取僕人式領導(Servant-Leadership),從這一點出發,有些ScrumMaster最後成為團隊的僕人,負責幫團隊訂會議室、安排議程、寄發會議通知、撰寫會議記錄、更新Scrum Board,以及催大家準時參加Scrum會議。僕人易做,領導難行。

也有人覺得引導技能很重要,ScrumMaster要引導團隊發現自身的問題,而不是跳下去幫團隊解決問題。再加上Scrum團隊是自組織團隊,應該有能力能夠從失敗中學習,逐漸改善。因此,當團隊成員向ScrumMaster求助時,ScrumMaster總是說:「由團隊決定」,弄到最後讓團隊成員覺得ScrumMaster的存在本身變成了一種阻礙。

***

云何應住?

依據Teddy的理解,ScrumMaster之所以存在,他要解決的問題是:「如何讓Development Team、Product Owner與組織獲得Scrum的好處?」可以從這個角度切入,來思考要怎麼做好ScrumMaster。

金剛經裡面有一段話:

「菩薩於法,應無所住,行於布施,所謂不住色布施,不住聲香味觸法布施。須菩提!菩薩應如是布施,不住於相。何以故?若菩薩不住相布施,其福德不可思量。」

把「菩薩」換成ScrumMaster,就可以知道ScrumMaster要怎麼做。

ScrumMaster依據敏捷精神,無須拘泥一定的形式與方法,只求能夠幫助開發團隊、PO與組織。不需拘泥教練、僕人領導、流程專家、干擾屏蔽、阻礙排除、變革代理。ScrumMaster要專注在協助開發團隊、PO與組織獲得敏捷的好處,不拘泥於特定形式,如此便可產生有利的效果。

有些ScrumMaster很認真,為了做好自己的工作,上了很多課。但回到團隊之後,如果做得好,他變成了一個教練、一個僕人式領導者、一個流程專家、一個保護者、一個石頭搬運者、一個敏捷轉型策略大師。做不好,他成為沒打過棒球的棒球教練、任勞任怨的僕人、技術控、太極高手(推拖工作)、吵架王、嘴砲王。

他已經不是ScrumMaster,他被切割成好幾塊

***

無為而無不為

扯了這麼多,到底ScrumMaster要怎麼做?很簡單,在敏捷精神之下,該做什麼,就做什麼。做了之後有幫助,就持續下去。沒有幫助,思考如何改善,不斷精進。

這個過程很漫長、很痛苦,因為現實世界很危險,你要靜心,忍得住孤獨、寂寞、羞辱。你可能需要一位師父、前輩、長者,與你同在,支持你走完這個過程。

最後,你渡過河,到達敏捷的彼岸,你有能力幫助其他ScrumMaster繼續他們的旅程。

***

友藏內心獨白:是在找聖人逆!

2020年4月20日 星期一

毛書一刀未剪大公開

April 20 11:28~12:45


Teddy在2012與2014年所出版的兩本書《笑談軟體工程:敏捷開發法的逆襲》與《笑談軟體工程:例外處理設計的逆襲》已經絕版一陣子了。上個周末上【Scrum敏捷方法實作班】,有學員知道書已絕版,詢問Teddy是否能提供第一本書的電子檔?Teddy也忘了之前有沒有公開提供過,所以今天就寫一篇文章把這兩本書的電子檔公開。

因為書本最後出版的格式經過悅知出版社編輯過,這個「排版編輯」版權屬於出版社,所以Teddy只能公開當初提供給出版社的原稿。編輯前的原稿與最後出版的內容略有差異,且可能有一些尚未訂正的錯字,請讀者自行除錯。

電子檔下載:

***

友藏內心獨白:紙本的比較香。

2020年4月19日 星期日

塞翁失馬

April 19 20:37~21:28


也是疫情受害者

這兩天(4/18~19)是第32梯次【Scrum敏捷方法實作班】上課日,這梯次課程很早就確定開課,但因為前一陣子境外移入的新冠肺炎案例大增,陸續有學員取消報名,最後上課學員只剩下七位,剛好湊成一組。

原本課程最低開課人數是10人,因為目前處於疫情的特殊狀況,Teddy也沒有取消該梯次。疫情期間人少一點也好,雖然收入變少免不了有點小失望,但加減賺,至少可以付房租。

***

趁亂做實驗?

Scrum課程有一個練習活動,讓學員透過User Story Mapping(使用者故事地圖;USM)作為敏捷需求管理工具。上課前一天(禮拜五)Teddy想:「既然這次只有一組,練習活動是不是可以做一些調整,試看看改用Event Storming Workshop(事件風暴工作坊)來收集需求的效果?」。

想了一天,覺得自己沒有把握在短時間的練習活動中可以讓Event Storming Workshop達到原本USM的效果,於是決定還是先維持原本的練習活動。

昨天上了一天課,因為只有一組,Teddy反而有更多的時間與學員討論(WIP=1),講得話比往常都還要多。今天(禮拜日)早上起床,邊吃早餐邊打開電視聽新聞。突然間,不知怎麼的靈光乍現,有點想通了Event Storming Workshop與USM的差別,以及兩種方法個別合適的應用情境。

雖然在Event Storming發明人Alberto Brandolini的書中提過這個問題,但讀書的當下Teddy並沒有特別深刻的領悟。也許是緣分到了,經過一段時間的醞釀,突然有點感覺了。

***

上了台就不要想賺多少錢

Teddy在吳宗憲的綜藝節目中聽憲哥說過一句話:「上了台就不要想賺多少錢」。言下之意是說,不管此次的收入多少,身為一個藝人上台之後就是要拿出最好的表演。

***

如果不是疫情,最後報名人數只夠湊一組,人數不足是不會開課的。

如果Teddy抱持著:「只有七個人,那就不用特別準備,照以往的方式上課就好。」這兩天也就這麼過去了,也不可能有今天關於USM與Event Storming Workshop的小小突破。

所以說,認真把事情做好,其他事情就交給老天爺吧。

***

友藏內心獨白:活在當下。