l

2013年8月31日 星期六

2013金門考察之旅Day3-B大武山國軍公墓_金城鎮老街

August 29 22:45~23:51

離開太武山之後回飯店稍做休息,中午來到金城老街吃飯,吃完飯之後順便逛一下老街。其實前一點晚上Kay和Teddy參加一個免費的夜間導覽行程,由義工帶領介紹了十幾個金城老街的景點。因為是夜間導覽,所以有些景點看得不太清楚,利用中午吃飯的機會順便再來複習一下。

首先看到國定古蹟「邱良功母節孝坊」,一般簡稱稱為「貞節牌坊」,建於清朝嘉慶十七年(1812年)。牌坊在表揚清朝浙江水師提督邱良功的母親許氏守節二十八年的事蹟。

螢幕快照 2013-08-29 下午10.54.35

 

牌坊下方的石獅子,有分公、母。猜得出來哪一隻是公的,哪一隻是母的嗎?

螢幕快照 2013-08-29 下午10.54.47

 

老街。

螢幕快照 2013-08-29 下午10.55.24

螢幕快照 2013-08-29 下午10.55.17

 

將軍第,清朝武顯將軍「盧成金」的府第,建於清光緒七年(1881年)左右。

螢幕快照 2013-08-29 下午11.35.00

螢幕快照 2013-08-29 下午11.35.12

螢幕快照 2013-08-29 下午11.35.35

 

陳氏宗祠,據說擁有附近很多土地、房屋。

螢幕快照 2013-08-29 下午10.55.08

陳詩吟洋樓,不過因為產權的關係目前並沒有開放,很可惜。

螢幕快照 2013-08-29 下午10.55.59

 

這棟洋樓有很多有趣的裝飾,請看。

螢幕快照 2013-08-29 下午10.56.06

螢幕快照 2013-08-29 下午10.56.16

 

吹喇叭的天使。

螢幕快照 2013-08-29 下午10.56.33

 

放大一點來看。

螢幕快照 2013-08-29 下午11.28.52

 

中間這一位還倒立著扛柱子,好功夫啊挑眉質疑

螢幕快照 2013-08-29 下午10.56.54

 

非常漂亮的陳詩吟洋樓,希望能早日解決產權的問題,整修好之後開放給民眾參觀。

螢幕快照 2013-08-29 下午10.57.11

螢幕快照 2013-08-29 下午10.57.23

 

陳詩吟洋樓旁邊就是奎閣,裡面供奉著魁星。因為古時候金門不是縣級單位,所以不能蓋孔廟,只能蓋次一級的奎閣。

螢幕快照 2013-08-29 下午10.57.33

螢幕快照 2013-08-29 下午10.57.43

 

城隍廟,金門古稱浯洲,所以叫做浯島城隍廟。

螢幕快照 2013-08-29 下午10.58.49

螢幕快照 2013-08-29 下午10.59.00

***

友藏內心獨白:洋樓的設計師還挺幽默的。

2013年8月30日 星期五

盲目變動與選擇性保留

August 27 16:14~17:50

image

 

兩個禮拜前讀了《科學人》雜誌上面一篇名為「天才的條件」的文章,其中有一句話讓Teddy感到非常的有趣:

所有的天才可能都擁有相同的心理歷程:盲目變動選擇性保留

「盲目變動」與「選擇性保留」,這麼有趣的兩個動作,似乎可以拿來解釋很多現象。在這裡Teddy跟鄉民們分享兩個想法:演化創意思考

***

演化

演化的過程,可以簡單的用「物競天擇,優勝劣敗」來形容。有人認為演化是一種「天擇(上天選擇或自然選擇)」的過程,其中包含了四個階段:

  • 個體差異
  • 過度繁殖
  • 生存競爭
  • 適者生存

個體差異是由於基因突變而產生新的品種或是外觀與功能上與原先品種不同的相同物種。由於「基因突變」無法預測,因此可以把它視為一種「盲目變動」的起源。至於「生存競爭」和「適者生存」,則可以看做是「選擇性保留」的過程與結果。

