March 12 21:01~21:22
▼天滿宮前有名的夫妻樹。
▼天滿宮正殿外圍。
▼小貓咪一隻。
▼天滿宮正殿
▼整隊帶來參拜的高中生。
▼有人在表演猴戲XD。
▼好多鄉民圍觀。
▼天滿宮入口的神牛，被摸到發亮。
***
友藏內心獨白：學問之神魅力無法擋。
l
2016年4月23日 星期六
2016年4月22日 星期五
敏捷方法，瀑布思維
April 22 10:59~11:38
▲只想依賴文件的敏捷就不敏捷了
瀑布流程與從小到大所受的訓練，使得開發人員習慣並且期待能夠在一個「相對不變」且有「標準答案」的基礎上從事開發活動。多年來開發人員被這種「按圖施工，保證成功」的瀑布思維訓練得非常成功，以至於既使轉移到採用敏捷方法，但瀑布思維卻根深蒂固存在開發人員的心中，成為不可分割的一部分。
***
在Sprint planning meeting的時候…
開發人員：這個user story你可以寫詳細一點嗎，或是等你想清楚了之後我們再做，否則到時候做好你又要改，這樣子我們很麻煩耶。
Product Owner內心獨白：我就是要等看到成品之後才有更進一步的想法啊。
***
在Sprint review meeting的時候…
Stakeholder：這個產生畢業證書電子檔的功能目前可以修改人名跟證書號碼，但是畢業日期跟科系為什麼是寫死不能修改的？
開發人員：這是Product Owner要求的。
Stakeholder：Product Owner為什麼要做這樣的限制，你在開發這個功能的時候不會覺得怪怪的嗎？
開發人員：Product Owner就要求這樣做，我們就照做啊。
***
敏捷開發是一種迭代與增量式開發，講難聽一點就是「重工（rework）」。如果一件事情可以按部就班一次做好，為什麼要用迭代與增量的方式？這不是很浪費生命、浪費資源嗎？就是因為需求、技術、外在環境等存在相當高程度的不確定性或風險，導致沒辦法「一槍斃命」，一口氣就做出使用者心中想要的產品，所以只好退而求其次，採用且戰且走，摸著石子過河的策略。
在敏捷開發中，如果鄉民們心裡還想著給我一份超完美文件我才願意開工，或是想要採取「只動你手，不動你腦」的方式完成開發工作（一個口令，一個動作），專案的成果幾乎不會因為「型式上敏捷」或是「嘴皮子上敏捷」而產生任何改善，只會變得更糟。
***
友藏內心獨白：嘴巴說敏捷，身體倒是挺誠實的嘛。
2016年4月21日 星期四
透過體驗理解
April 20 10:25~11:28
▲從旅館往外拍的雪景
今年初以來一直在思考一個問題：「知道，但做不到，還算是知道嗎？」
例如，有時候在Facebook上看到正在休假中的朋友不斷貼出洗板旅遊文，當下心中會想：「出去玩有必要把打卡當作麵包屑來標註行走路徑嗎？要不要直接即時轉播算了。」但是輪到自己出遊的時候，卻犯了同樣的毛病，不斷地想要張貼和旅遊相關的照片。
知道不應該這麼做，但自己卻做不到，就不能算是真正的知道吧？
***
同樣的情境還有很多，例如有時候跟朋友討論事情…
Teddy：這個東西是這樣…那樣…
朋友：你說的這些我都知道啊。
過一陣子，朋友做了某種事…
Teddy：你不是說你都知道到，怎麼還會這麼做？
朋友：就…從失敗中學習嘛…
那你原本到底是真知道，還是假知道哩？！雖說敏捷開發鼓勵「從失敗中學習」，但是每次的學習都是有成本的。有些事情風險與不確定性並不高，並不需要所有事情都透過「從失敗中學習」。舉個例子：
Teddy：大便不可以吃喔。
鄉民甲：好，我知道了。
幾天後
鄉民甲：哇賽，大便真的好難吃啊。
Teddy：你真的好有實驗精神
***
今年二月底Teddy到日本關西小旅行5天，為了親身實踐「做到才等於知道的道理」，出發前決定旅行期間不在Facebook上張貼任何與此次旅行有關的訊息。剛開始真的有點手癢，看到美景、美食，忍不住想要打個卡，所幸都忍住了。在回國前的那個凌晨，京都附近下起雪來，冷冷的夜晚搭配雪景，怎麼可以不「炫耀 分享」給在台灣的親朋好友？
「三月雪耶！反正都要回國了，打卡一下也沒什麼關係吧。」這樣的想法不斷浮現在腦中，但此時想起呂世浩老師在「史記（一）」所講過的一句話：「要嘛不忍，要忍就一忍到底」，最後還是忍住沒有貼文，總算成功達成任務XD。
四月初又去了一趟日本關西，這次去的比較久，10天。同樣，10天內沒有貼任何和旅遊有關的訊息。有了上次經驗之後，這次輕輕鬆鬆達成任務。但是，就在回國不久在Facebook看到某人的留言，大意如下：「貼旅遊照片不是為了炫耀，而是希望年老之後有個回憶。」這句話又把Teddy打回原形，對啊，該做的事還是可以做，貼不貼旅遊照片不是重點，覺得想要記錄，就貼，怕吵到別人，就設定合適的閱讀權限即可。課題分離，別人要怎麼想自己也管不著，這麼簡單的道理，居然繞了一圈才體會到啊。
***
昨晚睡前把《史上最強哲學入門》翻了一下，書中提到：
在東方，人們認為，凡事一定都要伴隨著足以感覺到「啊，原來是這樣啊，是這種情形！我懂啦！」的強烈體驗或實際感受，才能夠算真正理解。而這種「透過體驗真正理解」的狀態，稱為「開悟」，以和一般的了解區別。這種「透過體驗真正理解」（開悟），與「知道知識」之間，有著奇大無比的差異。
建築師Alexander說：「A pattern is a process and a thing」，知道「thing」不算真的知道，除非把process也走過一次，透過體驗理解，才能算是真知。
***
友藏內心獨白：要從實踐來判斷。
2016年4月20日 星期三
早餐店的新人
April 20 08:46~10:00
▲紫米飯糰和豆漿
今天早上到住家附近小巷口的中式早餐店買早餐。Teddy從小就知道這家店，它位於Teddy上小學的最短路徑之上。小時候這家店在賣甜不辣，非常好吃，湯也好喝，還記得小時候常常花一塊錢點一小碗甜不辣，就只是為了喝一碗湯（PS：Ｎ年前一元新台幣就可以點一小小小碗甜不辣XD）。
念國中之後搬了家，早餐店位於上學的最短路徑之外，也就甚少經過。後來不知從何時開始這家店改賣中式早餐，一直以來店內都只有兩位服務人員，雖然Teddy久久才去買一次早餐，但老闆似乎認得每一位客人，「一對一行銷」功夫做得很好。
今天點餐的時候發現有點不同，店內居然多了一位幫手。在等待取餐的過程中，Teddy發現一個有趣的現象可以用來解釋軟體專案的兩個特性：
在一個已經延遲的專案加入更多的人，只會讓專案更延遲
這句出自《人月神話》（The Mythical Man-Month）的經典語句相信很多鄉民都聽過。因為新人剛開始對專案不熟悉，很難有立即的貢獻，原本的老人還要花時間來培訓新人。而且團隊人數增加之後溝通的路徑（複雜度）也增加，在新人有生產力之前，反倒先拖累了原本的產能。
Teddy觀察到早餐店的新人主要的貢獻在於「打包」，例如倒一杯豆漿、把客戶點的餐點裝到塑膠袋這種不太需要腦力（技能），只需要體力的工作。至於哪些東西是哪一位客人點的、打包之後的餐點費用多少這些需要記憶、計算的能力，這位新人可以說是完全沒有，事事都要詢問老闆。
一個口令一個動作 VS 自組織
早餐店的兩位店員對於店內的事務非常熟練，搭配起來作業流程很順暢，但新人卻需要老人，特別是老闆，的指示，才知道要做什麼事。例如：
Teddy：老闆我要兩個紫米飯糰和一杯大杯溫豆漿，少糖。
老闆：（對著新人說）一杯大杯溫豆漿，少糖。
新人：好…
新人：這個蛋餅是誰的？
老闆：這位客人的。
新人：他的一共多少錢？
老闆：60元。
新人：（對著客人說）一共60元。
老闆：（做好兩個紫米飯糰）
老闆：這兩個紫米飯糰是這位先生的，還有一杯大杯溫豆漿。
新人：這樣多少錢？
老闆：85元。
新人：（對著Teddy說）一共85元。
看到這裡鄉民們是不是很想表演跌倒的姿勢？只能說新人好像HTTP一樣，沒有保存狀態的能力（stateless）而且還不支援session或cookie。所幸老闆的「多功能力與記憶能力太強」，扮演著超強控制器（controller）的角色，讓新人在「只動你手，不動你腦」的情況下，看起來還可以產生一點點貢獻。
難到這就是傳說中的thin client嗎？！
***
友藏內心獨白：感覺沒有幫到什麼忙啊XD。
2016年4月19日 星期二
看圖說故事（4）：Output、Outcome、Impact
April 19 10:26~11:18
▲圖片節錄自《User Story Mapping》一書
今天介紹《User Story Mapping》書中的一張圖，這張圖有兩個圓圈：
- Now：左邊的圓圈代表現況，在現況之中有幾張不開心的臉龐，代表存在著一些需求或是問題沒有被滿足或解決
- Later：右邊的圓圈代表未來，在未來之中有些臭臉變成笑臉，代表這些人的需求或是問題被滿足或解決
在從Now過度到Later之間，如果沒有做出任何改變，那麼Later就等於Now，臭臉還是臭臉。為了改變未來的世界（改變Later），我們（設計師、開發團隊、公司、組織、個人…）提出一些Ideas（想法）。為了落實Ideas所製造的產出物，稱為Output。
以軟體開發為例，最顯而易見的Output就是開發完成交付給使用者的功能，這也是一般用來衡量效率、生產力的指標。但是，大家都知道開發完成的許多功能實際上並不符合使用者所需，甚至做完之後從來沒被使用。所以作者認為Output並非產品開發的重點，Outcome才是重點。
***
Output對使用者所產生的影響稱為Outcome。
舉個例子，一個精神不濟的人獲得一杯咖啡和一杯冰開水。「咖啡」和「冰開水」就是Output，喝了冰開水雖然也可以提神，但它的提神效果（一般而言）並沒有咖啡來的好。所以對一個精神不濟的人而言，提供給他咖啡會比冰開水獲得更好的Outcome（更好的效果）。
Outcome代表「服用（套用）Output」所產生比較立即可見的效果，而Impact（影響）則是Outcome經過一段時間醞釀之後所形成的長期影響。例如，一位精神不濟的程式設計師，每天早上喝了一杯咖啡之後不但精神百倍，一整個月下來程式寫得更多，bug更少。這種效果就是好的Outcome所產生的Impact。
***
對於產品或軟體開發，在這張圖中所者提到兩個重點：
- 你的責任是改變世界，從Now變成Later。
- 在改變世界的過程中，要最小化Output，最大化Outcome與Impact。換句話說，做最少的事達到做大的效果。
***
友藏內心獨白：Output和Outcome沒有任何交集又稱為白忙一場。
2016年4月18日 星期一
5月份【軟體重構入門實作班】
April 15 11:00~11:40
重構（refactoring）是一種「不改變軟體外在行為的前提之下改善程式碼內部結構」的方法。無論是code-first開發模式（傳統的開發方法），或是test-first開發模式（測試驅動開發方法），再好的設計都可能隨著時間與需求變化而長歪掉。因此需要藉由重構來讓軟體系統維持一定程度的可讀、可修改與可擴充性，以避免軟體變成硬體，再也改不動它，影響產品及時上市的競爭力。
軟體重構領域包含好幾個議題，從《Refactoring: Improving the Design of Existing Code》書中提到最基礎的70幾個重構方法、重構為設計樣式、軟體架構層次的重構、既有系統重構、TDD與重構、測試案例重構、資料庫重構等。入門班的三天課程將以介紹經典的《Refactoring: Improving the Design of Existing Code》為主，採用「怪味道驅動（bad smell-driven）」的方式，系統化地介紹書中所提到22個造成設計不良的怪味道（bad smell），以及移除這些怪味道的重構方法。
在介紹完重構的基本知識之後，課程將分門別類地逐一討論22個怪味道，並且讓學員現場實作練習移除怪味道的重構方法。經過三天密集的練習，期望學員不但能夠具備看出自己專案中程式碼的怪味道的能力，更進一步可以套用所學的重構方法來改善軟體設計、提升物件導向設計能力，償還技術債。
課程重點包含：
- 什麼是重構？
- 軟體設計、重構與設計模式。
- 套用重構的工作流程與重構步驟。
- 物件導向設計原則。
- 22種怪味道這樣學就會了。
- 重構實作練習（提供Java程式碼，可pair programming結隊練習）。
- Refactoring to patterns練習。
- TDD與重構：Bowling Game Kata。
***
【軟體重構入門實作班】第一梯次已在今年三月順利結束，上課實況請參考：
▼課程實錄照片
***
友藏內心獨白：重構是確保clean code的必要技能。
2016年4月17日 星期日
2015北九州考察之旅Day7-B天開稻荷神社 & 戶外烏龍麵午餐
March 12 20:26~20:50
▼離開寧靜的光明禪寺走入太宰府境內，人潮馬上多出N倍。
▼Kay原本要到太宰府天滿宮後山某個地方爬山，但看了一下地圖覺得那個登山地點有點遠，於是改走另外一條山路，繞到太宰府天滿宮旁邊的天開稻荷神社。一方面爬到山，另一方面也不會離天滿宮太遠，以免體力耗盡搞到沒時間參觀天滿宮。
▼走到天開稻荷神社巧遇一群幼兒園小朋友在此野餐
***
▼在天開稻荷神社稍事休息之後往下走就回到太宰府天滿宮。過了這個小隧道看到一個茶屋。
▼肚子也餓了就在這裡吃午餐休息一下，兩碗烏龍麵合計才1180日圓，還附了一壺熱茶，便宜又可以吃飽。
***
友藏內心獨白：佛心價。
訂閱：
文章 (Atom)