麥甲我蓋布袋, Part 5

August 23 21:52~23:00

 

前幾天無緣無故收到某「刊物」寄過來的一封信，讀完信件內容之後有點小傻眼 。以下為經過「處理過後」的信件內容：

***

Dear All,

你好，我是XXX刊物編輯路人甲。

我想邀請您參加XXX刊物第N期的主題報導，幫忙我們推薦幾本軟體類的好書。

這次推薦好書的動機，是因為我們發現許多軟體從業人員，譬如程式設計師都只會coding，感覺自己能做的事情被侷限住。

所以，希望透過各位前輩，針對技術、管理，或是自訂類別，幫我們多推薦幾本好書（數量不限），讓讀者能夠透過這些推薦書，幫助他們不論在技術或管理面更上一層樓，成為搶手的人才。

在推薦字數方面，希望最少能有100字。

若願意參加，煩請提供以下資料給我，並於收到email之後的隔天下班時間前回覆給我。

1. 個人簡歷
2. 推薦理由
3. 書名
4. 出版社

我們會贈閱當期刊物給您，煩請提供收件地址。

***

各位鄉民們，請暫時切換到「柯南模式」，看看上面這封email有沒有什麼問題？

 

看到沒？什麼，觀察力這麼不敏銳，將來怎麼做大官…XD。沒事，宣布答案，問題就出在Dear All。

鄉民們：什麼？這樣寫有什麼問題？

Teddy：這樣寫的意思，代表發信者將同一封信一次發給很多人。這原本也不算是個問題，但是，今天發信者名義上是要「邀請」收信者（Teddy就是其中之一）來寫推薦書單與理由。如果是邀請，應該不可以這麼便宜行事，把所有的收件者放在「密件副本」然後開頭用一句Dear All帶過。而是應該要把每位受邀者個名字列出，然後單獨一封、一封信去邀請每一位受邀者。信件的內容絕對可以一模一樣，但是用Dear All感覺就不對勁。

還有第二個問題，就是發信者居然要求收到信之後的隔天下班前就要把資料寄回給他，這也太強勢了一點吧。他以為受邀者都很閒嗎 。

什麼，你問Teddy有沒有回覆對方。這還用問嗎，如果有就不會寫這一篇啦。

***

友藏內心獨白：這次有打馬賽克，應該不會被蓋布袋吧…。

Scrum FAQ (4)

August 22 21:00~22:40

今天繼續昨天的議題，回答上禮拜上Scrum第三梯次課程由學員們所提出來的問題。

問題六：Scrum Master和Product Owner可以是同一個人嗎？

Teddy：「理論上不行」，因為這兩者的責任在許多地方是互相衝突的。PO通常會希望團隊在每一個sprint當中，完成越多的story越好。PO基本上不管團隊用什麼方式開發軟體，反正在單位時間之內能夠完成越多的功能就越好。Scrum Master則需要觀照全局，必須協助團隊持續改善開發流程與技術能力。而這些改善的工作，很有可能是短時間看不到立即的功效，因此PO不一定會願意將這些改善的需求排入優先的施工對象。

當Scrum Master和PO變成同一人時，如果Scrum Master是技術人員背景，那麼很可能發生「重改善而輕功能」的問題，把很多時間花在為改善而改善上面。反之，如果Scrum Master是非技術人員出身，則可能會排斥所有的改善工作，把全部的時間都拿來開發功能，而導致「重功能而輕改善」。

結論就是，「逆練 英九 九陰真經」，要自己小心一點，注意不要走火入魔了。

問題七：Bug fix 的story要如何估算點數？

Teddy：這個問題很好，簡單地說，就是「用猜的」。基本上，bug可以分成三種：

1. 修改方法很明確的bug：這種bug最簡單，只要花時間就可以改好。例如，網頁打錯字、修改CSS、欄位檢查邏輯錯誤等。
2. 大致知道問題可能會出在哪裡的bug：從回報bug的敘述中，團隊「大致上」可以猜到bug發生的原因，但是對於要花多少時間才可改好比較沒有把握。
3. 完全沒有頭緒的bug：只知道在某種狀況下系統會發生錯誤，但是可能還沒辦法重複發生錯誤的步驟，也不是很清楚錯誤發生的原因，更不知道要如何排除錯誤。

