[AHA 2017]講師採訪－91的學習永動機模型

2017-02-15

1672
0
2018-01-03

AHA 2017 大會將於 4/13 ~ 4/15 在上海舉辦，報名與活動詳情請見 2017AHA大会。

本文為 AHA 議程組針對講師與其主題所做的採訪內容。

Joey，能不能谈一下你的从业经历？

第一份工作：叡揚資訊

我在進軟體業之前，並沒有什麼寫程式的底子，所以在起跑點就落後別人一大段。

第一份工作是在 400 人的軟體服務整合商【叡揚資訊】擔任四年的國防役，一旦離職就是要回去部隊服一年八個月的兵役，因為跑不掉，所以國防役在台灣業界都被笑稱「便宜、耐操、好用」，也比較容易比一般人多一些「承接艱鉅任務的機會」。因為跑不掉，只能想辦法從中獲得樂趣，也因此奠定了我對軟體開發的愛。這段時期剛好公司在軟體品質、架構設計與基礎建設進行轉型，而我也擔任轉型、研究與實踐的先驅者，因此在實務上歷練了不少技能，如 UML、重構、設計模式、依賴注入、AOP、持續整合、單元測試。

這段奠定自己程式設計基本功的時期，除了在公司內擔任主要的教育訓練講師，也認識了很多微軟技術社群的前輩與朋友，獲得了微軟最有價值專家的榮譽，同時擔任微軟官方技術論壇的版主。

第二份工作：YAHOO

第二份工作是在【YAHOO】五年，從事電子商務相關的領域，主要負責後台，也就是顧客看不見的部分，都歸我們負責。

除了電子商務領域知識的累積外，也有比較多的機會接觸到國外的軟體工法與分散式架構的設計，這也是我目前職涯最重要的分水嶺，因為這段時期我開始接觸了敏捷，也協助幾個 scrum team 形成自組織的文化與運作，也協助了幾位 PO 從傳統的角色與合作方式，轉成與 team 建立信任情感、合作無間。

而自己在軟體技藝上的精進，則是自學了 web testing、TDD、GOOS、cucumber，CI 上搭配靜態程式碼分析、自動生成文件與持續部署。設計技能上則是對延展性、擴充性、可維護性、安全性、效能、大量交易與高併發的需求，有了更深入的瞭解。

這段時期則認識了更多非微軟技術社群的朋友，尤其是敏捷相關的社群，同時也開始著手書籍的翻譯與撰寫，在社群活動與研討會上分享經驗，也開始了 TDD 培訓的公開課程。

第三份工作：Titansoft

我在 2016 年認識了 Yves 之後，加入了【Titansoft 】。

鈦坦有我所嚮往更加自組織的敏捷文化，同時也對線上娛樂商模的變化性與技術需求感到興奮，這段時間雖短暫對我來說卻十分璀璨，我體會到了什麼是 being agile，而不是 doing agile。

圖像裡可能有12 個人、微笑的人、大家站著和室內

跟鈦坦與社群的夥伴們一同參加了 ICA 引導相關的培訓課程，讓我對敏捷教練所扮演的引導者角色有了更多的感觸，也實際應用在社群活動與培訓課程中。也親自體驗了完全的自組織團隊，所激發出來熱情的能量，pair programming 是再自然不過的事，因為互助、互相學習、互補，是團隊中每個人都渴望追求的狀態。

圖像裡可能有2 個人、室內

第四份工作：東森信息科技

目前則是在東森集團中的【東森信息科技】，同時扮演幾個不同的角色：

Director：people manager，帶領電子商務相關，約 50 人的技術團隊。
Principal architect：協助目前系統架構的擴展與優化，以及規劃新電子商務平台的建立。
Agile coach：協助建立基礎建設、協助團隊排除協同合作所遇到的問題、協助團隊與組織敏捷轉型。
Technical trainer：進行一系列技術與敏捷相關的教育訓練。

请和大家介绍下你和目前所从事的工作？

我叫 Joey，闖蕩江湖則都是用 "91" 這個稱呼，因為 Joey 跟「九一」念起來很接近，而數字 91 讓大家很容易就記得我的名字。

在東森信息科技的角色與職責，在上一段已經提過了，這邊則介紹正職以外的發展與興趣。

我從 2014 年開始成為 TDD 培訓課程的講師，截至目前共辦過 8 場企業內訓，7 場公開培訓課程，每場皆 45 人爆滿，最近兩場分別在 1 小時與 3 小時內售罄。除了 TDD 以外，也在公司舉辦教育訓練，主題包含 C#、OOP、重構、設計模式以及敏捷。

研討會與社群活動 speaker，則是從 2013 年開始，包含 WebConf, Agile Tour, JCConf, phpConf, Microsoft tech days BoF 等…也在 2010 年到 2017 年連任八屆微軟最有價值專家的榮耀，推廣微軟相關技術並在社群中貢獻所學，透過別人提出的問題來迅速接觸更多自己未知或沒機會碰到的問題，是累積自己技術深度的不二法門。

自己也熱愛寫作，除了個人的 blog 以外，同時也發表不少文章在技術專欄上，參加了四次 IT邦幫忙鐵人大賽，並拿下三屆的獎項。

並與朋友合著了兩本 ASP.NET MVC 相關的書籍，其中一本已邁入第 11 刷，銷量約 7500 本。在出版社的邀約下，也著手翻譯了兩本書籍，分別是 .NET 以及敏捷相關書籍。