螢幕快照 2013-08-27 下午4.28.15

***

創意思考

先來一段「免責聲明」,Teddy不是創意專家,單純是紙上談兵。

接下來用創意思考界經常引用的「設計思考(design thinking)」的五個流程作為類比的對象:

  • Empathize(同理心)
  • Define(定義問題)
  • Ideate  (創意發想)
  • Prototype(雛型製作)
  • Test(雛型測試)

以Teddy對設計思考有限的理解,下圖是將「盲目變動」與「選擇性保留」對應到設計思考五個步驟的結果。

螢幕快照 2013-08-27 下午5.00.55

***

然後哩

看到這裡鄉民們可能會想:然後哩?從「設計」的角度來看,演化其實是一種非常好的設計方法。例如,海底生物可以直接深潛到幾千公尺的海底,而要設計一個可以跑到幾千公尺深的海底的潛水艇則是非常困難的工作。但是,演化的「設計成品」雖好,一般而言演化的兩個重要過程--個體變異與天擇--其結果需要經歷很長的一段時間才會達到穩定的狀態。因此人為設計如果要學習演化的設計模式,勢必需要想辦法加速這個過程。

Teddy認為,很多創意思考所採用的「腦力激盪」或是「集體創意發想」的方法,就是一種加速模擬「個體變異」或是「盲目變動」的過程。接著透過人為的「選擇性保留」,來得到創意設計的結果。

就醬子,報告完畢。

***

友藏內心獨白:愛蜜莉 Teddy的異想世界…該去打水漂了嗎挑眉質疑

2013年8月29日 星期四

從Scrum到Scrumban的經驗

August 28 16:00~18:52

螢幕快照 2013-08-28 下午6.55.19

 

繼《系統管理團隊結合Kanban與Scrum的經驗》以及《遊戲團隊結合Agile與Kanban的經驗》之後,今天要介紹一篇發表在Software and System Process (ICSSP), 2012研討會的論文,名為:《From Scrum to Scrumban: A Case Study of a Process Transition》。

不了解Scrumban的鄉民們可以參考《What is Scrumban?》這篇文章。如果要更深入學習Scrumban,則可以參考Corey Ladas所寫的《Scrumban: Essays on Kanban Systems for Lean Software Development》這本書。

***

背景介紹

這篇論文介紹一間代號為CMSiPro的瑞典公司從Scrum過渡到Scrumban的歷程以及從中學習到的經驗。這家公司在全球十個國家設有行銷與業務辦公室,在瑞典的斯德哥爾摩有一個開發團隊,越南的河內則有另一個開發團隊與一個測試團隊;每個工程團隊有15~20位工程師。Product Owner團隊則是分散在瑞典和丹麥

螢幕快照 2013-08-28 下午6.12.59

***

遇到的問題

CMSiPro公司的開發團隊遇以下這些問題:

  1. 跨國團隊溝通不良
  2. 分散式團隊工作協調不順
  3. 沒有做好需求變動追朔(requirements change traceability)
  4. 沒有定義DoD(Definition of Done)
  5. 急就章的短期解決方案:這一點很重要,Teddy遇到的很多團隊也都有這樣的問題,所以要特別解釋一下。因為Scrum團隊成員會有一種想要在sprint結束前完成所有sprint planning meeting所挑選出來的story的傾向(怕沒做完會被以為工作成效不彰),因此經常會採取急就章的解決方法,甚至是犧牲程式碼的品質,讓story「看起來好像完成了」。這個問題的原因,部分與團隊沒有定義明確的DoD也有關係。
  6. 程式碼被合併之後就沒什麼人敢修改:只有在每個sprint結束的時候才會合併(merge)程式碼並且開始整合。一旦合併的過程結束之後,就算是覺得現有的程式碼有可以改進之處,但是因為怕麻煩與出錯,所以大家就不想去動合併後的程式。久而久之,累積的技術債就越來越多。
  7. 管理階層對於問題的回饋反應很慢:這一點…不用解釋了,大部分的公司都一樣挑眉質疑
  8. 對於流程的知識與承諾不足:這一點用Teddy的話來說,就是「他們以為自己在實施Scrum,其實他們是在run…(自己接)」。
  9. 不夠開誠布公:根據作者的說法,因為越南團隊(儒家文化?!)比較害羞跟謙虛,所以有些問題會放在心裡不敢直接表達出來。
  10. 技術債不斷的增加:反正程式可以動就好了啊不要告訴別人
  11. 流程改善相關的活動優先權都很低:這一點也是很常見的問題,PO總是想要多做一點功能,持續改善是什麼,可以吃嗎?挑眉質疑
  12. 沒有效率的開發流程:綜合以上這麼多問題,開發流程當然不可能有效率。

