2010冬遊日本關西Day3-B春日大社及其他

March 03 08:36~10:10

春日大社附近有很多石燈籠，如果晚上有點燈的話，應該會很美。

 

石燈籠也被鹿男入侵了。

 

在日本熱門古蹟景點隨時都會看到穿制服的學生。

 

春日大社…忘了這算不算是大門入口…XD。

 

春日大社內部，等了一會才等到沒人拍下這兩張照片。

 

落葉太多，掃起來應該滿累的。此時腦海中突然湧起兩句話：

• Programming is gardening, not engineering.
• All programming is maintenance programming.

寫了這麼多篇的遊記，終於有一點和軟工扯上關係了…XD。

 

這一隻是石頭做的鹿。

 

亂拍的全景圖。

 

這是某人的「內心獨白」嗎。

 

由於Teddy 行進方向是由山上往山下走，所以在離開春日大社時才看到放在入口標誌著世界文化遺產的大石頭。

 

在春日大社附近有一個萬葉植物園，但是因為要門票所以過門而不入…Orz。其實是走得有點累了，想休息一下。

 

來到山下（奈良公園）看到一攤賣地瓜的，買一個吧。

 

小小一個，熱熱的味道還不錯。忘了多少錢，好像三，四百日幣吧。這應該是Teddy買過最貴的地瓜。

 

剛好看到一輛公車經過。

 

有一隻鹿想要來偷吃地瓜。去去野鹿走，這麼貴的地瓜當然是Teddy留下來自己吃啊。印象中好像除了在當地購買的鹿仙貝以外，是不能餵食其他食物給鹿吃的。據說是為了 賺錢 鹿的健康。

野鹿內心獨白：再不給我吃我要報警了喔。

 

從奈良公園過個馬路就到了往前直走幾分鐘便可到達春日大社的…能夠說是「登山口」嗎？會看到一個橘色大鳥居。

 

吃完地瓜之後不知不覺地走到另外一個景點「東金堂」。

 

沒買票入內參觀，所以看看建築物外觀就好了。

 

旁邊有一個小湖，可以坐在湖邊休息片刻。

 

離湖邊不遠處有幾家古色古香的商店。

 

剛剛看照片的時候發現一個靈異現象，怎麼突然就變成晚上了。上一張照片拍攝時間大該是下午三點，下一張是下午六點。耶，這中間的三個小時跑去那裡啦？真相只有一個，就是…Teddy忘了…Orz。印象中好像跑去什麼地方喝咖啡可是都沒拍照。結論：凡拍過，才會留下痕跡。

 

在住宿地點附近找一家看起來還可以又不會太貴的店吃晚餐。

 

 

 

 

 

入夜之後到JR奈良站附近逛了一下。今天走了一整天，早點睡覺吧，明天還要走另外一個一整天。

 

***

友藏內心獨白：有看過日本的鹿男連續劇再去奈良會更有感覺喔。

2010冬遊日本關西Day3-A東大寺(下)

March 01 13:45~14:30

離開主殿之後，繼續往二月堂與法華堂方向前進。

 

 

落葉鋪滿草地…當場看真的很美。

 

 

一路上山林裏面都是野鹿。

 

到了。

 

其實Teddy已經搞不清楚那一間是二月堂，那一間法華堂，反正就加減看吧。

 

這是走到哪了…?

 

一路上看到滿多漂亮的楓紅。

 

中午十二點出頭，差不多該吃飯了。附近剛好有吃的。

 

沒想到還滿好吃的。

 

尤其是下圖中的甜點，真是太好吃了啦。

 

價錢也不算貴。

 

又看到一隻在吃紙的鹿…Orz。

 

吃完飯之後繼續下一個行程，往春日大社出發。走著走著怎麼看到下圖。

 

原來走到了「若草山」耶，不過今天只是路過，改天才會來爬山。

 

當時落草山在施工，不過還是可以上去。

 

