2013金門考察之旅Day1-A得月樓、僑鄉文化展示館

July 05 15:38~16:50

今年6月和Kay到金門考察，第一天一大早6:10到達台北松山機場準備搭第一班立榮航空飛到金門尚義機場。

 

6:50開始登機，到金門的人好多，班機客滿。

 

8:10抵達金門。

 

金門住宿地點選在「海福商務飯店」，訂房外加100塊飯店提供機場接送服務。飯店下午3點才可以入住，8:40左右到達飯店之後先寄放行李，跟飯店租了一部機車準備開始考察之旅。機車費用和馬祖一樣，都是一天500元。但是馬祖的機車包含油錢，海福飯店的機車要自己加油。機車還蠻新的，很好騎（Teddy是負責被載的人）。

 

離開飯店之後，某人居然說她肚子餓了，所以先到附近的早餐店吃早餐。早餐店的老闆娘很親切，更重要的是，早餐居然出乎意外的好吃，唯一的小缺點就是…蒼蠅好多啊。後來Teddy發現，金門很多地方蒼蠅都很多，這算是特產之一嗎？還好Teddy大叔幾十歲的人了，見過大世面，在台灣宜蘭山區看過數量更多的蒼蠅群，這一小群蒼蠅嚇不倒Teddy的。

吃完早餐之後來到水頭，首先參觀得月樓。得月樓蓋這麼高是為了瞭望之用，可以遠遠的看到海盜。

 

這一帶有很多經過金門國家公園整修後的閩南式建築古厝和洋樓，滿有味道的。閩南建築、僑鄉文化、戰地文化號稱金門三大特色。

***

在得月樓旁邊的僑鄉文化展示館。

 

閩南建築的特色，燕尾。

***

友藏內心獨白：水頭景點還蠻多的。

選擇不是設計

July 03 14:12~15:40

 

老闆：那個…公司的網站要準備改版，這次的重點是要做的美觀又好用，知道了嗎。

你：請問怎樣才算是美觀又好用？

老闆：到底是我是老闆還是你是老闆。我叫你做事你反而出功課給我做，有沒有搞錯啊你。

你：那…我做2種不同的網站雛形讓老闆您選擇這樣可以嗎？

老闆：什麼，才兩種。至少做個5種吧。

你：是，遵命。

老闆：好，記得明天早上把雛形demo給我看。

你：明天…!#@!@$e04…

***

你：老闆，這5種網站雛型A、B、C、D、E您看一下喜歡哪一種。

老闆：都不行，顏色都太醜了，重作，下禮拜一再拿給我看。

你：是，遵命。

***

你：老闆，這5種網站雛型B、C、A、E、D您看一下喜歡哪一種。

老闆：嗯，這次做的有比較好一點，顏色看起來比較協調，但是操作起來還是不太方便。你回去再改一下，改的好用一些，後天再拿給我看。

你：是，遵命。

***

你：老闆，這5種網站雛型A、B、C、D、E您看一下喜歡哪一種。

老闆：嗯，這樣就對了嗎，現在不管是顏色還是使用性都比之前第一次的版本好用許多。你看吧，有要求才有進步，公司要不是我每件大小事都盯著，哪有今天的成功啊。

你：是、是，感謝老闆的指導。

老闆：那我看…就選擇C好了。

你：是，遵命。

Teddy內心獨白：最後的A、B、C、D、E和第一次給老闆看的A、B、C、D、E內容不是幾乎一模一樣嗎？

***

什麼是設計？在《設計的定義》中Teddy提到：

• 設計是決定form、context，以及兩者之間的關係。
• 好的設計是form與context的良好適應關係。

選擇不是設計（selection is not design），在幾個爛蘋果中挑一個比較不爛的這不能稱為「設計」。不知道為什麼，這種「N選1」的方式在很多專案中好像還蠻常見的。很多人，尤其是大老闆，可能是時間有限，只提出很抽象的「方向」，但卻沒時間討論或接受需求訪談。在「需求很模糊」的情況下，你（開發或設計人員）也只能用亂槍打鳥的方法，期待「聖上」翻牌子的時候可以翻到你做出的來那個「設計」。

結論又是那句老話：「此為正常現象，請安心服用」。

***

友藏內心獨白：見怪不怪。

[工商服務] Design Patterns與Scrum課程

July 03 17:30~18:36

 

Design Patterns 入門實作班確定開課

2013年7月20、21、27日 （週六、日、六）舉辦的「Design Patterns這樣學就會了：入門實作班」第四梯次確定開課，還剩下幾個名額有需要的鄉民們請把握時間，早鳥優惠在7月5日截止。課程報名網頁在此。