以上這些問題,Teddy在帶領Scrum團隊的時候也經常遇到,算是很典型的問題。

***

Scrum到Scrumban的過程

這篇論文花了很多篇幅在敘述從Scrum改用Scruban的過程,看完這些過程之後,Teddy只想說:「瑞典人做事,真的很嚴謹」挑眉質疑。這些細節就容Teddy跳過不表,引用論文裡面的一張圖來蒙混過去XD。

螢幕快照 2013-08-28 下午6.22.03

***

經驗分享

對於之前提到的12點問題,作者談到改善後的結果:

  • 完全解決:2.分散式團隊工作協調不順、3.沒有做好需求變動追朔(requirements change traceability)、4.沒有定義DoD(Definition of Done)、6.程式碼被合併之後就沒什麼人敢修改、11.流程改善相關的活動優先權都很低
  • 部份解決:1.跨國團隊溝通不良、5.急就章的短期解決方案、8.對於流程的知識與承諾不足、9.不夠開誠布公、沒有效率的開發流程。
  • 沒有解決:7.管理階層對於問題的回饋反應很慢。
  • 正在解決中:10.技術債不斷的增加。

以上,嚴格講起來,都不是重點不要告訴別人。因為作者最後提到他們學到最重要的一件事,就是:

剛開始採用Scrum的時候所遭遇的問題,其實不是Scrum本身的問題,而是CMSiPro公司的Scrum實踐的很爛(the poor implementation of Scrum)。

類似的看法Henrik Kniberg也曾經提過,許多Kanban團隊是經由改用Kanban的過程而重新學習與了解Scrum。

總之,作者最後建議兩點:

  • 建立流程持續改善的機制。
  • 找到訓練良好並且願意投入承諾的員工。

這兩點基礎建設如果能夠做得到,很多問題都可以逐步被解決。

***

因為作者提到Scrum的教育訓練很重要,Teddy順勢再補充一點:「第七梯次Scrum敏捷方法實作班」招生中,這是本年度最後一梯次的Scrum公開班課程,準備或已經導入Scrum/Kanban但卻問題重重的鄉民們請多加利用熱戀

image

***

友藏內心獨白:整篇文章和Scrumban好像沒什麼關係。

2013年8月28日 星期三

Scrum 與 Kanban應用環境

August 27 13:50~15:40

image

 

昨天在《遊戲團隊結合Agile與Kanban的經驗》裡面Teddy引用了《Agile & Kanban In Coordination》這篇論文中的一張圖(如下圖所示),圖中用需求大小分類來決定需求要交給Iteration Team或是Kanban Team開發。

image

