l

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,兩者相輔相成,缺一不可。

***

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

2019年4月25日 星期四

Clean Architecture讓系統穩定演化

April 25 15:40~16:26


劇情

以下是許多開發團隊都經歷過的對話…

技術控員工:我們的系統架構太爛,我已經快受不了了。現在新技術那麼多,如果用了這些新技術所有問題都迎刃而解。我強烈建議,應該把系統砍掉重練

技術主管:我承認我們的系統已經改不太動,每次修改的成本越來越高,但我覺得我們應該重構系統而非重新撰寫系統。

技術控員工:理論上沒錯,但我們系統亂成一團,重構不一定比重寫要來得簡單啊,搞不好更花時間。現在新技術、新框架,解決我們的問題很快,我還是覺得應該要整個砍掉重練。

技術主管:根據我以前的經驗,整個砍掉重練風險很高。我們的系統至少目前可以動,這是無可取代的價值。我還是覺得重構比較保險,穩扎穩打。

技術控員工:可是我已經不想再看到這堆爛code了,有辦法你自己來重構看看。

技術主管:!@#!%^^#!E04…

***

不自覺的過程

技術控員工與技術主管各有道理,雖然一般來講重構比重寫要來得好,但有時候歷史包袱太大,很可能重寫的成本反而比重構要來得低。決策的困難點在於,兩種做法的成本很難量化之後加以比較,只能藉由經驗、資源、甚或是一時情緒衝動所決定。依據主管的經驗,重寫往往沒什麼好下場,只滿足技術控員工學習新技術的慾望,而忽略的重寫帶來的高風險。

如何讓系統在持續演進的過程中,又可以保持一定的穩定性,相信是很多軟體從業人員想要追求的目標。上禮拜四地震後Teddy跟指導教授聊天,聊到Alexander在《Notes on the Synthesis of Form》提到:「一個系統要能夠持續保持穩定,其自身的調適性一定要大於外在需求改變的頻率與強度,否則系統將會處於不穩定的狀態。」

在傳統社會中,因為文化的限制力道非常大,因此建築物的演化,往往只做小範圍的改變,除非發生文化劇烈改變(例如維新運動、被外族統治),否則設計者基本上只要遵循老祖宗的做法去設計建築即可。

此外,因為設計者(蓋房子的人)生活在其設計的建築物之內,所以只要建築物有任何不合適的地方,例如漏水、淹水、通風不良等,設計者立刻會著手修正。因此,系統會一直保持穩定的狀態。這種設計方法,叫做不自覺的過程(unselfconscious process),此過程會產生極其穩定的系統。

***

Clean Architecture所形成的文化

不自覺過程的原理,套用在軟體系統一樣成立。以一個套用Clean Architecture的系統為例,Clean Architecture好比傳統社會的文化,規定了系統階層(entity、use case、interface adapter、framework and driver、)、每個階層所負擔的責任、以及限制(相依性原則、跨層原則)。

在此文化之下,開發人員不再享有「我想怎麼胡搞瞎搞,就怎麼胡搞瞎搞的自由。」相依性原則嚴格限制了系統相依性方向,I/O層變成可隨意替換的一部分。框架不再是架構師關心的核心,domain model與use case才是主角。

開發人員透過持續重構讓軟體系統隨時維持在clean code、clean architecture的狀態,系統的調適性便可基本大於需求改變的頻率與強度,如此才可讓「需求改變主要與scope相關,與改變發生的時間點無關」,軟體就真的軟了起來。

你不喜歡React,想換成Angular,沒問題,把UI層抽換掉即可,它原本就是可插入替換的一部分。不喜歡MySQL想換成NoSQL資料庫,沒問題,換個database gateway即可。

***

結論

只要你的軟體系統的調適性大於需求改變所造成的殺傷力,你就不怕需求改變所造成的衝擊。就算改變會造成混亂,也可以在短時間內讓系統恢復穩定。

這不是開發人員一味只強調技術至上的觀點,而是一種支持快速交付商業價值的靈活性。

***

廣告

對於Clean Architecture + 領域驅動設計(Domain-Driven Design;DDD) + 測試驅動開發(Test-Driven Development;TDD)有興趣的鄉民, 歡迎參考泰迪軟體的【Clean Architecture這樣學就會了實作班】課程。

***

友藏內心獨白:限制讓開發變得更容易。

2019年4月1日 星期一

你還在寫程式?

April 01 00:34~01:03


對話

前一陣子前某公司HR和Teddy聯絡,想找Teddy去企業內訓上【Clean Architecture這樣學就會了實作班】…

HR:經過調查之後,公司內部想上這門課的人太多,因為預算關係我們想優先安排最需要的同仁來上課。

Teddy:這很合理。

HR:上完課程會有甚麼成效?每個人都可以應用在工作上嗎?

Teddy:Clean Architecture簡單來說,是一種可以擴充的插件式架構。對同仁而言,如果是舊專案,沒什麼特別理由是不需要改成Clean Architecture。但如果是新專案,以我的經驗Clean Architecture有很大的機會可以派上用場。

Teddy:我最近套Clean Architecture寫了一個看板系統,我覺得很有幫助。

HR:你還在寫程式?

Teddy:對啊,不能光說不練XD。

***

程式可以寫一輩子嗎?

以上這段和HR主管的對話,讓Teddy想起2014年寫的這篇文章〈程式可以寫一輩子嗎?〉。這個問題,從Teddy年輕時第一次被「質問」到現在,說實話自己內心並沒有100%肯定的答案。

每個人的情況都不同,Teddy自己是希望能夠寫程式寫一輩子。雖然現在泰迪軟體的工作性質不需要像以前當開發人員寫那麼多程式碼,但學習軟體新技術、設計課程教材,還是需要寫程式,不可能光讀書不寫code。

Kent Beck說:「If you stop coding, you stop learning.」Teddy非常喜歡這句話,coding的目的很多,透過寫程式學習,絕對是開發人員最主要的學習方式。

***

結論

身為程式設計師,有機會、有能力寫code,是很幸福的一件事,不應輕易放棄。

***

友藏內心獨白:寫程式可以用手也可以用口。