課程進行方式請參考：

• 2012年入門班上課實況
  • Day 1
  • Day 2
  • Day 3
• 2013年入門班上課實況
  • Day 1
  • Day 2
  • Day 3

課程費用

原價NT$ 28,000 (含稅)，推廣期間報名優惠：

• 7月5日前報名並完成繳費享早鳥優惠：NT$ 24,000 (省4,000) 。
• 4人同行，一人免費：每人NT$ 21,000 (每人省7,000) 。
• Scrum課程老客戶：NT$ 22,500 (參加過「Scrum敏捷方法實作班」兩天課程的學員具備此身分，省5,500)

***

 

 

 

 

 

 

 

Scrum敏捷方法實作班第七梯次

Scrum敏捷方法實作班預計在8月17、18日（週六、週日）舉辦，課程報名網頁在此。

課程特色：

• 任何人都可以上：本課程不限軟體開發人員，只要想要了解Scrum的朋友們都可以報名參加，包含專案經理、產品經理、介面設計師、工程師、技術經理等。
• 由Teddy負責授課：在歡笑聲中不小心就學會了Scrum。
• 符合台灣現況的Scrum導入經驗：由Teddy在課程中分享不同產業導入Scrum的成功與失敗經驗。
• Scrum活動實作：課程搭配大量的練習活動（產生product backlog、sprint planning meeting、task break down、task board建立、daily scrum、retrospective meeting等） ，讓學員們在課程結束之後具備實際帶領Scrum團隊的基本能力。
• 小班分組模式：課程搭配實際帶領過Scrum團隊的助教，協助各組練習各項Scrum活動。
• 贈送Scrum工具包：課程推廣期間贈送一組Scrum Master必備的Scrum工具包，讓學員上完課之後可以帶著工具包立即協助團隊導入Scrum。
• 售後服務：上課學員可加入Facebook上專屬的「泰迪軟體敏捷開發課程社團」，課後有任何問題皆可在此發問。

課程進行方式請參考：

• 第一梯次：Day 1、Day 2。
• 第二梯次：Day 1、Day 2。
• 第三梯次：Day 1、Day 2。

課程費用

原價NT$ 18,000 (含稅)，推廣期間報名優惠：

• 8月2日前報名並完成繳費享早鳥優惠：NT$ 15,000 (省3,000) 。
• 4人同行，一人免費：每人NT$ 13,500 ( 每人省4,500) 。

***

友藏內心獨白：下次開課又是3個月之後了。

有威力的顧問（2）：不問則不答

June 28 22:16~23:26

 

今年上半年接了幾個顧問案，在執行顧問案的這幾個月，Teddy越來越能體會溫伯格在《顧問成功的秘密（The Secrets of Consulting）》這本書中所提到的各項建議。Teddy在《顧問成功的秘密：有威力的顧問》曾經介紹了溫伯格在書中提到的11項「有威力（影響力）顧問」的特質。這11項特質寫得真的太好了，Teddy想要分幾次將這11項特質介紹給鄉民們。

你的責任是去影響人，但唯有在他們向你提出要求之後方可為之

許多工程師出身的人可能都跟Teddy一樣，看到不合理、不正確的人、事、物、做法、流程等，都會有一股想要「修正」的衝動（路見不平，拔刀相助）。隨著年紀增長，累積的經驗也越來愈多。當一個新的顧問案成立的時候，Teddy總是會有一種想要一股腦把所有觀察到的問題告訴客戶的衝動，其中有些問題甚至與這個顧問案的內容毫不相干。

但是冷靜下來想一想，顧問又不是公司編制內的人員，而且顧客只是請你來幫忙協助解決某個特定範圍的問題，應該要避免涉入公司其他事務。但是雞婆的個性有時候又會讓自己很掙扎，明明看到某個地方有問題，卻又要視而不見。這樣做，合適嗎？

其實想通之後這個問題也很簡單，因為「顧客只是請你來幫忙協助解決某個特定範圍的問題，並不是請你來經營這個公司。」所以，除非顧客特別向你提出協助的要求，否則還是應該閉上嘴巴，以免誤觸公司內部的政治角力鬥爭或是踩到別人的勢力範圍。

***