透過寫作，在知識內隱到外顯的過程中，無法順暢表達的部分，可以發現自己的不知，進而調研讓自己瞭解的更深。公開的文章往往也會引起許多朋友的回饋與交流，最彌足珍貴的莫過於指出自己的錯誤，倘若沒有這個過程，自己可能會抱著錯誤的想法一直下去而未可知。翻譯書籍則是強迫自己用最深的角度與力道去閱讀國外的經典書籍，鍛鍊自己表達的通順能力，這能力對我所扮演的角色相當重要。

分享一下台湾的软件行业情况吧，包括TDD, GOOS等实际推广情况？

我這邊針對「困難點」、「迷思」、「現況」來簡要描述一下。

【困難點】

一、環境問題：台灣因為市場小，大致上都是炒短線。例如：

接案的多、開發產品的少：為了能結案，什麼都可以捨棄。
新創多、活下來的少：為了能生存，什麼都可以捨棄。
單兵作戰多、協同合作少：養 code 自重歪風盛行，角色之間各執一詞、各說各話，重視的不是交付價值，而是責任歸屬。
工程師屬食物鏈末端，待遇地位普遍低下：許多工程師對職涯的規劃都是程式過客，盡可能的擺脫需要用技術與不斷學習才能獲得競爭優勢，儘速進入系統分析師或專案經理，期待能只出張嘴跟客戶釐清需求後，轉嫁時程壓力給開發團隊。

二、導入技能點不夠：成功的導入與轉型，需要面面俱到的能力。單一位的導入或協助轉型的人員，往往缺乏一些關鍵性的技能。例如：

缺乏工程實踐能力與經驗：也就是過去跟現在，都有讓技術方案落地的能力。
溝通與取得信任的能力：導入、轉型、改善，事情本身其實相對單純許多，人與人之間的溝通與信任，還是最花時間與心力經營的。沒有信任，就沒有安全感，就不可能發自內心的產生變化。怎麼讓主管、老闆願意買單，怎麼從他們的角度去幫助他們獲得想要的結果，提案能力與權威感還是很重要的。再加上往往在炒短線的時程壓力下，很多時候是有心殺賊，無力回天的情況。加上能硬能軟的人本就稀缺，公司是否願意投資在聘請這樣的人員上，是要先花錢花時間磨斧頭，還是要繼續用鈍斧頭榨出最後產能，也是另外一個現實的問題。
教練能力：能硬能軟，還得要能教、能引導，才能讓大家變好或自己朝向改善成長之路邁進。很多時候，導入人員是很好的運動員，但不是稱職的教練。
敏捷內化的程度：就像《達摩祖師傳》裡面講的「說理的人多，而悟理的人少」，台灣還是太多人（包含之前的我）重有形的形式、工具、實踐，而無法讓整個團隊組織體會敏捷的本質。很多敏捷是有形無神，這也是 Joshua Kerievsky 在《Modern Agile》中所強調，他這幾年看到最大的問題。（他在 Agile Singapore Conference 2016 的演講必看啊！Titansoft 的夥伴們已經幫忙加上了中文字幕）

【迷思】

以為 TDD 是測試，而測試只是為了提昇品質。而且認為測試很花時間，在成本與時間的限制下，品質是可以取捨的。而品質是開發人員的責任與問題。開發人員在沒有安全感的前提下，自然趨吉避凶。
以為 TDD 就是侷限在 class/function level 的東西。畢竟，要訴諸於圖文解釋實務上的 TDD，得考量到領域知識、語言熟悉度、設計能力、UI介面與應用程式外，還得考量篇幅、說明詳細程度、由淺入深描述的能力。自然大家看到的東西，都是簡化到不能再簡化的範例來說明 TDD 的基本與核心概念，長久以往就造成了這樣的誤解。
以為 TDD 就只是先寫測試，再寫產品程式碼而已。而失去了化繁為簡的能力與過程，也錯過了透過測試案例推砌出產品程式碼，迭代與增量式的開發方式。
不願意承認自己設計能力不足，自己設計的 API 不好用。而是 TDD 不實用，只是紙上談兵的糖衣。
為了寫測試而寫測試。導致測試程式難以維護，無法提昇設計的易用性，無法產生測試即需求文件與操作手冊活文件的綜效。
以為 TDD 在開發時一定會比較花時間。這一點需要導入手法與說服技巧來輔助，包含了換位思考、承諾、提案、驗證概念、挑對 pilot、做出成果、渲染、留餘力在剛好的時機進行下一步的改善。

還有一個永遠存在的問題：以為任何新的導入都可能是銀彈、治百病的萬靈丹，沒病還可以強身健體的迷思

【現況】

從 2014 年開始，台灣的敏捷社群風氣盛行，也開始有許多認同敏捷的人在各公司擔任要角。敏捷如同心法，但只有敏捷，有心無力。
從 2015 年開始，DevOps 正夯，雖然很多老闆都把 DevOps 當省人員成本的大旗，很多工程人員都把 DevOps 當作只是基礎建設與自動化流程的同義詞，但不可否認，引進了許多基礎建設的發展。但基礎建設就像良好的武器防具，沒有好的臂力與使用技巧，也無法發揮其效果。
基於前兩點，以及全球的技術趨勢佐證這些東西並非紙上談兵，工程能力的基本功要求浮現，加上社群大牛幫頂，勝過自吹自擂，三年來的開班授課也做出口碑，而我在實務上的經驗也增加了可信度、權威感以及學員的信任，所以越來越多人對 TDD 的接受程度提高，覺得這並非烏托邦的遙不可及，只是大部分人不得其門而入而已。

GOOS 最大的卡點，還是在協同合作上的問題。角色之間不信任，以責任歸屬為前提，而非交付價值。開發只認文件的白紙黑字，而非即時溝通、取得回饋、達成共識。那些不必要的時間與成本消耗，對他們來說都是不安全感中的救生艇。實例化需求不難，信任與安全感才是最大問題。