l

2016年4月30日 星期六

2015北九州考察之旅Day8-A乘船遊柳川 & 本吉屋吃鰻魚飯

March 12 22:36~23:26

▼今天要去柳川搭船和吃鰻魚飯。搭車地點一樣在西鐵天神驛。天公不作美,下著小雨。

螢幕截圖 2016-03-12 22.37.13

 

▼在西鐵天神驛買了火車和船票的套票。有另一種套票是有包含鰻魚飯,但有限制店家,網路上也有人說好像分量會比較小。因為貪吃又怕找不到店家,所以沒有買包含鰻魚飯的套票。

螢幕截圖 2016-03-12 22.37.28

螢幕截圖 2016-03-12 22.37.45螢幕截圖 2016-03-12 22.38.00

***

▼一出柳川車站就看到船公司派人在車站內接人,等時間差不多一起帶隊搭小巴士前往搭船地點。

螢幕截圖 2016-03-12 22.44.05

螢幕截圖 2016-03-12 22.44.23螢幕截圖 2016-03-12 22.49.32螢幕截圖 2016-03-12 22.49.44

 

▼雖然下雨但不用怕,船家準備了超大件雨衣,人人有份。

螢幕截圖 2016-03-12 22.50.45

 

▼一路上船夫不斷導覽,聽不懂日語完全不知道發生什麼事。不過中間船夫還穿插唱了3~4首日語歌,非常認真,令人佩服。

螢幕截圖 2016-03-12 22.53.15

螢幕截圖 2016-03-12 22.49.59螢幕截圖 2016-03-12 22.51.21螢幕截圖 2016-03-12 22.51.29螢幕截圖 2016-03-12 22.51.53螢幕截圖 2016-03-12 22.52.05螢幕截圖 2016-03-12 22.52.19螢幕截圖 2016-03-12 22.53.57螢幕截圖 2016-03-12 22.54.09螢幕截圖 2016-03-12 22.54.45螢幕截圖 2016-03-12 22.55.09螢幕截圖 2016-03-12 22.56.08螢幕截圖 2016-03-12 22.57.14

 

▼途中經過這家水邊小七,可以買點東西在船上吃。不過當天下雨沒有任何人光顧。

螢幕截圖 2016-03-12 22.55.45

 

▼下船時把雨衣留在船上即可。

螢幕截圖 2016-03-12 22.57.26

***

▼下船不遠處就是鰻魚飯老店本吉屋的分店,懶得走去本店就在這裡吃午餐。

螢幕截圖 2016-03-12 23.08.49

 

▼點好餐之後先送上熱茶和一小盤烤鰻魚骨頭。這個烤鰻魚骨頭,越吃越順口,吃完好想再來一盤啊。

螢幕截圖 2016-03-12 23.07.24

 

▼烤鰻魚飯好香,好好吃。

螢幕截圖 2016-03-12 23.07.52螢幕截圖 2016-03-12 23.08.18

 

▼窗外就是河道,不斷有遊河的船隻經過。

螢幕截圖 2016-03-12 23.07.38螢幕截圖 2016-03-12 23.08.25

 

▼兩人吃了6600日幣,約1896台幣。

螢幕截圖 2016-03-12 23.08.07

***

友藏內心獨白:真的好吃。

2016年4月29日 星期五

品質的取捨

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之後應該要嚴謹一點,這也是很常見的一種做法。

***

友藏內心獨白:對新創公司而言,老闆口袋的深度最重要。

2016年4月28日 星期四

刻意練習

April 25 16:18~16:56

螢幕截圖 2016-04-25 16.21.55

 

有一位學生去年在北科大修了Teddy的兩門課,在修課期間他突然心血來潮,立下「每周寫一篇部落格文章」的心願。幾天前遇到他…

Teddy:你有還持續寫部落格嗎?

學生:現在沒有了…

Teddy:為什麼?

學生:前一陣子迷上玩game…寫部落格真的很難,經常腦袋空空不知道要寫什麼。