Teddy通常會把好幾個bug集中在一個bug fix的story裡面去修復，而這些集中在一起修復的bug，最好是有80%左右是屬於上述第一種或是第二種bug，而20%左右是屬於第三種bug。然後，心理先預估一下，看看這些佔80%的bug（第一種與第二種）和其他story相比，大概需要多少story point。假設是5個story point好了。藉著再看看剩下的20%第三種的bug，如果整個bug fix的story point變成8，對於修復剩下第三種bug的信心如何？舉例而言，如果大家的信心只有30%，那就把story point再往上跳一級，變成13，此時如果大家的信心可以提高到70%~80%左右，那就差不多可以了，就用這個數字當作這個story的story point。看到這裡鄉民們可能會問，那為什麼不在往上跳一級，用20個story point？這樣信心指數可能會到95%啊？這也是一種方法，團隊可以依據大家投票的結果，取得一個大家認為可以接受的大小。重點是，決定之後就去做，做了之後再依據實際狀況，作為下次修正的參考。

問題八：內部討論API的文件，是否需要紀錄。

Teddy：類似的問題（敏捷方法是否需要寫文件）上一集回答過了。如果是Teddy，應該會直接把文件寫在API上面（寫在code裡面），而不會特意寫一份文件（例如Word文件），來敘述API的介面與使用方法。

問題九：Sprint planning meeting part 1在估算story point時，因為尚未切割task（尚不清楚施工項目），所以此階段所估算的story point是不是很不準？

Teddy：通常來講應該不會。在Part 1 雖然沒有切割task，但是團隊在討論與出牌過程中，其實在心裡面已經把如何完成這個story的方法「綜合演練」過一次了。如果大家的想法差異很大（所謂的很不準），那麼在出牌的時候自然會顯示這樣的差異，然後再引發另外一輪的討論，逐漸把這個差異給縮小。當然也可能會發生，在part 2切割task的時候，才想到剛剛有一些因素忘了考慮，而影響了story的估算。這也沒關係，就重估story的story point就好了。

問題十：團隊的工作是由Product Owner還是Scrum Master來分配？

Teddy：都不是，工作是團隊成員自己認領的。Scrum Master在「必要的時候」可以「提醒」團隊成員工作施工的順序是否有依據story的優先順序來施工。當團隊成員不知道要認領什麼工作來做的時候，Scrum Master也可以「建議」可能可以認領的工作。總之，工作絕對不是由Scrum Master或是PO指派的。

***

剛剛看新聞，明天照常上班、上課。要繼續去修訂這週末要上課的design pattern教材。

***

友藏內心獨白：颱風趕快走啦。

Scrum FAQ (3)

August 21 21:33~22:12

今天來回答幾個上禮拜上Scrum第三梯次課程時，由學員們所提出來的問題。

問題一：Scrum的活動都有著timeboxing的精神，但是如果spring planning meeting的時間用完了，但是工作還沒討論完，那該怎麼辦？

Teddy：很簡單啊，就直接開工了啊。假設Teddy是Scrum Master，遇到這樣的情況，會在會議結束前30-60分鐘提醒大家，快要沒時間了。就好像是已經誤點的

台鐵「自強號」一樣，此時大家就會開始加速，想辦法在剩下的時間之內把事情討論完。萬一真的還是有東西沒討論完，那就直接開工吧，也許在此次sprint中團隊會有一點小混亂，可是這樣下次大家才會學會把握時間，在有限的時間之內把最重要的議題給討論完畢。

問題二：敏捷團隊到底要不要寫文件啊？

Teddy：這一題簡單，你認為需要寫，寫了之後對客戶有幫助，哪你就寫。但是不要回到傳統那種想要用文件來代替直接溝通的作法。最高指導原則就是，能不寫，就不寫；可以晚寫，就晚一點寫 XD。

問題三：想要導入單元測試，需要找專人負責撰寫會比較好嗎？

Teddy：ㄟ，應該不會。單元測試基本上是由開發人員自己所寫的測試，所以應該是要想辦法讓開發人員知道也願意動手寫，而不是找其他專門的人來寫。

問題四：對於剛接觸Scrum的團隊，是否適合一開始就導入TDD？

Teddy：雖然TDD大部分在採用敏捷方法的團隊中比較常見，但TDD和有沒有採用Scrum應該是沒有特別的關係。你也可以採用waterfall流程，但是在開發時使用TDD，這應該也是OK的。是否採用TDD應是要看團隊中有沒有人覺得有需要（有人特別倡導），或是團隊或Scrum Master觀察到，如果採用TDD對於改善團隊的開發流程與設計能力有幫助。再回過頭來看，如果你的團隊才剛剛開始接觸Scrum，Teddy不太建議一開始導入太多agile practice，先花個3-6個sprint讓團隊成員熟悉Scrum之後再看看要從哪些方向來規畫改善目標。