看來應該是快到了。不過，千萬別小看這段階梯，請注意看照片階梯最下方，放大之後可以看到三隻鹿。沒錯，這三隻鹿早就算好，在這條要道上等在那裡準備跟遊客要吃的…XD。三隻鹿並排氣勢很驚人，真是太聰明了，很有團隊精神。

 

就是這三隻，還排出三角隊形，有練過喔。

 

看到一棟很特殊的建築物。

 

春日大社剩200公尺就到了。

 

到了，下回繼續。

 

***

友藏內心獨白：奈良的景點還滿集中的。

站著開會效率就會好…嗎？

March 01 21:43~22:50

 

今年二月初有一則新聞報導，標題是「科技業追效率-站著開會成風潮」。該報導中有一段話：「隨著敏捷法獲得愈來愈多公司採納，站著開會也隨之普及。去年對世界各地六千零四十二名科技員工進行的調查發現，有百分之七十八的人參加每天站著舉行的會議。」

哇，78% 的科技員工參加daily stand-up meeting耶。這個數字在台灣可能也是78，不過是千分之78。耶，還是萬分之78啊…Orz。

平平是「科技員工」，怎麼台灣和國外的比例差那麼多。鄉民們如果有實施daily stand-up meeting的可以留個言分享一下實施的狀況嗎？

***

Teddy想講的是，誰說光是站著開會效率就會好？小學跟國中的朝會都是站著開會啊，台上的人自己很hi，但發言內容通常都是又臭又長的雞毛蒜皮小事，甚麼腳踏車不要亂停之類的，有那一句話是被學生聽進去的。另外，當兵時的早晚點名也是站著開會啊，什麼...剛剛值星班長在講什麼我恍神沒聽到啦...XD。

就算是daily stand-up meeting，「開會達人」還是可以把會議搞得很冗長。

就算是daily stand-up meeting，還是有人會坐著開會（行動不便人士除外）。

就算是daily stand-up meeting，還是有人可以東南西北的打開話匣子聊天。

不是說「站著開會效率就會好」，躺著開會效率就不好。Daily stand-up meeting依照Scrum的建議，有2+1件事請務必做到，否則成效可能會大打折扣。

1. Same time
2. Same place
3. Time boxing

Daily stand-up meeting無論如何一定要在固定的時間（例如早上9:30或是下午5:00）舉辦，千萬不可以每天舉辦的時間不固定。另外，就是要在固定的地點舉辦，開會地點不要每天換來換去的。以Scrum為例，開會地點就選在實體的task board前面，邊看著task board邊報告「那三件事」。

最後一件事就是會議「基本上」要在15分鐘之內結束，如果有什麼延伸的議題需要討論也是在會後把相關人等留下來討論，而不是讓daily stand-up meeting無限期的延長下去。

再次強調，對於daily stand-up meeting而言，前兩點要求是非常重要的。如果團隊daily stand-up meeting搞得好像逐水草而居的遊牧民族，跑來跑去居無定所，那就不太妙了。

***

友藏內心獨白：知易行難啊。

戴上腳鐐去賽跑

March 01 10:35~11:58

 

有一陣子Teddy很熱衷於issue tracking system，把每一個sprint中團隊所找到的bugs或是issues都打到issue tracking system中，並且詳細敘述產生bugs的步驟與發生問題的畫面，以便於開發人員日後要修改bugs時有所依據。實施了一陣子之後Teddy覺得有點不對勁，那裡不對勁？

• 有時候要很詳細地把一個bug打入issue tracking system中可能要花15-30分鐘，但是搞不好修這個bug還不用10分鐘，到底是要把這個bug打到系統中還是直接找人修掉比較合適呢？
• 當issue tracking system裡面有5個bugs的時候，開發團隊可能會有一種想要趕快把這些bugs修完的動力。但是，如果issue tracking system裡面有50個，甚至是500個bugs呢，還有人會去關心這些bugs嗎？