Teddy:是啊,是很難。定期寫部落格(或任何形式的寫作)是一種思考訓練,就是因為寫不出來才更要寫,這樣才可以訓練自己的思考。

學生:我很佩服你很輕易的就可以每天都寫一篇。

Teddy:錯,即使到現在,我寫一篇也都是很不容易的。我只是養成了習慣,把它當成一種強迫自己讀書與思考訓練的手段,同時也是一種自我行銷的方法,才堅持到現在。並不是我特別厲害,信手拈來就可以寫出一篇。

Teddy:你看看「搞笑談軟工」部落格,從2007年「開台」的那一年,只有4篇文章。2008與2009也各只有6篇和31篇文章,少的可憐。但2010與2011這兩年都超過100篇,平均3.x天就寫了一篇,代表我慢慢找到了可持續的節奏。也因為如此,2012年之後「發願」每天寫一篇這件事,並不是從0開始,而是一種持續做某件事的演化結果。如果從來沒寫過突然要每天都寫一篇,就好像現在要求你要寫日記一樣,能夠做到的人應該很少。

***

有人說成為專家需要一萬小時的(刻意)練習。這個練習的過程絕對不輕鬆,就算你的領域是遊戲,夠輕鬆有趣了吧!想要成為專家,或是職業選手,練習的過程一定也是十分辛苦。

與其等到某一天自己突然大澈大悟,文思泉湧,具備定期寫部落格文章(或做任何事情)的能力,還不如儘早練習,累積這種能力的基礎比較實在。

***

友藏內心獨白:幹嘛那麼累,不斷改變志向不就好了…Orz。

2016年4月27日 星期三

用戶故事中的霸主

April 25 13:10~14:17

螢幕截圖 2016-04-25 13.59.24

▲照片翻拍自《User Story Mapping》

 

採取用戶故事(user story)的團隊經常遭遇一個棘手的問題:「如何切出大小適中的用戶故事?」在〈需求的大小〉介紹過Investment Theme(投資主題)、Epic(史詩)、Feature(特性)、User Story(用戶故事)這種切割方法,今天要介紹《User Story Mapping》這本書的觀點。

《User Story Mapping》從三個角度來看用戶故事,由大而小分別是:

  • 商業(Business):從企業的角度來看,可以幫助企業達到某些商業上的成果。
  • 用戶與客戶:滿足用戶或是顧客的需要。
  • 開發團隊:開發團隊能夠在幾天內做完。

舉個例子,有不少敏捷開發團隊都有這種經驗,stakeholder(例如行銷或業務主管)在sprint review的時候一直批評團隊所完成的用戶故事「太小」,功能「太少」。聽到這種打槍式的「回饋意見」,團隊也覺得很無奈:「才兩個禮拜你是希望我們能做出多偉大的東西出來?敏捷開發本來就是迭代與增量開發,你要的這些功能不是我們不做,是安排在之後的sprint才會做。」

因為行銷或業務主管腦想看到的是「商業層面有價值的用戶故事」,但是團隊此次所展示的只是「這個sprit所完成的用戶故事」,兩者的範圍相差太大,所以產生認知上的落差。

***

「《User Story Mapping》認為,不管是叫epic或是feature,它們都是一種user story所以當stakeholder或是Product Owner提出一個想法,團隊不要用「這是一個epic喔,你還沒想清楚,請把它切成user story再來討論」這種態度打發對方。而是應該透過雙方對話,一起合作切割成開發團隊所能夠施工的user story,這才是一種健康的協作模式。

螢幕截圖 2016-04-25 14.08.34

▲照片翻拍自《User Story Mapping》

 

用戶故事中的霸主,還是用戶故事。

***

友藏內心獨白:大小不是問題,有沒有對話才是重點。

2016年4月26日 星期二

不只是會動

April 25 11:40~12:47

IMG_1124

 

先打個廣告,五月份「單元測試與持續整合實作班」確定開課,早鳥優惠到4/30日截止。

