敏捷方法實務研討會會後筆記4 - 測試驅動開發與工作時程

測試驅動開發 (Test Driven Development, TDD) 的觀念由來以久。寫程式時會順便寫測試碼，幾乎是所有有經驗的程序員在不自覺下養成的習慣。例如我在《運用訊息溝通網絡及軟體工程方法建立開放源碼專案之個人淺見》一文中，提到我以前用 C 語言寫程式時順手寫測試碼的習慣。不過那個時候，xUnit 這類測試工具還不普遍。當時看其他人寫的開放源碼程式，幾乎是人人各有一套測試碼的撰寫風格。但是隨著 xUnit 工具的普及，測試碼的撰寫方式也愈來愈一致了。同時，也改變了程序員編程時的習慣，帶動了先寫測試碼的「測試驅動開發」觀念。

TDD 的好處，基本用不著我多加說明。 Robert C. Martin 在《敏捷軟體開發-原則、樣式及實務》中寫的再明白不過了。儘管如此，在研討會中，我還是針對 TDD 提了一個問題。我的問題是：能不能藉由測試案例建立更準確的工作時程量測指標，以便掌握確切的工作時程。

陳教授說法，是標準說法。使用者完成故事卡後，由開發人員進行 CRC 會議，劃分出數個工作及預估的工作時程，寫在工作卡(task card)上。開發人員以工作卡為單元評估並簽認自己的要負責的工作。而這些工作卡會貼在牆上，供所有團隊成員查看進度時程。我們可在《eXtreme Programming理論與實務》、《敏捷軟體開發-原則、樣式及實務》等書中看到這方面的「規劃遊戲(planning game)」。

然而這個標準答案不能滿足我。實務經驗告訴我，我們通常會以程式的類 (class) 為單元劃分工作，以類的方法多寡及過去的開發經驗評估工作時數。這種評估方式跟 OOP 出現的歷史一樣久，久到我有足夠的經驗在腦海中一再提醒我：這樣不夠準。我相信資深的程序員都有這種難以說出口的經驗：我們經常輕忽類的複雜性與需求變化，而低估工作時數。尤其當自己還是菜鳥的時候。

"當你可以度量你所說的東西，並能以數字表示，意謂著你了解它" -- Lord Kelvin, 1883 Robert C. Martin，敏捷軟體開發-原則、樣式及實務

Martin 在《敏捷軟體開發》中提到了任務點數(task points)。我一直在想，我們有沒有什麼東西，可以把實際的編程工作項目條列化，而不是工作卡上的類的方法數目。如果我們能夠找出條列化的事物，就可以作為衡量工作時數或工作貢獻的任務點數。

我個人的經驗是用測試案例的測試項目作為任務點數。請各位先參考下列兩篇文章：

先說故事再動手設計

待實作的函數只有一個，其中只有3行程式碼。測試案例中的測試項目有4項。

Working with PHPUnit3 - 撰寫測試案例

待實作的類, DatabaseRow, 除建構子外只有兩個神奇方法 (__set, __get)。按 C# 的說法是泛用屬性存取子。程式碼約35行。測試案例中的測試項目有5項。

第一個例子只是一個3行程式碼的函數，而第二個例子是要實作一個類，其中有3個方法，約35行程式碼。如果用方法的數目 (1:3) 或是程式碼的預估行數 (1:10) 評估任務點數。基本上，負責第一個例子的程序員要吃大虧的。因為第一個例子的程式複雜度比第二個例子高，而且那是由一個熟悉 REGEX 字元規則記述法的程序員負責，才能做到如此簡單。但是若以測試項目做任務點數，那麼這兩個例子的工作比重就很接近了(4:5)。

我個人的解釋，或者說從經驗上得到的感覺，測試案例中的測試項目多寡，可以反應出對象的複雜度。愈複雜的對象，我們就需要編寫愈多的測試項目。

假若一個類其中有兩個方法，方法a 我們只編寫了2個測試項目，而另一個方法b 我們卻編寫了10個測試項目。經驗上可以推論，方法b 的內部複雜度可能較高，可能會接受較多的參數，可能含有較多的控制分支結構。因為方法b 要處理的情況較複雜，所以我們才會編寫那麼多的測試項目。

基於上述的經驗，我覺得可以用測試項目的多寡作為任務點數，進而評估工作時數和貢獻度。而且基於測試驅動開發中先寫測試碼的原則，我們有可能在編寫測試碼時就能準確地安排工作時程。

專案經理 (PM) 應該也很歡迎這種作法。專案經理只要執行一次測試案例看看有幾個綠燈，就能掌握小組成員今天的開發進度是快還是慢了。

然而以上所言，只是我的個人經驗。我並未待過實施敏捷方法的軟體公司，我是自己一個人在做 TDD (所以我的實務經驗顯示，導入 TDD 並不需要整個團隊都做。就算團隊並不採用敏捷方法，個人也可以把它當作單純的工具使用)。因此我只是從自己採用 TDD 進行開發工作時得到的感覺，認為測試項目可以作為任務點數。

在研討會最後的發言時間中，台科大的鄭教授 (我應該沒記錯) 有提到他的經驗。基本上我認為他的經驗跟我的想法一樣。我們確實有可能利用測試案例估算更準確的工作時程。更妙的是，鄭教授說他們的案子中，測試案例是交給專案經理寫的。跟我的想法不謀而合。我一直認為，若專案經理的工作之一是掌握時程進度，那麼由專案經理編寫跟時程進度息息相關的測試案例，是很合理的。

順帶一提。鄭教授也說，在他們的案子中有用整合測試工具，實現每日建置 (night building)。每天晚上結束工作前，執行一次整合測試，以確定工作項目順利完成。

可惜會後發言時間不夠，大家都要趕著回家過端午節。我還要趕著去火車站搭車回高雄，晚了撞上返鄉潮，那連可以輕鬆站的位子都找不著了。我的問題，勉強算是有一個不完整的答案。

相關文章

• 敏捷方法實務研討會會後筆記1 - 溝通與 Pair programming
• 敏捷方法實務研討會會後筆記2 - 駐廠使用專家與使用者參與
• 敏捷方法實務研討會會後筆記3 - 反覆式開發過程
• 敏捷方法實務研討會會後筆記5 - 資料結構與虛擬碼