l

2013年3月27日 星期三

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

Mar. 27 04:23~05:38

911178583391837

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請教一下。

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

***

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

沒有留言:

張貼留言