***

上禮拜六剛上完「Design Patterns這樣學就會了–入門實作班」,和往常一樣,每個梯次都會有學員問到:

  • 不同pattern之間的差異與比較
  • 為什麼某個pattern要這麼做而不那麼做
  • 如何知道什麼時候要套用哪個pattern
  • 怎麼判斷所套用的pattern是否合適而不會導致過度設計(over design)

除了上述問題,這梯次的學員有人特別關注:「要做到pattern所提供的功能,也可以用其他方法啊,為什麼要套pattern哩?」例如,在Factory Method中產生產品類別(product)的責任交由子類別決定。要做到相同的功能,也可以不要使用繼承,只需要傳一個callback function給父類別就可以了啊。

沒錯,如果光從「功能面」,也就是解決方案(solution)的角度來看,有好幾個方法都可以達到同樣的功能。但是,pattern不是只有解決方案,還包含context、problem、force、resulting context這些元素。Teddy遇到不少學員,在學習pattern的時候都是從解決方案的角度來學習與應用pattern。如果學習pattern只看到解決方案,pattern所帶來的麻煩很可能比它所帶來的好處還要來的多

舉個例子,如果只是為了填飽肚子,你可以選擇:

  • 便當
  • 三明治
  • 拉麵
  • 牛排
  • 義大利麵
  • 漢堡
  • 水果
  • 沙拉
  • 夜市小吃
  • 喝水
  • 減肥餐
  • 別人吃剩的食物

你可以花一整天來爭吵上面這麼多個解決方案哪一個才可以用來「填飽肚子」,甚至你可以額外再列出100個替代方案。光是從解決方案的角度來討論意義不大,因為它們都可以解決「填飽肚子」這個問題,吵到最後變成意氣之爭。所以,一定有其他force(因素)影響著我們如何找到一個合適的解決方案。

IMG_1145

***

歌手黃小琥曾經唱過「不只是朋友」,在這首歌中有一句歌詞:

你從不知道我想做的不只是朋友

在軟體開發中,這句歌詞可以改成:

你從不知道我想要的不只是會動

男女雙方如果真得很喜歡對方,光是做朋友還不夠,還希望能夠以結婚為前提交往。軟體開發也一樣,如果你很重視你的客戶與團隊,程式一定要可以動,但光可以動還不夠,還要考慮各種品質屬性(非功能需求)是否滿足。

哪些品質因素?軟體架構中那些以ability結尾的英文單字,例如:

  • Testability
  • Modifiability
  • Usability
  • Scaiability

以Testability(可測性)來看,許多人不知道怎麼做自動化測試,並不是真的不會「測試」這個技能,而是因為「待測物」設計的太爛,導致測試極端困難。軟體開發的核心技能,像是流程、設計、實作、測試、重構、架構,看起來是個別獨立的不同能力,實際上是互相緊密關聯的一個體系。

所以,學習pattern不能只看pattern,還要探討pattern在流程、設計、實作、測試、架構、重構中所扮演的角色。同樣,學習測試也不能光看測試,還要探討測試在流程、設計、實作、架構、重構中所扮演的角色。學習流程也一樣,要關注其他非流程的面向。依此類推,久而久之觀察force的能力就越來越強,解決問題的能例也越來越好。

***

友藏內心獨白:要建立關聯,不要製造孤島。

2016年4月25日 星期一

從想要到需要

April 22 22:10~23:59

螢幕截圖 2016-04-23 00.11.39

 

《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)通常要等到看到產品之後才會慢慢變得具體,這個道理雖然簡單,但當自己成為開發團隊的一員的時候,常常陷入當局者迷的陷阱:

  • 什麼,又要修改功能?你能不能一次說清楚啊。
  • 什麼,你還沒想清楚?你負責定義需求的人都不知道,那我要怎麼寫程式?
  • 我不知道啊,user story(或需求分析書)就是這樣子寫的,我只是照著規格做,不關我的事啊。