舉個例子，有個顧客因為業務擴充想要找程式設計師，但找了一陣子一直沒有找到足夠多的適合人選。雖然Teddy對於「找人」這件事有一些看法與管道，而且也認識顧客的高層主管，但因為Teddy執行的是Scrum顧問案，顧問合約中並不包含「找人」這個項目，所以Teddy並沒有毛遂自薦跑去跟該高層主管提出自己的想法。直到某一天這個高層主管自己跑來找Teddy，希望Teddy協助幫忙「找人」，此時Teddy才提出自己的建議。

如果這位高層主管沒有提出協助的要求，Teddy就興沖沖的跑去給「建議」，對方說不定會認為：「你哪位啊，幹嘛跑來跟我講這些…」

***

除非顧客公司的董事長是你 老爸 的好朋友，不然顧問這個工作真的不好當，「失業率（不續約的機率）」也很高。公司會請顧問，通常代表著公司在某方面出了問題，或是欠缺某種能力。公司內部沒有人願意被當作是問題的來源，所以要如何在「影響別人」的過程中，不至於遭遇太大的反彈或抗拒，真的是一門學問啊。

***

友藏內心獨白：廣義的說，找不到合適的人對於導入Scrum也是有負面的影響。

泰迪軟體一週年

June 29 14:00~18:09

 

今天（2013年7月2日）是泰迪軟體成立一週年紀念日，剛剛花了點時間把這一年來Teddy做過哪些重要事情稍微整理了一下，如下圖所示：

泰迪軟體成立前後，大致可分為三個階段。

成立前(2012年1~6月)

泰迪軟體成立前的6個月，Teddy一邊在某公司打工，幫忙看一下Scrum團隊的運作狀況並且幫工程師上Design Patterns課程，講完GoF的23個設計模式。另外的時間Teddy在準備出版《笑談軟體工程：敏捷開發法的逆襲》。同時間Teddy也去講了兩梯次由北科大軟體中心所舉辦的「Scrum敏捷方法實作班」課程。2012年5月，Teddy決定創業之後，就花了點時間研究要如何成立公司。這個階段的準備工作，可以算是sprint 0嗎？（鄉民甲：一個sprint搞六個月你也太長了吧。）

 

前半年(2012年7~12月)

在泰迪軟體成立之前，北科大軟體中心承接了經濟部工業局的一個三年期學界科專計畫，主要目的就是要推廣Scrum。如果鄉民們有聽過ezScrum團隊，這個團隊就是科專計劃下的產物，舉辦了很多場免費的公開推廣演講，也到許多企業界去介紹與導入Scrum。在計畫後期ezScrum團隊也舉辦了兩梯次的收費Scrum課程。

泰迪軟體的成立延續了這個科專計畫，希望回歸到商業模式運作，讓Scrum與敏捷開發方法的推廣能夠長久持續下去（如果公司不倒的話）。基於科專計畫的基礎，加上Teddy從2012年起每天寫一篇部落格文章所累積的一點點人氣，還有2012年6月份出版了《笑談軟體工程：敏捷開發法的逆襲》這一本還算暢銷的書籍。在這「三支箭」的加持之下，泰迪軟體就「大膽」成立了。

雖然泰迪軟體成立之初並不算是一切從零開始，但是成立後的前半年幾乎每天都在想收入從哪裡來。有人說，當員工雖然每天在心裡罵公司、罵老闆，但是只要公司不倒，員工每天上班就等於在數鈔票，有上班就有錢可以領，就算是颱風假也照發薪水（姑且先不論領多或是領少）。但是當老闆就不一樣了，每天開門就是燒錢，就算自己不領薪水，公司的房租、水、電、通訊等租金，還有設備費用折舊，這些都是錢。更何況老闆不領薪水這種想法也是錯誤的，因為會低估工公司的實際營運成本。

所幸公司成立的第二個月（2012年8月）以泰迪軟體名義所舉辦的兩門課「Scrum敏捷方法實作班：第三梯次」與「Design Patterns這樣學就會了：入門實作班(第一梯次)」也都順利開課，讓公司有了第一筆收入可以付房租。

這兩門課，也是Teddy當時僅有的「產品」。雖然Teddy非常積極地想要尋找Scrum導入顧問案，但就如事前所預測的，讓要台灣的公司願意自己掏錢請顧問來輔導軟體開發，還真的是…十分困難。在前半年內，一個導入顧問案都沒有談成。

總之，前半年的主要收入還是來自於Scrum課程的貢獻，Design Patterns也只開了一次。雖然Teddy很努力地再想要如何賺更多的錢…嗯嗯…應該是說要如何推廣Scrum，但說實話每次開課招生不確定性還是蠻高的，都在擔心報名人數太少課程會開不成。