後來Teddy忘了是看了那本書還是那篇文章，提到「一個好的敏捷團隊根本不需要使用issue tracking system」這樣的「邪說」。什麼，軟工的書不是都有介紹開發軟體應該要使用issue tracking system的嗎，為什麼有人會建議敏捷團隊不需要使用issue tracking system？

這當然又牽涉到「叔叔有練過，小朋友不要學」的這句老話。那篇文章的作者認為，一個好的敏捷團隊會有很低的bug rate（或是應該要朝向這個目標邁進），一旦在sprint當中發現任何bug就立刻改掉，所以根本不需要用一個「系統」來追蹤這些bugs。況且一旦使用了issue tracking system之後，團隊會有一種「找到問題只要把它打入系統就沒事了，反正以後有時間再慢慢處理就好了」的心態。至於這個「以後」是什麼時候，大概是未來從來不會發生的某個時間點吧。所以搞到最後的結果就是bugs/issues越積越多，變成一座垃圾山…XD。

Teddy讀了這篇文章之後也覺得滿有道理的，在Scrum的框架中，已經有Daily Scrum讓開發人員回報問題，還有平常開發軟體的活動中只要一發現bugs就要想辦法立即處理。Sprint Demo和Retrpspective Meeting也都可以討論bugs或是issues。所以回歸到敏捷宣言的第一條：

Individuals and interactions over processes and tools

不久之後Teddy就把原本幫團隊導入的issue tracking system給廢棄不用了。

***

看到這邊鄉民們一定會問，那不用issue tracking system發現了bugs或是暫時無法處裡的issues該怎麼辦？很簡單：

• 在每個sprint開發過程中，只要有人發現bug，就要想辦法在這個sprint把發現的bug解掉。
• 如果發現的bug或是issue牽涉因素太廣，修復時間太長，則把這個bug打到product backlog中，排定優先順序，留待之後的sprint來修復。如果這是一個很嚴重的bug/issue，通常下個sprint就會被挑進來施工，所以也不會在product backlog中停留太久。如果真的在product backlog中停留太久，那麼就代表這的bug/issue不是那麼重要或是不太急迫，所以也可以放心地繼續擺在product backlog中（當然還有一個可能就是Product Owner太混，這邊就不討論了…XD）。

自從拿掉了issue tracking system之後，Teddy覺得團隊的開發反而變得更順暢。一旦有人發現任何bug，就會馬上用MSN或是Skype通知所有專案中的開發人員，並徵求大家去「認養 認領」這個bug。在大部分的情況，這種模式運作得很好，而且發現的bugs也都被妥善地處裡。

***

所謂盡信書不如無書，雖然軟工的書告訴大家要使用issue tracking system，但是並沒有說明一個敏捷團隊應該如何使用或是看待issue tracking system。Teddy自己也是費了一番功夫才找到一個自己認為合適的方法。如果當初Teddy還「傻傻地執迷不悟」繼續把所有發現的bugs都打到issue tracking system，那麼Teddy勢必要把自己「寶貴的時間…XD」拿來做一些CP值不是很高的事情（輸入詳細的bugs發生步驟與擷取畫面），反而沒有時間把心思花在如何改善開發流程上面。這種感覺就好像先把自己腿上綁上腳鐐再去跟人家賽跑一樣。要跑贏，很難。

看到這邊鄉民們不要以為Teddy完全反對使用issue tracking system，這樣的系統還是有存在的必要。像是公司裡面QA部門測試鄉民們所開發的軟體時，就必須要把發現的問題詳細的打到issue tracking system，這樣子開發團隊才知道有那些問題需要處裡。前面Teddy所說不需要使用issue tracking system是指在同一個Scrum團隊中，而不是指跨部門的合作，這一點不要搞錯了，否則絕世武功練一練不小心又要走火入魔了。

***

友藏內心獨白：遇到問題時，應該思考這個問題是不是真的是一個問題。