這種作法,讓Iteration Team與Kanban Team的工作輸入(需求)大小差異性不至於太大,這一點對於Iteration Team與Kanban Team來說都很重要。

  • Iteration Team:如果Iteration Team在每個sprint裡面需要處理的工作包含很大的story以及許多很小的story或是bug fix的工作,非常有可能發生有些開發人員忙著處理大型的story,而有些開發人員只處理小的工作。依據Teddy的親身經驗,這麼做可能會導致開發人員依據自己的「喜好」來決定施工的順序,而不是依據PO排定story優先順序來施工。有些人偏好處理小型且定義清楚的工作(比較沒挑戰性),或是處理一些需要花時間但不一定需要花腦筋且比較簡單的bug。長期以往,不利於團隊的知識交流與合作。此外,在sprint進行中如果發生突發狀況,臨時要處理一些緊急但是比較瑣碎或是小型的工作,例如解bug,如果要緊急插入到已經排定的工作項目之中,也是會打亂Iteration Team的開發步調(嚴格來講,以標準的Scrum團隊而言,sprint進行中最好不要安插新的工作)。
  • Kanban Team:工作大小不一對於Kanban Team可能造成更大的問題。由於Kanban Team沒有iteration的限制,所有的工作只測量lead time(交期,或稱為cycle time)。大小不一個工作,會讓Kanban Team的平均交期變得沒有意義,也很難觀察出團隊的進度或是生產力。

***

因材施教

鄉民們應該知道,軟體開發沒有銀子彈、萬靈丹這種東西,不同的專案屬性與團隊組成,需要不同的開發方式來配合。Michael Sahota寫了一篇名為《A model for understanding Scrum and Kanban》的文章,提到Scrum與Kanban的應用時機。文中有一張圖以「重複 VS. 創新」與「專注 VS. 中斷」的角度來探討Scrum與Kanban的使用時間,Teddy把它簡化之後如下圖所示。

螢幕快照 2013-08-27 下午1.57.36

 

把上圖分成五種不同的應用時機:

  • 專注-創新:這種類型的專案可以採用Scrum方法,包含產品開發、研究團隊等工作內容需要創新或是創作思維,也需要專注的時間來進行專案開發。因此套用iteration的步驟(固定的需求規劃、每日會議、成果檢視、自省會議)可以協助團隊在維持專注與創新的同時,也顧慮到是否持續交付對客戶有價值的需求。
  • 專注-重複:這種類似的專案最著名的例子就是遊戲開發專案執行到「production phase(量產階段)」。取名為Production Line Kanban,就是說這種專案開發需要專注的時間,但是處理的問題屬於比較重複性的工作。用生產線作為比方,生產線上的操作員,相對來說不太較需要創新與動太多腦筋。關於遊戲開發專案的不同開發階段,請參考《Scrum框架下的跨界開發(3):遊戲開發的四個階段》這一篇。
  • 中斷-創新:這種類型的專案,可以混用Scrum與Kanban。例子包括《遊戲團隊結合Agile與Kanban的經驗》這一篇所提到的做法,用Iteration Team(Scrum Team)來應付專注與創新的工作,用Kanban Team來處理「中斷、事件驅動、多樣化」的工作。《系統管理團隊結合Kanban與Scrum的經驗》則是提到另一種混用Scrum與Kanban的做法,這種作法為了應付大量「中斷、事件驅動、多樣化」的工作而拿掉了iteration,改用Kanban,但維持了許多Scrum所建議的會議以及Product Owner和ScrumMaster角色。
  • 中斷-重複:這種類型的專案稱作Support Kanban,顧名思義就是適合用在扮演支援角色的專案。例如,客服中心的運作,或是公司內部的資訊系統,上線之後都需要一個團隊來維持系統正常運作。這種支援型的專案,工作被中斷的比例更高,工作內容的重複性也比較高。
  • 中間點:Michael Sahota把標準Kanban畫在中間這一個區域,也就是說專注、中斷、重複、創新這四個面向,都牽涉到一點點的這種專案,可以使用Kanban。這個,有點不好解釋,廣義的來說,就是什麼專案都可以用Kanban挑眉質疑

***

Lean Startup適合哪一種

最後一個問題,Lean Startup適合哪一種開發方式?會問這個問題,因為Teddy有個朋友原本正在嘗試導入Scrum,試了1、2個sprint之後,可能是讀了《Kanban and Scrum - making the most of both》與《The Lean Startup》這兩本書,朋友後來覺得拿掉iteration的Kanban比Scrum更適合Lean Startup。不過,後來Teddy私底下問他:「你們真的改用Kanban嗎?」得到的回應是:「沒有,其實是混用Scrum與Kanban的一些作法」。

