Oct. 30 21:40~22:05
最近Teddy因為工作的關係比較常到南港軟體園區。從南港展覽館走到南港軟體園區，需要過一個馬路。Teddy猜想每天等著過這個馬路的行人，應該有幾千人次吧。假設保守估計有3000人次，每次平均等待紅綠燈的時間是30秒，一天就浪費了3000*30=90000秒=1500分鐘=25小時。一年算280個工作天，就浪費了7000小時。
每次在這裡等著過馬路的時候，Teddy就在想：「為什麼捷運站不在南軟設一個出口，這樣不是可以減少很多等待的時間浪費嗎？」
***
「誰適合當ScrumMaster？」這個問題Teddy被問過沒有上百次也有幾十次。這個問題真的不好回答，因為公司文化、團隊組成、專案特性、個人特質、個性、意願、專業能力、經歷、人脈關係等，都會影響挑選ScrumMaster的因素。有時候對的人，放到不對的場合，也是白搭。
先不管其他條件，如果鄉民們經過上面這張照片所在的路口，也跟Teddy有類似的疑問，這種人就初步具備當ScrumMaster的條件，尋找持續改善的機會
***
友藏內心獨白：最好是那麼簡單。
Oct. 29 20:33~21:08
昨天提到〈PO決定優先權〉，今天談一下團隊決定需要多久的時間來完成story。在某次【Scrum敏捷方法實作班】中，有一位學員問Teddy…
學員：PO（Product Owner）是不是可以不用參加sprint planning meeting part 2？
Teddy：對啊。
學員：可是如果採用你的建議，用task累積的時間來估算團隊在這個sprint可以挑選多少story，那麼PO就被迫參加sprint planning part 2啊。
Teddy：啊？為什麼呢？如果PO有事不參加sprint planning part 2，他在part 1解釋完需求的內容之後就可以離開了。只要團隊在切割task的時候有問題可以找到PO就可以了。
學員：可是這個sprint可以做多少story要等到sprint planning part 2才知道啊。
Teddy：如果採用「團隊可用總時數減去task累積預估工時」的方法來估算，的確是要等到sprint planning part 2之後才知道這個sprint可完成story的數量。
學員：這就是問題啊，我們的PO想知道這個sprint完成多少story。
Teddy：那就在sprint planning part 2之後通知他不就好了。
學員：可是PO會有意見啊。
Teddy：有意見？你的意思是說PO對於團隊每個sprint完成story的數量有意見？
學員：對啊，如果PO覺得團隊預估可完成的story數量太少，他會「強烈建議」團隊在多選幾個story。
Teddy：這樣啊…那我猜測你們團隊一定很討厭Scrum。
學員：你怎麼知道？！
***
在Scrum框架下，PO決定需求的優先順序，團隊決定工作所需的時間。在〈PO決定優先權〉提到團隊不應該自行幫PO決定優先順序，同樣地PO也不能幫團隊決定施工所需的時間，否則就跟現行一般專案管理方式類似，由專案經理指定每項工作所需完成的時間，團隊成員只能聽命行事。如此一來，只是披上Scrum的皮，行傳統專案管理之實。相信應該沒有團隊會喜歡這種形式的「Scrum」吧！
***
友藏內心獨白：權責相符是很重要的。
Oct. 28 07:24~08:15
有一個朋友問Teddy關於Scrum的問題…
朋友：在sprint進行中，如果遇到bug該怎麼辦？
Teddy：如果這個bug是因為這個sprint的開發活動所導致的結果，當然就直接解掉。如果是之前sprint所遺留下來的，而且不修正會妨礙到團隊完成這個sprint所安排的story，則還是要修掉。又或者是這個bug很小，也可以隨手修掉。但如果這是之前sprint所遺留的bug，而且需要花費一段時間才能處理好，我會建議把這個bug放入product backlog裡面，讓PO（Product Owner）來安排修bug的時間。
朋友：可是團隊（開發人員）不是要負責產品的品質嗎？遇到bug不修卻丟回product backlog裡面讓PO來決定何時修bug，這不是把品質的責任交給PO來負責？
Teddy：團隊的確是要負責產品的品質，但是如果在sprint進行中發現之前開發活動所遺留下來的的bug，這種修bug的要求（request）稱為失效要求（failure demand）。失效要求也會耗費團隊的開發時間，如果團隊成員自行決定要處理失效要求，則原本PO所排定的story優先順序就被打亂了。很可能PO認為修正這個bug的優先權很低，可以暫時不理它，但團隊卻急著修它而忽略原本排定的story。換句話說，團隊幫PO決定了優先順序。
***
友藏內心獨白：不要越俎代庖。
Oct. 27 07:59~09:00
上禮拜上完【設計模式這樣學就會了：入門實作班】，每次上課的時候，Teddy都會了解一下學員想在這門課中學到什麼，一個經常聽到的期待就是：「如何辨別一個設計是否採用GoF的某個design patterns？」
這個問題可能有很多種方法，比較抽象一點的說法是「從pattern要解決的問題來判斷」，另外一種說法則是從辨識pattern的特徵開始。例如：
***
在不同的班次中，經常會有學員問Teddy：「某某設計算不算是Facade？」Teddy通常會反問：「如果這個設計是一個Facade，請問它擋在哪個子系統的大門前？」如果找不到任何被這個設計所隱藏的子系統，應該就不能算是一個Facade。如果可以找到，則進一步問：「Facade定義了那些介面？」鄉民們可以自行練習看看，對於判斷某個設計是否套用某個pattern應該會有幫助。
***
友藏內心獨白：問對問題很重要。
Oct. 01 09:43~10:50
Teddy寫了〈不是我不教，是你不肯學〉之後，有鄉民向Teddy抱怨…
鄉民：我看是因為你聽到別人沒有意願參加你的課程，你就不想回答對方問題吧。
對於求知與學習Teddy有三點看法：
***
別人的頻率和你不一樣是誰的錯？沒什麼對錯，就是「頻率不同」這個事實。別人不一定比較厲害，你也不一定比較差，但「頻率不同」就是搭不上話，硬要在這種情況下問出個所以然來，如果別人選擇不繼續回應就戴上個「不想上你的課或沒有買你的書所以你就不願意回答」這頂帽子，那未免太小看別人了。
平常Teddy上課是不准學員使用筆電與手機等3C產品，就是希望學員能夠專心，活在當下。有一次Teddy在上課的時候，有一位學員三不五時用手機跟朋友傳訊息。Teddy提醒了他，但這位學員還是不改，後來Teddy告訴他：「你如果再玩手機，我就要請你離開，課程費用我全額退費給你。」不是所有的事情都可以用錢解決，你來上課繳了錢沒錯，但別人也繳了錢，你的行為影響了別人或講師，這就不對。這種錢，Teddy不賺也罷。
還有一次有一位上過Scrum課程的學員在C. C. Agile問了Teddy一個例外處理的問題，這個問題有一個簡單但不完整的答案，也有一個完整但需要花一段時間解釋的答案。Teddy不想只是為了打發對方而提供簡單但不完整的答案，也沒辦法在C. C. Agile場合把完整的答案講完，只好請對方去看Teddy寫的書，因為整個思考過程Teddy在書中交代得非常清楚。如果事後提問者要解讀成「因為沒有來上例外處理課程所以Teddy就不想回答」那也沒辦法。你不可能討好所有的人，正所謂「物以類聚」，和你頻率相同的人自然會留下來甚至日後成為好朋友。頻率不同的人自然會去尋找符合他自己頻率的地方，此為正常現象，請安心服用。
上個月有一位報名上課的學員在開課前2~3天來信告知臨時有事無法參加。這位學員也很乾脆地告訴Teddy說他不要求退費，只要把發票寄給他就可以了。看到信之後Teddy非常感動，但就算對方不要求退費，Teddy還是把課程費用一毛不扣的全部退還。開課賺錢只是讓泰迪軟體可以持續經營下去的一種手段，除此之外也希望學員們可以透過Teddy為媒介，感受與了解軟體開發活動的各種樂趣。如果只是為了賺錢，還有其他比經營泰迪軟體更輕鬆且安穩的賺錢的方法。
***
這種事，講多了好像在幫自己宣傳。不說，遇到頻率不對的人，心裡又覺得很悶。怪就怪Teddy修養不夠，還沒到達「本來無一物，何處惹塵埃」的五蘊皆空境界。讓鄉民見笑了，繼續修練去。
***
友藏內心獨白：調整頻率之前可能要先檢查天線有沒有壞掉。
Oct. 24 22:37~23:05
沿著鴨川繼續騎，來到了上賀茂神社，一映入眼簾的是一株盛開的齊王櫻，很多遊客以它為背景拍照。
繼續往前走，當天剛好有人在此舉行婚禮。
繼續賞花、賞屋、賞流水。
離開前買了一份如下圖右方的糯米零食，買的人還不少，不過吃起來覺得還好，沒有特別好吃。
***
友藏內心獨白：看不完的櫻花。
Sep. 18 21:45~22:35
今天要騎自行車到上賀茂與下鴨神社逛逛，早上先搭公車到高野川和賀茂川合流附近租借自行車。一台車租一天只要500日圓，應該算很便宜。但是，自行車是中國製造的便宜車種，車子不太好騎，還是台北的UBike完勝。
借到車之後先騎到河邊，順著河岸逆流而上。先騎到一個叫做松崎疏水的地方，沿路很多地方都有櫻花，非常漂亮。
繼續往前騎，來到京都植物園附近的鴨川，看到一顆石頭寫著半木之道。今天這裡有市集，有許多賣吃的攤販，人潮眾多。這裡種了很多櫻花，正是盛開之時，難怪會選在這裡擺攤。
買了點吃的，因為半木之道人太多了，繼續往前騎了一小段，找了個有椅子且人少一點又可以賞櫻的地方休息一下順便吃東西。附近剛好有一群年輕男女正在聯誼的樣子，還有媽媽帶小朋友出來野餐。
***
友藏內心獨白：沒想到鴨川沿岸櫻花如此之多。