另外，說來慚愧，雖然上半年上了兩次Scrum企業內訓班，但這都是客戶主動打電話來詢問而成交的案子，並不是Teddy「直接跑出來的客戶」（主動招攬）。不過話說回來，打電話來詢問的客戶，要嘛是搞笑談軟工部落格的讀者，不然就是看過《笑談軟體工程：敏捷開發法的逆襲》的讀者，亦或是之前ezScrum的粉絲。從這個角度來看，有些案子應該也算是Teddy「間接跑出來的客戶」吧。

小結一下這個時期的心得：做軟體顧問生意好難啊。

***

後半年(2013年1~6月)

因為長輩的介紹，從2012年10月開始接觸的Scrum導入顧問案，居然在2013年1月很快地簽約了。用「居然」兩個字是因為之前談了幾個客戶，後來都因為「經費」因素而沒有談成。翻成白話文就是說，客戶的公司的老闆不願意花錢在導入Scrum這個項目上面。這在台灣算是正常現象，Teddy也已經安心服用了好久了。對於這個案子能夠談成，長輩的介紹幫了不少忙。

1月不知道走了什麼好狗運，還有一家知名的竹科電子大廠（外商）主動來電要泰迪軟體去新竹幫他們上Scrum企業內訓課程，而且Teddy報價之後對方完全沒殺價，就這樣只通過幾次email與電話，一次面都沒見過就談成了一個企業內訓案子。加上Teddy又開了一次「Design Patterns這樣學就會了：入門實作班」，所以1月份的收入就比較多一些。

4月份簽了另一個Scrum導入案，這次客戶是Teddy《笑談軟體工程：敏捷開發法的逆襲》的讀者。第一次和客戶見面，以為只是去和讀者會面，閒聊幾句而已。結果到了對方公司才發現，來了10幾個人，包含資訊部門的副總、兩位協理、以及數位經理與資深工程師。談了兩個小時之後Teddy離開客戶家，不久就收到客戶的email，表示除了要上Scrum以及單元測試與持續整合的內訓課程以外，還要簽Scrum導入顧問約。

下半年還有三件值得提的事情，第一是Teddy終於在4月份的時候開了「Design Patterns這樣學就會了：進階實作班」。這門課原本是要在2012年12月分開課，後來Teddy因為在忙其他事情，開課時間就往後延。開完了「Design Patterns這樣學就會了：進階實作班」之後，Teddy完整的把GoF的23個pattern公開講過一次（之前講課是打工的時候對企業內部員工開講，而且沒有實作練習，和後來的公開班不一樣），也算是替之後寫《設計模式的逆襲》這本書做了一點準備。

第二件事情是同樣在4月份的時候Teddy開了「單元測試與持續整合實作班」，這門課Teddy之前只有在企業內訓課程中開過，因為收費比較高，所以第一次公開班能開成Teddy也是有點意外。

第三件事是Teddy在下半年接了三個顧問案，包括兩個Scrum導入案，一個持續整合顧問案。在輔導顧客的過程中，Teddy自己也學到很多「如何做好一位敏捷顧問」的技巧。加上很幸運的間接經過友人的介紹，Teddy在下半年讀了「溫伯格」所寫的《顧問成功的秘密（The Secrets of Consulting）》這本書。讀完之後讓Teddy學到許多方法，讓自己更清楚要如何成為一位更好的軟體工程顧問。

***

結論

最後自己跟自己開個自省會議（retrospective meeting）：

• Good：
  • 在成立泰迪軟體之前Teddy讀了《大象與跳蚤－預見組織與個人的未來》這本書，作者在書中提到個人創業者，一定要有多重收入來源，例如出書的版稅、顧問費、演講費等。公司成立一年以來，總算是把「多重收入來源」都體驗過了一次。
  • 有開發新的課程，課程種類有緩慢逐漸增加中。
  • 無論再忙，每天還是都有發表一篇部落格文章。
• Improvement：
  • 尚未找到穩定的生意模式，開課成功與否與顧問案的來源還是有一種「碰運氣」的感覺。
  • 顧問案一忙，會導致花太多時間在客戶端，而沒有時間開發新課程與寫書。
  • 每次上課都能夠有時間可以依據最新的經驗調整講義內容。

行動計劃（action plan）就是：再試一年。

***

友藏內心獨白：感謝鄉民們精神上或金錢上的協助。

誰來當Product Owner

June 30 10:20~12:19

 

