過去的四年以來，軟體業一直在努力的追趕著像是極限程式設計這樣的敏捷方法的步伐。它們有什麼好處呢？能奏效麼？我們是不是應該去相信這些關於它們的傳言呢？我們是不是也應該在專案中進行嘗試？這些結論值得信賴麼？

刊物、文章都在對應用敏捷方法所帶來的難以置信的效果大肆的進行渲染，也有一些文章把敏捷方法貶損為使得軟體開發倒退回石器時代的方法。我們聽說過人們為此而取得的了不起的成就，也聽說過其他一些人告訴說敏捷讓他們的專案走近災難。

唉！

底線其實是這樣的。敏捷方法是關於如何去管理好軟體專案的，僅此而已。敏捷方法是用來提供給管理者們所需資料，以至於做出管理上的決策。

你該如何管理一個軟體專案？大多數的專案管理者都清楚去管理一個軟體專案更多的時候不是在用科學的方法，而是隨性。為什麼會這樣？因為獲取能切實反映專案的資料非常困難。

在我們為一個專案取好名字之前，在我們為專案收集需求之前，在我們挑選出適合的團隊之前，我們需要清楚的第一件事情就是最終期限。最終期限的定奪很大程度上是出於業務上的考慮： 或許股東大會正好要在那時候召開；或許在那天會有個內部展示；或許我們的資金只夠用到那個時候。不管原因是什麼，時間的確定是出於業務原因，並非技術因素。

此外，一旦期限被採納，就不能再變動了。唯一能改變此期限的方法就是延遲。簡而言之，最終期限是不能動了。團隊可能會做出一些估算來說明最終期限是無法達成的。但估算是個說不清道不明的東西，幾十年年來的資料告訴我們，我們在估算上做的有多麼糟糕；幾十年來資料也在告訴我們，我們一直都還對它抱有幻想。大多數的開發團隊都會用某種方法進行估算，並令其符合最終期限。

管理者們已經知道了最終期限，也掌握了達成它所需的估算，下一步就是做計劃了。他們可能會繪製一個PERT圖（譯註1）或是GHANT圖（譯註2），這些圖表向他們展示出了所有估算出的任務，以及它們的開發者是誰。這些圖表清晰地向他們展示出他們是能夠按時達成最終期限的，大家都很高興。

我其實不說你們也知道接下來發生了什麼：任務比預算要花更多的時間來完成；他們發現了之前沒考慮到的一些額外任務；幾周之內圖表就成了廢物。它可能還會呆在牆上一段時間，一天比一天的更加與事實脫離。

更糟糕的是需求發生了變化。我們丟掉了客戶X，於是我們也不再需要功能F了。我們可能贏得了客戶K，但隨之需要新添上功能G。

管理者們可能會要求繪製一個新版本的圖表掛在牆上，但他們依然堅持原先的最終期限不變。他們知道業務上需要這個專案於最終期限前達成。新計劃當然會展示出專案會延遲，或許還是不要制定這個新計劃的為妙。

管理者們經常會把施加壓力或是使用某種激勵辦法作為他們的法寶。他們會警告開發人員如果錯過最終期限會有什麼恐怖的事情發生，然後他們就找出一些有諸如攀巖之類的鼓舞士氣的圖畫掛在牆上，用來激勵他們完成專案。他們會在開發人員之中走動，並且詢問他們事情完成的怎麼樣了，於是開發人員迴應說：“很好！”，再然後，管理者們就回到了他們自己的辦公室去祈禱順利。

沒錯，我是在誇大事實，不過我相信你們中的大多數都曾經在做專案的時候見到過上述的某些情形。當然，我本人也曾遇到。

運用資料進行專案管理 

如果管理者們擁有真實的資料並用來管理專案會怎樣？如果掛在牆上的是它呢？

這個圖表展示出每週有多少任務做完了。任何人都能從中看出這個團隊大概平均每週做完45點工作。這是很有力的資料，但還不夠。如果我們還在牆上掛上瞭如下的圖片會怎樣？

