[活動預告] C.C. Agile Sprint 8 - BDD in .NET

Mar. 27 04:23~05:38

4月份的C.C. Agile聚會將邀請Joey（91哥）來分享：「BDD in .NET - TDD 在實務上最後一塊拼圖」，對TDD/BDD有興趣的鄉民們可參考Joey所寫的「30天快速上手TDD」系列文章。活動將於2013/03/28 (四) 中午12:00 開放報名，報名網址請按我。

***

反省

讀了Joey所寫的TDD系列文章，Teddy回想起以前帶Scrum團隊時，對於「如何驗收Story是否完成」的歷程。

1. 在每個Story中增加一個「手動驗收」的task，這個task是最被認領的工作，負責確認這個story是否可正常運作。
2. 第1個方法做了一陣子之後，團隊發現除了需要對整個story做驗證，每一個task在移到DONE之前也應該要找「第三者」（非完成該task的另一個團隊成員）來驗證一下。因此團隊將工作看板（taskboard）的狀態由原本的Not Checked Out、Checked Out、Done，在Done之前增加一個Test的狀態。改用這個方法之後，原本單獨的「手動驗收task」也就不需要了。
3. 又過了一陣子，團隊導入RobotFramework做自動化驗收測試。但由於之前完成的story並沒有自動化驗收測試案例，於是團隊只能在每一個sprint安排一點點時間，補寫這些自動化測試案例。
4. 等自動化RobotFramework累積到一定數量之後，團隊慢慢熟悉RobotFramework自動化驗收測試的開發方法，並且對自動化驗收測試的功效慢慢具備信心。此時團隊針對每一個新開發的story，要求至少同時完成1~2個自動化驗收測試才算這個story做完（套句Scrum的術語，就是增強DoD的條件）。

***

鄉民：為什麼到4就沒了，接下來呢？

接下來Teddy就離職打工、寫書、創業了。以上所描述的整個過程，前前後後花了3年半的時間，才將團隊慢慢帶到導入撰寫自動化驗收測試的狀態（因為過程中還有很多其他事情要處理，所以也不能將所有的時間都拿來改善技術層面的問題）。

要讓開發團隊接受ATDD、BDD、TDD的開發模式，的確不是一件很容易的事情，尤其針對所謂有豐富（傳統）經驗的開發人員而言，要求他們能夠先寫production code再寫test code就已經很了不起了，更何況是要反過來先寫test code再寫production code，當然是打死不從啊。

老屁股內心獨白：我這麼英明，設計能力這麼強，為什麼要跟個白癡似的先寫一個一定會失敗的test code，然後再來設計production code哩！

***

Joey的系列文章寫得很棒，推薦鄉民們撥時間好好讀一下。Teddy讀完之後也有幾個問題，剛剛好可以趁C. C. Agile的時候向Joey請教一下。

參加課程或聚會除了聽講以外，發問也是一項重要的修練啊。

***

友藏內心獨白：要把東西串起來不容易啊。