問題五：每一個task一定都要用pair programming的方式來施工嗎？

Teddy：這一點也不一定耶，要看工作的性質，還有團隊的「氣氛」。Teddy個人是蠻推薦採用pair programming的，這是除了單元測試和持續整合以外，第三個Teddy會想要推廣的敏捷實務做法。

***

這幾天比較忙，要趕著整理這個週末「Design Patterns這樣學就會了：入門實作班」的上課講義和程式範例，今天先回答五個問題，剩下的留待下次 。

***

友藏內心獨白：有問題區這一招還真不錯，老早就應該拿出來用了啊。

Scrum團隊如何打考績：鬼扯篇

August 20 20:30~21:30

 

依據「官方說法」，Scrum看的是「團隊的績效」，而不是個人的績效。但是，這一點在台灣真的很難做到，因為大部份公司的考績制度，最終還是「以個人為主」。試想一下，假設你是Scrum Master，你一天到晚告訴團隊成員「自我管理」的觀念，希望團隊可以互相溝通、合作，並期待團隊可以持續交付高品質且對客戶有價值的產品。但是，這一切都將在每年打考績的季節「暫時停止」。因為在這個時候，公司的考績制度眼裡看不到「團隊」，只有個人，所以制度逼著部門主管必須要將團隊成員依據某種條件加以給分並排序。

Scrum團隊並不是說大家吃大鍋飯，像「大 少部分」的公務機關一樣，不管有沒有做事，大家考績都拿甲等。而是在「自我管理」、多重回饋機制、追求技術卓越等前提之下，我們相信團隊成員的表現應該是依據整個團隊遞交產品的價值來判斷。

HR人員：你說什麼我不懂啦，總之公司叫你打考績你就給我打就是了。如果遲交的話是要扣你的年度考績分數的喔。

好吧，要打就打給你吧。但是，如果每一個人分數都一樣，又無法通過HR這一關。那怎麼辦？！

說實話，這又是一個難解的問題。有些公司會在年初的時候，要求每位員工訂出今年的「績效目標」，然後在年底的時候找員工來對談，看看員工是否有達成年度目標。這種方法其實Teddy一直都不太喜歡。為什麼？很簡單啊，這種在年初的時候訂定目標，等年底再來檢視達成度的做法，不就是waterfall流程的翻版嗎？身為敏捷團隊，你所要面對的問題與技術挑戰隨時都在變，怎麼可能在年初的時候就把今年的「績效目標」給訂出來？簡而言之，Teddy對於這種所謂「目標管理」的方法，一向都不是很認同。

***

講了這麼多有的沒的，對於敏捷團隊，在逼不得已的情下，到底要怎麼打「個人考績」啊？以下提供幾點建議：

• 大原則：打考績的時候Teddy會建議團隊中每位成員的考績都會在中等以上，而且最高與最低相差不要過大。例如，假設滿分是100分，最低的可能是75分，最高的可能是95分之類的。這不是Teddy剛剛說的「公務機關每個人考績都是甲」的那種現象，而是因為如果已經採用Scrum一整年，而團隊中還有存著這種會讓你想要給「不及格」的頑劣分子，那就表示這一整年中此人都沒有改善。這一點基本上身為Scrum Master是要負一點責任的。如果Teddy是這個團隊的Scrum Master，遇到真正打混摸魚的隊員，三個月內不改早就把「牠」給踢出去了，不會等到年底打考績的後再來反映這個問題。不過這只是大原則啦，不同公司文化與團隊還是有著自己需要去微調的地方。
• 誰來打團隊成員的考績：Scrum Master不一定是團隊成員在「組織表上的部門主管」，而打考績通常是由「組織表上的部門主管」來負責。現在問題來了，部門主管負責打考績，但是他可能不知道團隊成員每天都在做些什麼。Scrum Master很清楚團隊成員每天都在做什麼，但是卻不是部門主管。Teddy會建議部門主管在打團隊成員的考績的時候，應該要「重度諮詢」Scrum Master與Product Owner的意見，畢竟這兩位才是每天都和團隊成員一起接觸的人，真正知道每一位成員的能力與付出。
• 誰來打Scrum Master的考績：這個就有點尷尬了，ㄟ…有人會說，可以交給團隊成員來負責，這也是一種方法，但總覺得怪怪的。還是那個句老話：「如果覺得有人做不好，為何不在retrospective meeting的時候提出來，而要等到年底才來大肆批判一番？」。當然，Scrum Master還是會有經驗與能力強弱之分。所以Teddy覺得，Scrum Master的考績，需要有交給一位「有智慧的主管」的負責。問題是，這種人很難找。所以，本題無解…Orz。
• 誰來打Product Owner的考績：理論上這一條稍微簡單一點，為什麼？因為PO是負責產品的成敗，所以老闆可以從PO所負責的產品，是否受到客戶歡迎這個最直接的因素來打考績。
• 要依據何種條件來打考績：無論依據哪種條件，絕對不能以「拍老闆馬屁的功力」或是「沒有功勞也有苦勞（年資）」等條件作為打考績的依據。抽象一點來講，可以用每位團員「實踐Scrum與敏捷作法的能力」以及「持續改善的進度」來做為依據。例如，從技術面來看，團隊成員對於物件導向、design pattern、單元測試、refactoring等的能力如何，若能力有待加強，是否很願意在工作中主動利用機會學習（例如透過pair programming）。成員是否主動溝通並且提出問題、有努力嘗試減少重複發生的相同錯誤等等等等等等。

