2014北海道考察之旅Day8-D電視塔（上）

Feb. 11 13:19~13:50

下午準備前往位於大通公園的電視塔，經過大通公園地下通道。這個明亮的地下通道，又寬又長，兩旁有許多有趣的店家，還有可以喝咖啡休息的座位，令人印象深刻。

 

可愛的玩偶，一個微笑一個嘴角下垂。

 

地下通道每個一段距離有露天的開口，可以讓陽光和新鮮空氣進入地下通道，很棒的設計。

***

出了地下通道，望眼看去就是熱鬧的高樓大廈，遠遠可以看到高聳的電視塔。往電視塔走去，沿途可看到漂亮的小花，還有幾株楓樹做為代表，以紅衣相迎。

***

友藏內心獨白：很棒的地下通道。

測試案例壞味道（1）：三種分類

Feb. 25 15:20~16:32

Eiffel：要挑哪一本書好勒！

Teddy：書中自有小貓咪，我比較想要黃金屋啊XD。

 

自從領養Eiffel，想學小王子和狐狸建立馴養關係，因此花了不少時間陪牠。加上最近偷懶沒看什麼新書，部落格又快斷炊了。只好使出老招，把書出來抄…嗯嗯，是介紹才對。有一陣子沒寫測試的文章，就來介紹《xUnit Test Patterns: Refactoring Test Code》書中提到的幾個關於測試案例的壞味道，應該可以擋一陣子先。

書中把壞味道分成三大類，每個分類各有若干個壞味道：

1. Code Smells：
   • Obscure Test
   • Conditional Test Logic
   • Hard-to-Test Code
   • Test Code Duplication
   • Test Logic in Production
2. Behavior Smells：
   • Assertion Roulette
   • Erratic Test
   • Fragile Test
   • Frequent Debugging
   • Manual Intervention
   • Slow Tests
3. Project Smells：
   • Buggy Tests
   • Developers Not Writing Tests
   • High Test Maintenance Cost
   • Production Bugs

***

這15個壞味道，有些看名字就大概可以猜出內容是什麼。日後會逐一介紹每一個壞味道，今天要先談這三個分類的意義。首先，Code Smells是指必須透過閱讀程式碼（測試案例）來判斷的壞味道，例如Conditional Test Logic（條件式測試邏輯）顧名思義就是測試程式中出現了條件判斷式，又例如Test Logic in Production指的是在production code裡面出現測試邏輯。這些壞味道都和測試程式碼的結構直接相關。

Behavior Smells是指影響測試案例執行結果的壞味道，例如Slow Tests一看就知道是跑得很慢的測試案例，Manual Intervention則是需要人工介入的測試案例。這兩種情況都是鄉民們在撰寫自動化測試案例不希望看到的結果。

Project Smells用來表示專案整體健康狀況，不用看測試程式碼甚至不用執行它也可以發現這些壞味道。例如有著Buggy Tests（有臭蟲的測試案例）的專案不用說一定是不健康的專案，還有Developers Not Writing Tests（開發人員不寫測試案例）當然也是很嚴重的問題。

***

知道三個分類的意義之後，就可以進一步逐一來認識每一個測試壞味道的。

***

友藏內心獨白：知道定義是很重要滴。

C.C. Agile Sprint 30實況報導

Feb. 24 22:13~23:15

 

2月5日是C.C. Agile Sprint 30舉辦的日子，時間過的好快轉眼也辦了30次聚會。本次的主題是「Coding Dojo – Prepared Kata 程式道場之套路練習」，邀請北科大電機系博士生葉明哲與林子閎，為我們打出一套保齡球的Prepared Kata。

Coding Dojo中文翻譯為程式道場，專門為了習「武（程式）」之人所創造出的環境，進行的方式有Prepared Kata（預備套路）和Randori Kata（亂鬥）兩種。一般Coding Dojo大多採用Randori Kata的方式進行，選定題目之後，由參加者輪流上台，在固定的時間內（例如五分鐘）採用pair programming與TDD的方式來解題，時間到了之後每次換一個新人上台接手。

