March 12 22:36~23:26
▼今天要去柳川搭船和吃鰻魚飯。搭車地點一樣在西鐵天神驛。天公不作美，下著小雨。
▼在西鐵天神驛買了火車和船票的套票。有另一種套票是有包含鰻魚飯，但有限制店家，網路上也有人說好像分量會比較小。因為貪吃又怕找不到店家，所以沒有買包含鰻魚飯的套票。
***
▼一出柳川車站就看到船公司派人在車站內接人，等時間差不多一起帶隊搭小巴士前往搭船地點。
▼雖然下雨但不用怕，船家準備了超大件雨衣，人人有份。
▼一路上船夫不斷導覽，聽不懂日語完全不知道發生什麼事。不過中間船夫還穿插唱了3~4首日語歌，非常認真，令人佩服。
▼途中經過這家水邊小七，可以買點東西在船上吃。不過當天下雨沒有任何人光顧。
▼下船時把雨衣留在船上即可。
***
▼下船不遠處就是鰻魚飯老店本吉屋的分店，懶得走去本店就在這裡吃午餐。
▼點好餐之後先送上熱茶和一小盤烤鰻魚骨頭。這個烤鰻魚骨頭，越吃越順口，吃完好想再來一盤啊。
▼烤鰻魚飯好香，好好吃。
▼窗外就是河道，不斷有遊河的船隻經過。
▼兩人吃了6600日幣，約1896台幣。
***
友藏內心獨白：真的好吃。
April 26 08:53~10:21
4/21日第44次C. C. Agile活動邀請阿官來分享他在新創公司工作，奮鬥兩年的「失敗經驗」。創業的道理書上也許都有寫，但「當局者迷」，當自己身歷其境的時候，反倒察覺不出來。在阿官的結論中，提到一個觀點：「對新創公司而言，找到對的問題比做出功能來的重要。」
▼因此當你確定產品真的有市場之前，「品質不是那麼重要」。
▼換句話說，需求比品質來的重要。
***
除了阿官以外，網路上也有很多人分享過類似的經驗，有些人甚至用更聳動的方式宣稱：「對新創公司而言，什麼品質、流程都不重要，最重要是驗證你的產品符合客戶需要」。
品質到底重不重要？如果重要，是軟體生命週期中一直都重要，還是某個時間點之後才重要？可以透過犧牲品質來達成其他的目標嗎（例如趕工的時候犧牲品質）？
這個問題可以放到建築師Alexander的pattern框架中來思考。如果問題是：「品質是否重要？」為了回答這個問題，要先探索這裡所討論的「context」（情境）是什麼？以吃飯為例，用餐的品質是否重要？如果你是 金正恩 好野人或富二代，每餐都要到「星級餐廳」用餐可能是你的最低標準。如果你是三級貧戶或是正處於鬧飢荒時期的遊民，只要能夠維持生命跡象，任何可以入口的東西可能都是選項。
一個東西或是屬性的重要性，經常是經過權衡、取捨之後的判斷。例如，行車的安全性重不重要？當然重要啊，但你不會為了提高安全性而買一台坦克車上路，因為這樣就太over了。現實狀況是，你很可能為了經濟性的理由而犧牲（一點點）安全性。例如，因為價錢而選擇日系車款而非號稱「鋼板很厚」的歐系車款。
取捨的依據來自於達到force（作用力）之間的平衡關係。回到阿官的例子，他建議「當你確定產品真的有市場之前，品質不是那麼重要。」所以「尋找符合市場的產品」這個作用力在某個時間點大於「提供高品質產品」這個作用力。但是，這個取捨點不能太超過，導致「品質過低以至於妨礙新創公司尋找符合市場的產品」，取捨錯誤因此無法完成原本想要達到的目標。
***
很多問題的答案不是Yes/No那麼絕對，而是什麼東西多一點，什麼東西少一點的取捨平衡。「品質不是那麼重要」並不表示「品質（完全）不重要」。從Scrum的角度來談，你的DoD（definition of done）在「product market fit（PMF）」之前可以「鬆一點」，在PMF之後應該要嚴謹一點，這也是很常見的一種做法。
***
友藏內心獨白：對新創公司而言，老闆口袋的深度最重要。
April 25 16:18~16:56
有一位學生去年在北科大修了Teddy的兩門課，在修課期間他突然心血來潮，立下「每周寫一篇部落格文章」的心願。幾天前遇到他…
Teddy：你有還持續寫部落格嗎？
學生：現在沒有了…
Teddy：為什麼？
學生：前一陣子迷上玩game…寫部落格真的很難，經常腦袋空空不知道要寫什麼。
Teddy：是啊，是很難。定期寫部落格（或任何形式的寫作）是一種思考訓練，就是因為寫不出來才更要寫，這樣才可以訓練自己的思考。
學生：我很佩服你很輕易的就可以每天都寫一篇。
Teddy：錯，即使到現在，我寫一篇也都是很不容易的。我只是養成了習慣，把它當成一種強迫自己讀書與思考訓練的手段，同時也是一種自我行銷的方法，才堅持到現在。並不是我特別厲害，信手拈來就可以寫出一篇。
Teddy：你看看「搞笑談軟工」部落格，從2007年「開台」的那一年，只有4篇文章。2008與2009也各只有6篇和31篇文章，少的可憐。但2010與2011這兩年都超過100篇，平均3.x天就寫了一篇，代表我慢慢找到了可持續的節奏。也因為如此，2012年之後「發願」每天寫一篇這件事，並不是從0開始，而是一種持續做某件事的演化結果。如果從來沒寫過突然要每天都寫一篇，就好像現在要求你要寫日記一樣，能夠做到的人應該很少。
***
有人說成為專家需要一萬小時的（刻意）練習。這個練習的過程絕對不輕鬆，就算你的領域是遊戲，夠輕鬆有趣了吧！想要成為專家，或是職業選手，練習的過程一定也是十分辛苦。
與其等到某一天自己突然大澈大悟，文思泉湧，具備定期寫部落格文章（或做任何事情）的能力，還不如儘早練習，累積這種能力的基礎比較實在。
***
友藏內心獨白：幹嘛那麼累，不斷改變志向不就好了…Orz。
April 25 13:10~14:17
▲照片翻拍自《User Story Mapping》
採取用戶故事（user story）的團隊經常遭遇一個棘手的問題：「如何切出大小適中的用戶故事？」在〈需求的大小〉介紹過Investment Theme（投資主題）、Epic（史詩）、Feature（特性）、User Story（用戶故事）這種切割方法，今天要介紹《User Story Mapping》這本書的觀點。
《User Story Mapping》從三個角度來看用戶故事，由大而小分別是：
舉個例子，有不少敏捷開發團隊都有這種經驗，stakeholder（例如行銷或業務主管）在sprint review的時候一直批評團隊所完成的用戶故事「太小」，功能「太少」。聽到這種打槍式的「回饋意見」，團隊也覺得很無奈：「才兩個禮拜你是希望我們能做出多偉大的東西出來？敏捷開發本來就是迭代與增量開發，你要的這些功能不是我們不做，是安排在之後的sprint才會做。」
因為行銷或業務主管腦想看到的是「商業層面有價值的用戶故事」，但是團隊此次所展示的只是「這個sprit所完成的用戶故事」，兩者的範圍相差太大，所以產生認知上的落差。
***
「《User Story Mapping》認為，不管是叫epic或是feature，它們都是一種user story。所以當stakeholder或是Product Owner提出一個想法，團隊不要用「這是一個epic喔，你還沒想清楚，請把它切成user story再來討論」這種態度打發對方。而是應該透過雙方對話，一起合作切割成開發團隊所能夠施工的user story，這才是一種健康的協作模式。
▲照片翻拍自《User Story Mapping》
用戶故事中的霸主，還是用戶故事。
***
友藏內心獨白：大小不是問題，有沒有對話才是重點。
April 25 11:40~12:47
先打個廣告，五月份「單元測試與持續整合實作班」確定開課，早鳥優惠到4/30日截止。
***
上禮拜六剛上完「Design Patterns這樣學就會了–入門實作班」，和往常一樣，每個梯次都會有學員問到：
除了上述問題，這梯次的學員有人特別關注：「要做到pattern所提供的功能，也可以用其他方法啊，為什麼要套pattern哩？」例如，在Factory Method中產生產品類別（product）的責任交由子類別決定。要做到相同的功能，也可以不要使用繼承，只需要傳一個callback function給父類別就可以了啊。
沒錯，如果光從「功能面」，也就是解決方案（solution）的角度來看，有好幾個方法都可以達到同樣的功能。但是，pattern不是只有解決方案，還包含context、problem、force、resulting context這些元素。Teddy遇到不少學員，在學習pattern的時候都是從解決方案的角度來學習與應用pattern。如果學習pattern只看到解決方案，pattern所帶來的麻煩很可能比它所帶來的好處還要來的多。
舉個例子，如果只是為了填飽肚子，你可以選擇：
你可以花一整天來爭吵上面這麼多個解決方案哪一個才可以用來「填飽肚子」，甚至你可以額外再列出100個替代方案。光是從解決方案的角度來討論意義不大，因為它們都可以解決「填飽肚子」這個問題，吵到最後變成意氣之爭。所以，一定有其他force（因素）影響著我們如何找到一個合適的解決方案。
***
歌手黃小琥曾經唱過「不只是朋友」，在這首歌中有一句歌詞：
你從不知道我想做的不只是朋友
在軟體開發中，這句歌詞可以改成：
你從不知道我想要的不只是會動
男女雙方如果真得很喜歡對方，光是做朋友還不夠，還希望能夠以結婚為前提交往。軟體開發也一樣，如果你很重視你的客戶與團隊，程式一定要可以動，但光可以動還不夠，還要考慮各種品質屬性（非功能需求）是否滿足。
哪些品質因素？軟體架構中那些以ability結尾的英文單字，例如：
以Testability（可測性）來看，許多人不知道怎麼做自動化測試，並不是真的不會「測試」這個技能，而是因為「待測物」設計的太爛，導致測試極端困難。軟體開發的核心技能，像是流程、設計、實作、測試、重構、架構，看起來是個別獨立的不同能力，實際上是互相緊密關聯的一個體系。
所以，學習pattern不能只看pattern，還要探討pattern在流程、設計、實作、測試、架構、重構中所扮演的角色。同樣，學習測試也不能光看測試，還要探討測試在流程、設計、實作、架構、重構中所扮演的角色。學習流程也一樣，要關注其他非流程的面向。依此類推，久而久之觀察force的能力就越來越強，解決問題的能例也越來越好。
***
友藏內心獨白：要建立關聯，不要製造孤島。
April 22 22:10~23:59
《User Story Mapping》書中對於軟體開發有一段很有趣的描述，有一首歌的歌詞提到：
You can't always get what you want. But, if you try sometime, you just might find, you get what you need（你不可能永遠得到你想要的。但是，如果你嘗試一段時間，你也許會發現，你會得到你所需要的東西）。
軟體開發和上面這段歌詞剛好相反，如果你（product onwer）和一個有能力的團隊一起合作，在sprint review的時候你總是可以獲得what you want（你和團隊在sprint planning時所同意的user story內容），但只有在看到結果之後，你才能夠更進一步評估什麼才是what you need。請不要責怪你自己，軟體開發的本質就是如此。
***
用戶真正的需求（need）通常要等到看到產品之後才會慢慢變得具體，這個道理雖然簡單，但當自己成為開發團隊的一員的時候，常常陷入當局者迷的陷阱：
雖然搞敏捷的人都說要「擁抱改變」。是啊，出一張嘴叫別人擁抱改變很簡單，輪到自己的時候，改變距離你還有100公里你就已經覺得「溫度太熱」，想辦法找個涼一點的地方躲起來先。
***
《User Story Mapping》的作者在書中提到Alistair Cockburn曾經告訴過他：「每一個user story在product backlog裡面都應該有三個項目來代表它。哪三個？第一個項目是原本要做的那個user story，第二個項目是修改第一個項目，第三個項目是修改第二個項目。如果你的product backlog不是這樣，你就沒有在學習。」
每個功能做好之後還要再修改兩次，只是剛剛好而已啊。
***
友藏內心獨白：可以有不改程式又擁抱改變的方法嗎？
March 12 21:35~22:10
▼大部分遊客參觀完天滿宮應該就結束太宰府行程，Kay還安排到離天滿宮走路有20~30十分鐘的太宰府跡。基本上日本旅遊手冊上，凡是印有「跡」字的景點，就是遺跡的意思，也就是沒什麼東西可以看，可以省略。因為我們要順便散散步，所以才安排去太宰府跡。
▼經過一片農田之後，到達太宰府跡。一大片空地只剩下地上的地基，可以看得出來古時建築物的範圍。
***
▼在太宰府跡待了一下下就打道回府。回程走另一條路經過觀音寺，這裡古色古香，幾乎沒有遊客，在此稍作休息，算是意外的收穫。
▼離開觀音寺往太宰府驛準備搭車回福岡西鐵天神驛
▼太宰府驛
***
▼福岡西鐵天神驛外圍。
▼晚餐就在這附近的百貨公司裡面的一家咖啡廳用餐。咖啡出乎意料的好喝，餐點也不錯，價格也不貴，用餐環境用好，非常棒的一家店。
***
友藏內心獨白：以好喝咖啡畫下當天完美的句點。