***

上面講了這麼多，最後還有非常重要的一點，哪就是你的團隊要真的在實施Scrum，只是公司HR制度還沒有接受Scrum。如果你的團隊像Teddy在《這不是肯德基》所敘述的，只是「只是對外宣稱在實施Scrum，骨子裡還是傳統的專案管理方式」，那就不用想太多，用老方法打考績就可以了。

***

友藏內心獨白：打考績真的是一件很傷腦筋的問題啊。

這不是肯德基

August 19 22:01~22:57

圖片來源：http://wiki.komica.org/pix/img1074.jpg

 

廢話不多說，直接看內容。

路人甲：我們部門主管2-3年前從國外回來，他說他們在國外都在採用Scrum，所以自從他擔任我們部門主管之後，我們也開始採行Scrum。由於我們的專案很大，所以我們採用「Scrum of Scrum」，也就是說我們的專案由好幾個Scrum團隊來執行，每個團隊的Scrum Master會定期在自己開會。

Teddy：這樣很好啊。

路人甲：我有幾個關於Scrum的問題可以問你嗎？

Teddy：請說。

路人甲：我們也是有開Daily Scrum會議，但是因為大家都很忙，所以我們一個禮拜開一次Daily Scrum…

Teddy：等一下…Daily Scrum顧名思義，就是每天都要開的會議啊。你們一個禮拜開一次，那不是跟傳統的「週會」一樣嗎？

路人甲：是喔？我一直以為Daily Scrum就是只要「站著開會」就算是了，因為每天都開會好像沒什麼好報告的，一天能夠做出多少東西呢？所以我們就改成一個禮拜開一次。

Teddy：一個禮拜開一次就失去Daily Scrum的意義了，原本的回饋頻率從一天變成一週了。

路人甲：我們…

Teddy：等一下，我猜你們的工作模式，一定是「各做各的」，每個團隊成員負責某些程式模組，對不對？

路人甲：對耶，就是在sprint planning meeting之後，Scrum Master會把這個sprint每個人要做什麼工作都「分派」好。

Teddy：啊，什麼。你們的工作是由Scrum Master指派的？！

路人甲：對啊，因為Scrum Master比較有經驗啊，我們這些團隊成員經驗較淺，不知道要如何準確地預估工作時間…

Teddy：什麼，每個task的工時不是在sprint planning meeting（part 2）的時候由團隊成員一起估算出來的嗎？

路人甲：沒有啦，我剛剛說過了啊，團隊成員沒有Scrum Master那麼有經驗，所以task的工時是由Scrum Master指定的。

Teddy：我再跟你確認一下，你說你們採用的是Scrum嗎？

路人甲：對啊，我們主管說我們要採用Scrum啊，已經實施了兩年多了啊。

Teddy內心獨白：你們主管說要採用Scrum，但是你們可能不是很了解敏捷精神與Scrum，於是就用原本做專案的方法，把Scrum給改造之後並且填滿它了。

***

路人甲：我還有一個問題，我們分成很多個Scrum團隊之後，每個團隊開發出來的東西，最後經常發生無法整在一起的問題耶。

Teddy：那你們有採用持續整合嗎？

路人甲：持續整合？這是什麼？