Prepared Kata的進行方式則需要請分享者事先準備好題目和熟練解題過程，在台上藉由TDD、refactoring和baby steps逐步展示解題的過程，讓觀眾「欣賞」分享者美妙的解題招數。因為Prepared Kata需要有人事先準備，而且這個準備過程需要花費不少時間熟練，所以一般Coding Dojo比較少採用（因為大家都懶的準備啊XD）。

***

這次因為Teddy上學期在北科資工所兼任一門「敏捷與精實軟體開發」課程，其中有些人的期末報告的題目是Prepared Kata，一魚兩吃機會難得，課程結束後順便請修課學生來C. C. Agile打一套拳給鄉民們欣賞。

***

當日活動投影片在此

C.C. Agile#30 – Coding Dojo – Prepared Kata from CCAgile

***

友藏內心獨白：有病治病，無病強身。

再探專案複雜度

Feb. 24 11:12~12:45

翻拍自《Essential Scrum》

 

在〈四種專案複雜度〉介紹了《Strategic Management and Organisational Dynamics: The challenge of complexity》書中依據需求與技術的不確定性將專案區分成4種不同類型（參考下圖）。

 

上圖在很多介紹Scrum的書中都出現過，在《Essential Scrum》參考另外一篇文章，將專案類型分成5種，除了原本的simple、complicated、complex、chaotic（anarchy）以外，增加了disorder這一類。《Essential Scrum》把這5類解釋得很清楚，今天重新回頭再體會一次這幾種專案分類的意義，以及Scrum適合應用在那種專案之中。

• Simple：對於簡單型專案，每個人都可以看出其中問題的因果關係。問題的解法通常是顯而易見，沒有什麼重大爭議。 Scrum也可以用來處理簡單型專案，但可能不是最有效率的方法。柯P常放在嘴邊的SOP（標準作業流程）就比較適合用來處理這類型的問題。如果鄉民們要重複生產或製造某樣產品，例如工廠生產線、擦油漆，採用一個標準的作業流程會比採用Scrum要來的合適。
• Complicated：複雜專案需要借用專家的知識來協助解決問題。問題的答案可能有好幾個， 需要專案依據他的經驗與專業知識來判斷並選擇合適的解法。Scrum很顯然適用於此類型的專案，但可能不是最佳的方法。例如，資料庫效能最佳化牽扯到很多參數的調教，最好交由有經驗的DBA來處理。許多軟體專案的維護工作，包含技術支援與解bug，也屬於這一類型。
• Complex：在錯綜複雜專案中，許多事情都無法預期。如果問題有正確的答案，這個答案只有在事後（問題發生之後）才知道（傳說中的事後諸葛亮）。Scrum很適合這種專案，需要探索問題，然後根據所學習到的知識調適後續的解決問題的做法與方向。針對這種專案，鄉民們需要保持創意，而且公司需要創造一個不怕失敗甚至是鼓勵失敗的環境。創意性的新產品開發或是針對現有產品的創新改良屬於這種類型的專案。
• Chaotic：混沌專案需要快速回應，好比身處在重大危機當中，必須要立即反應以避免進一步的傷害，然後收拾殘局以備東山再起（怎麼覺得跟買賣股票好像，大勢不好的時候要壯士斷腕停損殺出XD）。例如，你公司製造的橄欖油被發現原料有含銅葉綠素，遇到這種問題該如何處理？Scrum顯然不是很適合用在這種場合，此時鄉民們並不關心product backlog item的優先順序，也不需要挑選下個sprint所要施工的需求。針對混亂專案，需要有人來扛起責任並做出回應。
• Disorder：當你不知道你屬於上述4種專案的哪一種的時候，你就屬於disorder狀態。處於這個類型的專案是相當危險的，因為你不知道要採取哪種行動來解決問題。當然在這種狀態中套用Scrum是沒有意義的，你要做的事是要想辦法離開這種狀態。