雖然搞敏捷的人都說要「擁抱改變」。是啊,出一張嘴叫別人擁抱改變很簡單,輪到自己的時候,改變距離你還有100公里你就已經覺得「溫度太熱」,想辦法找個涼一點的地方躲起來先。

***

《User Story Mapping》的作者在書中提到Alistair Cockburn曾經告訴過他:「每一個user story在product backlog裡面都應該有三個項目來代表它。哪三個?第一個項目是原本要做的那個user story,第二個項目是修改第一個項目,第三個項目是修改第二個項目。如果你的product backlog不是這樣,你就沒有在學習。

每個功能做好之後還要再修改兩次,只是剛剛好而已啊。


***

友藏內心獨白:可以有不改程式又擁抱改變的方法嗎?

2016年4月24日 星期日

2015北九州考察之旅Day7-D太宰府跡 & 西鐵天神驛附近晚餐

March 12 21:35~22:10

▼大部分遊客參觀完天滿宮應該就結束太宰府行程,Kay還安排到離天滿宮走路有20~30十分鐘的太宰府跡。基本上日本旅遊手冊上,凡是印有「跡」字的景點,就是遺跡的意思,也就是沒什麼東西可以看,可以省略。因為我們要順便散散步,所以才安排去太宰府跡。

螢幕截圖 2016-03-12 21.27.19

螢幕截圖 2016-03-12 21.26.58螢幕截圖 2016-03-12 21.27.33螢幕截圖 2016-03-12 21.27.48

 

▼經過一片農田之後,到達太宰府跡。一大片空地只剩下地上的地基,可以看得出來古時建築物的範圍。

螢幕截圖 2016-03-12 21.28.27

螢幕截圖 2016-03-12 21.28.14螢幕截圖 2016-03-12 21.28.43螢幕截圖 2016-03-12 21.29.15螢幕截圖 2016-03-12 21.29.27螢幕截圖 2016-03-12 21.29.38螢幕截圖 2016-03-12 21.29.49

***

▼在太宰府跡待了一下下就打道回府。回程走另一條路經過觀音寺,這裡古色古香,幾乎沒有遊客,在此稍作休息,算是意外的收穫。

螢幕截圖 2016-03-12 21.30.04螢幕截圖 2016-03-12 21.30.56螢幕截圖 2016-03-12 21.32.29

螢幕截圖 2016-03-12 21.30.18螢幕截圖 2016-03-12 21.30.29螢幕截圖 2016-03-12 21.30.37螢幕截圖 2016-03-12 21.30.46螢幕截圖 2016-03-12 21.31.16螢幕截圖 2016-03-12 21.31.45螢幕截圖 2016-03-12 21.32.07

 

▼離開觀音寺往太宰府驛準備搭車回福岡西鐵天神驛

螢幕截圖 2016-03-12 21.32.51螢幕截圖 2016-03-12 21.33.04螢幕截圖 2016-03-12 21.33.24

 

▼太宰府驛

螢幕截圖 2016-03-12 21.57.11

***

▼福岡西鐵天神驛外圍。

螢幕截圖 2016-03-12 21.59.28螢幕截圖 2016-03-12 21.59.36螢幕截圖 2016-03-12 21.59.59

 

▼晚餐就在這附近的百貨公司裡面的一家咖啡廳用餐。咖啡出乎意料的好喝,餐點也不錯,價格也不貴,用餐環境用好,非常棒的一家店。

螢幕截圖 2016-03-12 22.04.50螢幕截圖 2016-03-12 22.05.07

螢幕截圖 2016-03-12 22.05.13螢幕截圖 2016-03-12 22.05.20螢幕截圖 2016-03-12 22.05.36螢幕截圖 2016-03-12 22.05.48螢幕截圖 2016-03-12 22.06.02螢幕截圖 2016-03-12 22.09.35

***

友藏內心獨白:以好喝咖啡畫下當天完美的句點。