一年多前有一次機會Teddy去觀察某個Scrum團隊運作，這個團隊是公司內部的研發團隊，主要的工作是開發後端管理平台讓公司維運人員使用。此外團隊還要提供API，讓其他部門的開發團隊可以透過API來和後端管理平台整合。這個團隊當時正準備啟動一個新專案，支援客戶（公司內部另一個部門）新的業務需求。

當Teddy參加完第一個sprint planning meeting之後，發現了一個有趣的現象，就是「沒有人願意承認自己是Product Owner」。

***

Teddy ：請問你們的Product Owner是誰？

團隊：應該是客戶吧，因為他們有權決定需求的先後順序。

Teddy ：那你們的客戶有寫story嗎？

團隊：沒有耶，story是我們大家分著一起寫出來的。客戶不會寫，應該也沒時間寫story，他們還有很多事情要忙。

Teddy ：那你們怎麼知道要寫那些story？

團隊：因為這個專案不是一個全新的專案，而是已經開發好幾代的系統，現在只是要在上面加一些新功能。我們大致上知道有那些功能要做，只是誰先做以及一些需求上的細節需要跟客戶確認。

Teddy ：所以你們自己先把你們認為要做的story寫出來，然後利用sprint planning meeting的場合跟客戶確認？

團隊：差不多是這樣。

Teddy ：那請問如果這個案子失敗了，要由誰負責？

團隊：這…很難說耶。案子失敗了我們的考績和客戶的考績都會受影響…

Teddy 內心獨白：所以就是說…沒有人需要負責？

Teddy ：那你們團隊為什麼不指定一個人來當Product Owner呢？

團隊：不行啦，需求的內容和優先順序又不是我們決定的…

Teddy ：你們可以把客戶當成stakeholder，然後在團隊成員中指派一人當Product Owner。雖然說需求的內容和優先順序是由客戶（stakeholder）決定，但是一但你們指派了團隊成員當Product Owner，也可以想成Product Owner參考stakeholder的意見來決定需求的優先順序。請參考下圖。

 

團隊：可是這樣就變成我們要承擔案子的成敗，這樣也不合理啊。我們的人變成Product Owner之後，說不定客戶就偷懶，以後就不來參加sprint planning meeting了…

喬了老半天，結果這個案子還是在「不知道誰是Product Owner」的情況下繼續進行。

案子最後是有順利完成，從「結果論」來看，這種「不知道誰是Product Owner」的情況好像也沒什麼重大缺點。但是Teddy內心還是覺得，就算是要採用這種「不知道誰是Product Owner」的運作模式，開發團隊還是應該要指派一人作為「地下 Internal Product Owner」，由此人來統整從stakeholder與開發團隊而來的需求，並且要安排足夠的時間給「Internal Product Owner」，讓他可以扮演好這個角色。

***

最近重讀Alexander的《Notes on the Synthesis of Form》，再回頭思考這個問題。假設在導入Scrum之前，開發團隊與客戶的溝通模式，可能是下方左圖或右圖的狀態：溝通複雜度過高（光是找到對人的來問問題就花了很多時間）或鮮少溝通（結案的時候才一翻兩瞪眼）。

         

 

如果是採用「標準版」的Scrum，團隊中會包含一位Product Owner（PO），由他來和客戶溝通需求。兩個子系統（客戶和開發）內部的溝通複雜度可以很高（內聚力很高），但子系統之間的溝通複雜度由Product Owner隔開（降低不必要的耦合）。

在「不知道誰是Product Owner」的情況下，Product Owner的責任由客戶與團隊共同分擔。其實開發團隊還是有一個主要的人扮演著「Internal Product Owner」的角色，只是扮演這個角色的人不願意公開承認（雖然再度違反了Scrum的規範，在這種情況下此人通常是由ScrumMaster兼任）。

***

Product Owner是一個很辛苦的工作，在某些專案中，要找到願意且有時間、有能力接受挑戰來擔任Product Owner的人的確是非常困難。公司內部IT部門協助其他部門的專案開發就是一個很典型的例子，接外包案的專案也有類似的問題。Teddy目前的經驗，在這種「不知道誰是Product Owner」的情況下要成功，最好要把握以下幾點原則才不至於逆練九陰真經練到走火入魔：

• 要把客戶洗腦到能夠接受專案採用value-driven的方式開發。
• 客戶要一起參加sprint planning meeting (part 1)與sprint review。
• 團隊指派一人作為「Internal Product Owner」，並給他足夠的時間來扮演好這個角色。
• 把客戶的考績跟自己的考績綁在一起（目標一致，大家在同一艘船上）。

***

友藏內心獨白：Alexander的書真的有提到內聚和耦合的觀念啊。