***

最適合Scrum的專案類型是Complex，當鄉民們把Scrum應用在其他類型的專案時，要小心提醒自己是否用了不合適的工具。

***

友藏內心獨白：看法又多了一層。

開發團隊的技能（下）

Feb. 21 16:20~16:43

專心打獵XD。

 

今天介紹《Essential Scrum》提到開發團隊所需技能/特性的最後四點。

• Right-Sized：Scrum建議團隊人數不要太多，約在5~9人之間。
• Focused and Committed：開發團隊成員必須要專注並且承諾努力完成團隊的共同目標。也就是說，一個人最好屬於一個Scrum團隊，不要在不同的專案中切換。
• Working at a Sustainable Pace：穩定的工作步調最簡單的說法就是一天工作8小時，儘量不加班。Scrum是一種pull model的工作模式，由價值鏈的下游往上游抓取工作，「理論上」可以避免傳統push model所產生的工作壓力與減少不必要的半成品庫存。
• Long-Lived：維持高效率的團隊是相當不容易的成就，Scrum建議不要因為專案結束就把團隊拆散，應該讓儘量維持團隊運作，讓這個已經形成默契的團隊處理不同的專 案。

***

最後這四點是開發團隊的特性，你的Scrum團隊是否具備這些特性呢？

***

友藏內心獨白：每天自願加班不是正常Scrum團隊的特性。

開發團隊的技能（中）

Feb. 20 17:14~17:55

一個人怎麼組Scrum團隊啊…Orz。

 

今天繼續介紹《Essential Scrum》書中提到開發團隊所需的技能。

• Musketeer Attitude：看過《三劍客》的鄉民應該會記得裡面的一句名言：「All for one and one for all（我為人人，人人為我）」，這一點強調開發團隊（以及Scrum團隊）一起成功或一起失敗的團隊責任，沒有個人的成敗。

Musketeer Attitude反應在很多地方，例如在一個運作良好的開發團隊，不會有人說：「我的工作已經完成，你的工作卻沒有做完，所以導致這個story無法完成。」在打考績方面，Scrum建議不要有個人考績，只有團隊考績。最後，swarming（團隊成員聚

• High-Bandwidth Communications：開發團隊成員之間，以及與ScrumMaster和Product Owner之間必須以「4G 高頻寬」的方式溝。最簡單的方式就是面對面溝通，如果是分散式團，則可以利用視訊、電子郵件、即時通訊軟體、群組軟體、分散式合作系統等來增進溝通的頻寬。另外，像是組織跨職能團隊與維持小團隊規模也可以增加溝通的效率。
• Transparent Communication：除了要提高溝通的頻寬以外，透明性對於有效溝通也是很重要的。如果溝通的雙方無法坦率、真誠的交換意見，再多的溝通也是枉然啊。

***

友藏內心獨白：Software development is all about communication。

2014北海道考察之旅Day8-C拉麵共和國午餐與伊勢丹百貨閒逛

Feb. 10 23:32~23:52

離開札幌舊都廳之後走回札幌車站附近的百貨公司找吃的，來到一個叫做「拉麵共和國」的地方，隨意找了一間店吃飯。點了一碗拉麵和一碗乾麵，好好吃。來日本吃拉麵幾乎不會採到雷。

***

吃完午餐之後在伊勢丹百貨逛了一下，原本想找個地方喝下午茶，結果看到驚人的抓娃娃機。商品除了娃娃之外，還有餅乾，連北海到新鮮玉米都有，好神奇啊。

 

最後在地下街找到喝下午茶的地方。

 

帳單。雖然餐點沒有很精緻但價錢也不算貴。

***

友藏內心獨白：終於可以休息一下了。