這張圖表展示出，每週還剩下多少任務待完成。你可以看出這條線是怎麼樣下滑的，還能看到曲線中的反覆。這可能是因為增加了新功能，或是開發人員重新估算的某些任務。

如果我們在牆上掛上了這兩幅圖，那麼任何人都能觀察它，並且看出這個專案大概還需要八、九周才能完成。

有了這樣的資料，你就可以管理專案了。你能看出團隊工作的有多快，可能釋出的日期到底會在什麼時候。並且，你可以在專案一開始就看到這些，使用這些資料你可以做決策來擴充編制，減少功能，或是甚至改變最後期限。

沒有這些資料，你就只能祈禱，況且必然會在很晚的時候才發現問題，然後高呼補救晚矣。但如果你擁有這個專案的真實資料，就能及時地做出複雜的決策來進行補救，就可以管理專案產生良好結果。

採集資料

我們該如何採集這些資料？這就是敏捷方法所談論的內容，敏捷方法教會我們一些採集資料的方法，然後我們就可以把它們掛在牆上了。

經由敏捷方法中的極限程式設計方法所指導的專案能把專案分拆成很多非常小的可釋出件，我們稱之為“使用者素材”。每個素材可能需要一個人大約一週的開發時間。我們清楚的知道我們的估算能力都很糟糕，也明白需求將會改變，但又不得不去估算，那就讓我們從這些小劑量的使用者素材開始吧。

我們通常會隨意的選取某些使用者素材，然後儘可能準確地去估算。有的人喜歡用確切的開發天數來衡量，有的則喜歡用點數。比如說，我們可能會估算開發一個關於使用者登陸的素材耗時3點，而使用者登出的素材耗時2點。或許儲存功能的素材是5點，而撤銷的是6點。我們不在乎具體這些的“點”代表多少真實的時間，關心的是一個3點的素材所消耗的時間是6點的一半。

接下來，管理者和開發人員們對下週的目標達成了共識。打個比方說這個目標需要66點，團隊就會努力在下週完成這66點的工作。管理者以及客戶們（譯註3）選出了工作量為66點的使用者素材，然後由開發人員去實現。

我們當然不擅長估算，所以週末的時候我們會發現只完成了40點的工作，剩下的26點會被重新加入到待完成素材中。的確有些失望，但現在我們知曉了先前所不知道的東西，現在我們明白了我們一週只能完成40點左右的工作。於是從下週開始，管理者以及客戶們就會選出40點的使用者素材。

這回事情有所好轉，到星期三的時候我們就已經完成了38點工作，而且某些開發人員已經做完了他那部分。於是我們又選出了另外的一些使用者素材讓他們去做。到週末的時候我們總共做完了45點的工作。於是下週我們就會選出45點的素材，以此類推。

從牆上掛著的圖表中很容易看出當前的工作狀況。每週我們都會在圖上繪製一個條目來表示出上週我們完成了多少點，每週我們都會算出還剩下的使用者素材數量，並且也會在相應的圖表中繪製出來。基於我們最近的經驗，我們也會重新來評估剩下的這些使用者素材。因此，我們就能保證牆上的圖表儘可能準確、及時地反映情況。

通常在專案過程中會碰到這樣的情形：我們發現一些工作任務無法被拆分成小劑量的使用者素材；也還有這樣的說法：諸如那些基礎架構的事情要先做，而且要花上一週以上的時間來完成。這些說法都有失偏頗。一個又一個團隊告訴我們整個複雜的專案都可以被拆分成很多微小劑量的使用者素材；一個又一個團隊也告訴我們基礎架構不是在開始一下子搭建起來的，而應是一週周的逐漸增長起來的。

測試驅動開發

還有一種謬論是：資料是很容易摻水的。開發人員很容易告訴說他所負責的使用者素材已經“做完了”，但實際上還沒有。這是一種慣用招數，他們會把空函式或是隻實現了很少的函式提交上去，用來騙過開發進度的檢查。而實際上，不能工作的函式會被彙報成是個bug，因而並沒有拖延開發進度。（相信我，維基尼亞（Virginia），真的有這麼幹的團隊！）