Teddy：那我知道答案了，就是沒有…Orz。

Teddy：當一個專案由多個Scrum團隊共同完成時，持續整合就變得非常的重要。如果多個團隊沒有透過持續整合將各自開發的軟體每日頻繁地整合與測試，最後一定整不起來的啊。

Teddy內心獨白：所以你們又用傳統的方法，把Scrum給填滿了。2A。

***

路人甲：在Scrum of Scrum會議中，我們每一的團隊的Scrum Master總是在吵架耶。

Teddy：吵架…嘿嘿嘿，是不是為了決定誰要當那隻「代罪羔羊」而吵架啊。大家都在忙著把「專案為什麼進行不順利」的責任推到別人的身上吧。

路人甲：Teddy你會算命喔，怎麼都知道。

Teddy內心獨白：啊你都講成這樣了，我還猜不到那豈不是遜掉了。

Teddy：你們的Scrum of Scrum會議一定沒有每天開對不對？

路人甲：對耶，跟我剛剛說的「Daily Scrum」一樣，我們的Scrum of Scrum會議是一個禮拜開一次。

Teddy：好了，什麼都不用說了。你們這個哪是在採用Scrum啊。連Scrum的「樣子」（形式）都沒有，我看你們只是為了讓你們主管「以為」你們在採用Scrum，所以對外都要宣稱自己有在用Scrum吧。

路人甲：可是我們真的是在採用Scrum啊…

Teddy：好、好。乖，時間到了，快吃藥吧XD。3A。

***

結論；請參考標題…Orz。

***

友藏內心獨白：有病快去看醫生，不要硬撐。

120708（上）國軍英雄館早餐_台灣博物館

August 18 22:58~23:59

看到這幅壁畫鄉民們知道這是哪裡嗎？沒錯，就是台北市中華路上的國軍英雄館。今天起了個大早，六點半左右來到這裡吃有名的百元早餐。

 

人還真多耶，還好很早就到了，那時候還有位置。

 

關於食物…嗯，只能說，絕對可以吃到很飽，其他的不要想太多。有一點要強調一下，早餐的青菜還真的很好吃耶，主要以中式為主，這樣一百塊算很不錯了。

***

吃完之後先回家休息一下，11點多到位於二二八公園內的台灣博物館參觀。門票只要二十元，有夠便宜。

這兩位在拍什麼，腰彎成這個樣子？

 

原來是在拍「穹頂」。

 

館內還滿有趣的，廢話不多說，直接看照片吧。

 

左邊紅色拍照這個人是Teddy，右邊是Kay。

 

其實我們主要是要來看這個展覽的。

 

來到了三樓，看到很多懷舊的東西。

 

下午一點整，差不多該離開去吃午飯了。

***

友藏內心獨白：台灣博物館，給你一個讚 。

2012-07-01阜杭豆漿吃早餐

August 17 06:44~07:21

一大早七點半一堆人是在排什麼隊？原來是在排隊吃早餐。這一天和Kay到台北市善導寺捷運站附近的阜杭豆漿吃早餐。雖然Teddy住在台北也已經有N十年了，但是要不是前一陣子因為「開發票事件」上了電視，Teddy還不知道台北有這麼一家有名的早餐店。

 

阜杭豆漿位於華山市場之內，因為來的這一天是周日，很多店都沒開門。

 

排隊

 

準備上二樓，還是排隊。

 

來到二樓店門口還有教你排隊的排隊示意圖。

 

這個用餐環境好像是整個市場共用的，只不過週日其他商家沒開門，用餐的人全部都是阜杭豆漿的客人。在市場內使用黃燈，感覺好像來到咖啡廳。

 

現場製作早餐的師傅們，應該快累翻了。

 

點餐處，先點喝的再點吃的，整個流程還算順暢。

 

當天早餐，從排隊到拿到食物大該花了40分鐘左右。

***

結論：

1. 豆漿很好喝，食物也很好吃。
2. 不知道是不是因為假日的關係，感覺來吃早餐的人當中，有很多都是觀光客。除了台灣本地的觀光客之外，還有香港人和日本人。
3. 雖然人很多，但是現場位子還滿多的，不至於找不到位子坐。
4. 交通方便。

什麼…你問Teddy還會再去吃一次嗎？ㄟ…短時間應該不會了，光排隊的時間Teddy應該已經吃完兩次早餐了。

***

友藏內心獨白：第一次體驗到這麼長的買早餐排隊人龍XD。