如果從「重複 VS. 創新」與「專注 VS. 中斷」來做為選擇開發方式的依據,就比較容易理解朋友的處境與選擇依據。畢竟Lean Startup,或是廣義的來說,Startup(新創公司),所面臨的問題或是工作並非全部都動態到非得把iteration拿掉才行。就算是把iteration拿掉,許多Kanban團隊其實也混用了很多敏捷實務作法,不僅僅只是標準Kanban所要求的「視覺化工作流程」、「限制WIP」、與「測量及最佳化Lead Time」這三點而已。

***

友藏內心獨白:弄清楚context並且練好基本功是很重要的。

2013年8月27日 星期二

遊戲團隊結合Agile與Kanban的經驗

August 26 21:34~23:00

螢幕快照 2013-08-26 下午11.17.20

 

前一陣子讀了一堆有關精實開發、Kanban、Scrumban、Scrum+Kanban的書籍、網路文章和論文,幾天前介紹了《系統管理團隊結合Kanban與Scrum的經驗》,不知道鄉民們讀了之後有何感覺?Teddy自己是覺得蠻有趣的,今天繼續介紹另外一篇發表於2011 Agile Conference的論文:《Agile & Kanban In Coordination》。

這篇論文描述了一個18人遊戲團隊導入敏捷開發的經驗。這個團隊,和很多開發團隊一樣,同時肩負著「開發新功能」與「修改小功能及解bug」這兩種不同類型的工作。他們導入Agile與Kanban的過程,可以分成三個階段:

  1. 敏捷階段(10/1/2009~1/1/2010):作者在文章中並沒有說他們使用的是Scrum方法,但是根據Teddy的理解基本上作者所使用的敏捷方法是參考Scrum而修正的一種方法。這個階段主要的做法有:
    • 將18人分成三個團隊開發同一個產品,團隊人數分別為5人、6人、7人。
    • 估算task
    • 採用iteration
    • 有統計velocity
    • 有PO也有建立product backlog
  2. 敏捷團隊組建(1/1/2010~6/1/2010):在第一階段的嘗試中,作者提到PO經常遇到「不知怎麼把工作分給哪一個團隊比較合適」的這個問題。經過一番嘗試之後,最後他們決定既然三個團隊都共同開發一個產品,那麼乾脆就合併成一個團隊算了,引此導致了第二階段:
    • 將三個團隊合併成一個18人的敏捷團隊。
    • 非正式的組成一個Product Owner團隊。
    • 開始團隊的story planning會議。
    • 使用Scrum的User Story與Task。
  3. Kanban與敏捷團隊組建(6/1/2010~4/1/2011):第二階段的作法,明眼人一看就知道存在團隊人數太多的問題。Scrum建議一個團隊人數最好介於5~9人,18人的團隊真的是太大了。作者在文章中提到,有3~5個人表現得不好,經常無法完成他們所認領的工作,但這些問題卻因為人數太多而被隱藏起來。人數過多也會導致「自我管理」變得十分困難。最後,第三階段的嘗試:
    • 把團隊分成9人的Iteration Team與6人的Kanban Team。
    • Iteration Team負責較大的需求開發,Kanban Team負責小型且較明確的工作。
    • 正式組成一個Product Owner團隊。

***

敏捷與精實

下圖節錄自論文中的內容,作者提到他們的敏捷團隊與Kanban團隊所採用的敏捷與精實作法。基本上Kanban團隊沿用敏捷團隊的大部分做法,只是把固定開發周期與burndown chart拿掉。另外,用Kanban board來取代Story Board。

螢幕快照 2013-08-26 下午10.58.58

 

最後,用一張論文中非常有意思的圖來做為總結。Teddy在剛開始的時候有提到,作者的團隊和很多開發團隊一樣,同時肩負著「開發新功能」與「修改小功能及解bug」這兩種不同類型的工作。最後他們將團隊分成Iteration Team與Kanban Team,剛好用來對付大型工作(開發新功能)與小型工作(修改小功能與解bug)。