測試驅動開發，特別是極限程式設計實踐中的驗收測試，給出了這個問題的解決之道。當管理者和客戶們挑選待開發的使用者素材的時候，他們也必須同時與QA一同合作，並且構建出自動化驗收測試。除非是通過了驗收測試，否則就不能說此使用者素材已經做完了。（可以訪問一個免費的驗收測試工具http://fitnesse.org）這種實踐方法讓管理者和客戶們能夠控制“做完了”的定義。

控制“做完了”的定義意味著管理者們也控制了圖表上所展現資料的有效性。當圖表上展示出上週有45點工作做完了，這就是說這45點工作被證明是做完了，因為這些使用者素材通過了管理者和客戶們所定義的驗收測試。因此，管理者們能夠信任這些圖表上的資料，並且可以依靠這些資料來幫助他們做出管理上的相關決策。

起初，要為所有的使用者素材都編寫出驗收測試確實有些困難，這些難處主要是圍繞者如何測試GUI、裝置驅動，還有編寫這些測試所要額外花費的時間上。可是，獲悉到這些圖表資料的有效性以及它所帶來的效益，通常這種動機就足以刺激他們去解決這些問題了。管理者們通常為了追求達到這種可預知度而甘願付出高昂的代價，況且，回報也是很可觀的。一旦測試實現了自動化，它們就再也不用通過人工方式來運行了。人工的測試成本可是相當昂貴的。

結論

諸如極限程式設計這樣的敏捷方法每一、兩週就能提供出可靠的資料，而管理者們就可以運用這些資料來為此專案的做出管理上的決策。他們可以運用資料來預測專案何時能完工，或是下個釋出會在什麼時候；他們可以運用資料來做出擴充編制或裁減人員的抉擇；他們可以運用它們來達成最終期限並讓成就客戶的預期。

產品研發中的這些資料才是敏捷方法的最終底限。這些資料是敏捷存活的基石，如果你正在使用敏捷方法，卻沒能用到過這些資料，那你所做得就不是真正意義上的敏捷。

譯註：

1，PERT，計劃評審法，全稱為Program Evaluation and Review Techniques。PERT誕生於20世紀50年代，主要用於簡化大型和複雜專案的時間管理。專案中的每項活動都被賦予最好、最壞和最有可能三項的時間估算。通過這些估算可以計算出平均的完成時間。而平均完成時間用來計算出關鍵路徑時間和整個專案的期望完成時間。關於PERT的詳細內容可參見http://en.wikipedia.org/wiki/PERT。

2，GHANT，甘特圖，原詞應為Gantt，或許是Bob大叔打錯了這個詞：）。甘特圖是一種用柱形或是條形統計圖來展示專案進度的常用方法。甘特圖展示了專案中活動的起始和終結時間。關於甘特圖的詳細內容可參見http://en.wikipedia.org/wiki/Gantt_chart。

3，客戶，XP強調客戶和開發人員在一起緊密地工作，以便於彼此知曉對方所面臨的問題，並共同去解決這些問題。XP團隊中的客戶是指定義產品的特性並排列這些特性優先順序的人或是團體。有時，客戶是和開發人員同屬一家公司的一組業務分析師或是市場專家。有時，客戶是使用者團體委派的使用者代表。有時，客戶事實上是支付開發費用的人。但是在XP專案中，無論誰是客戶，他們都是能夠和團隊一起工作的團隊成員。

本文是Uncle bob發表於2003年5月的文章，作者已授權翻譯。

Robert C. Martin是Object Mentor公司總裁，面向物件設計、模式、UML、敏捷方法學和極限程式設計領域內的資深顧問。他不僅是Jolt獲獎圖書《敏捷軟體開發：原則、模式與實踐》（中文版）（《敏捷軟體開發》（英文影印版））的作者，還是暢銷書Designing Object-Oriented C++ Applications Using the Booch Method的作者。Martin是Pattern Languages of Program Design 3和More C++ Gems的主編，並與James Newkirk合著了XP in Practice。他是國際程式設計師大會上著名的發言人，並在C++ Report雜誌擔任過4年的編輯。