螢幕快照 2013-08-26 下午11.03.06

***

結論就是,除了「混在一起做撒尿牛丸」這種選項以外,還可以做成「撒尿蝦與牛丸雙拼挑眉質疑

***

友藏內心獨白:難道做軟體的人也要去學做菜的方法嗎!

2013年8月26日 星期一

我應該也算是自由工作者…吧!

August 25 18:27~20:06

image

 

前幾天讀了「良葛格」在iThome 621期上面一篇名為《自由工作者之自由:自由的代價與實質意義》的文章,心有戚戚焉。讀完這篇文章之後才知道良葛格從2003年起已經連續十年未曾有過正職的經驗,算是自由工作者的前輩。文中「保留時間醞釀更多選擇」這一個段落的內容,Teddy讀來特別有同感。

想起2012年7月剛成立泰迪軟體的時候,剛開始也是因為生活的壓力,心裡急著想要尋找更多的收入來源。但一開始每隔2~3月才有一門公開課程,而企業內訓及導入的案子都還在耕耘當中。當時每個月的平均收入只剩下之前工作的1/3左右,但是自己的時間比較充裕,有心力可以規劃一些新的課程與嘗試一些新的創造收入方法。例如,在平日夜間舉辦短期(2~3小時)的講座型課程活動,或是自己主動聯繫潛在的客戶,用非常優惠的價格協助導入Scrum與敏捷開發。

到了2013年上半年,也不知走了什麼好狗運,突然蹦出好幾個企業內訓和企業導入案,加上幾個「Scrum」、Design Patterns」、「軟體測試與持續整合」等公開課程都陸續招收到足夠的學員而成功開課,收入變得比較穩定一些,但也搞到自己幾乎沒有喘氣的時間。唯一剩下一點點空檔的時間,拿來寫完部落格之後,所剩無幾。有時候甚至經常需要動用到自己晚上的休息時間,才勉強維持每天發表一篇部落格文章的承諾。此種現象,正如良葛格在文章中所寫的:「…最後迫使自己雖然形式上是自由工作者,但實質上更不自由」。

寫到這邊Teddy想到在《顧問成功的秘密》這本書中提到,顧問只有「工作閒與工作忙」這兩個狀態,而在工作忙的時候更應該花時間來經營新的客群,否則等到工作閒的時候再來經營往往會緩不濟急。因此書中建議顧問應該要「每週至少花一天時間在公開露面這件事上」(請參考《顧問成功的秘密:每週至少公開露面一天》)。要如何利用時間以便平衡「眼前收入」與「未來發展」這兩股經常是互相衝突的力量(force),的確是自由工作者需要面對的難題

***

自由的實質意義

文末良葛格提到「自由的實質意義」在於:「能夠在時間、工作、經濟等經營出更多選項」,這一點Teddy也非常認同。與上班族相比,自由工作者在時間、工作選擇與收入來源各方面所擁有選項的確是比較多。除此之外,Teddy到目前為止短短一年八個月的自由工作者菜鳥經驗,覺得還有一件很重要的意義,就是「可以實現把興趣當作飯吃」這件事。

導入Scrum與敏捷開發實務做法、學習Alexander的pattern與pattern language理論、軟體測試與持續整合、軟體設計、例外處理等等,都是Teddy的興趣。雖然以前工作的時候也是靠這些「興趣」吃飯,但是畢竟主要的工作是開發某個軟體系統,而這些「興趣」只是支援這個開發過程的背景知識與能力。自己創業之後(小公司應該也算是自由工作者吧),慢慢發現原來這些「興趣」是可以轉換成新台幣,這算是一種從市場所得到最直接的回饋。這種感覺,真的很爽熱戀

有看過Teddy的 大作 拙作《笑談軟體工程:敏捷開發法的逆襲》這本書的鄉民們,可能會知道Teddy心中一個小小的心願,就是希望能夠「改變人們在台灣開發軟體的方式」。這個 妄想 心願,當年身為一個上班族的Teddy,是不可能有機會可以實現。雖然成立泰迪軟體之後,Teddy對於公司也沒甚麼偉大的遠景,只希望能活下來不要倒店就好。但是這個「改變人們在台灣開發軟體的方式」的希望,隨著上過Teddy課程、企業導入案與觀看部落格鄉民人數的增加,Teddy真的有感受到「改變」的發生。雖然和整個台灣從事軟體開發的人數相比,這個數目現在還是很小,但套句敏捷開發的講法,真的有在「逐步成長」。Teddy知道要改變所有的人這是不可能的事情,但是能影響一個算一個,除了讓自己可以依靠興趣繼續在社會上存活下去以外,如果真的能對鄉民們在工作上、生活上有所幫助,也算是功德一件。

「自由的實質意義」是什麼?Teddy現在覺得,人生走這一遭,在自己的有生之年可以做一些不一樣的嘗試,這個嘗試未必是最好的、最成功的、最有名的、最賺錢的,但是絕對是獨一無二的、有趣的、有意義的、值得記憶的還有不添加人工香料與防腐劑的

***

友藏內心獨白:自由=修行=做功德挑眉質疑

2013年8月25日 星期日

2013金門考察之旅Day2-G山后

August 20 17:05~18:00

離開獅山砲陣地之後來到山后參觀整修後的閩南式老宅,入口處寫著「金門民俗文化村」。

螢幕快照 2013-08-20 下午5.30.01

 

兩落老宅中間的小巷子,剛好可以看到非常漂亮的燕尾。

螢幕快照 2013-08-20 下午5.17.19

 

山后的閩南式建築群,除了有經營民宿之外,還有賣吃的,終於找到一家有賣咖啡的店了。

螢幕快照 2013-08-20 下午5.17.32

 

方亭咖啡…方亭不是悲慘世界裡面女主角的名字嗎不要告訴別人

螢幕快照 2013-08-20 下午5.18.14

 

點了一杯拿鐵,味道還不錯。

螢幕快照 2013-08-20 下午5.18.39

 

這家方亭咖啡同時也經營民宿,到裡面參觀一下,看到一隻貓。

螢幕快照 2013-08-20 下午5.18.57

 

睡得還挺熟的。

螢幕快照 2013-08-20 下午5.19.07

 

店內居然還有供奉關老爺。

螢幕快照 2013-08-20 下午5.22.02

 

繼續參觀其他建築,這裡的閩南建築群整修的很不錯。

螢幕快照 2013-08-20 下午5.25.24

螢幕快照 2013-08-20 下午5.26.01

螢幕快照 2013-08-20 下午5.26.18

螢幕快照 2013-08-20 下午5.26.25

螢幕快照 2013-08-20 下午5.26.32

螢幕快照 2013-08-20 下午5.26.53

螢幕快照 2013-08-20 下午5.27.18

螢幕快照 2013-08-20 下午5.27.34

 

有一棟建築當作展示館,可免費入內參觀。

螢幕快照 2013-08-20 下午5.28.16

螢幕快照 2013-08-20 下午5.27.41

 

哇,新娘房耶。

螢幕快照 2013-08-20 下午5.27.53

 

可惜沒有新娘挑眉質疑

螢幕快照 2013-08-20 下午5.28.00

 

已經很少見的灶,Teddy小時候的時候還用過不要告訴別人

螢幕快照 2013-08-20 下午5.28.22

 

燒熱水的澡盆。

螢幕快照 2013-08-20 下午5.28.40

 

山后建築的模型。

螢幕快照 2013-08-20 下午5.29.01

 

鯉魚形狀的排水口。

螢幕快照 2013-08-20 下午5.28.49

 

 

螢幕快照 2013-08-20 下午5.29.33

***

第二天白天的行程到此告一段落。

***

友藏內心獨白:晚上還要參加導覽啊。