本文是對Cedric發貼的回覆
一些贊成
Cedric提出了一些不錯的觀點，尤其是指出瞭如果敏捷開發的“傳道士們”只使用教條的論點，而不去接觸那些遇到實際的問題的真實的開發者，那麼他們就沒法再將敏捷進行到底。早期的接受者已經採納了；而下一代是比較搖擺不定的，想影響他們我們就必須用更強的與現實開發緊密相連的論點。
然而，我非常不贊成Cedric所提的關於“風險的考量”的觀點。從我的觀點來看，發佈那些你不確定能運行的代碼是完全不可取的。要麼確信發佈的能運行，要麼就不發佈。在這一過程中，有足夠的風險要去處理。
風險的考量
此外，沒人能真正的做到風險的考量，他們真正能做到的是去希望。他們希望他們的代碼能工作得足夠好，使得客戶和經理們都不會爲之發脾氣。坦白的講，正是這種抱有希望的態度才讓軟件工程師看起來像是個傻瓜。我們樂觀地發佈了軟件的最新版本，然後手指交叉於背後，祈禱客戶不會做那些會讓系統崩潰或是數據庫毀壞的事。
一個會崩潰的功能遠比那些未實現的功能要糟糕的多。一個未實現的功能會使發版延期而且可能會給競爭對手帶來優勢，可是一個會崩潰的功能卻讓我們的客戶變成敵人。客戶像我們所承諾的那樣使用着這些功能。當我們發佈了一個功能，那是在承諾它是可以運行的；當它崩潰了，我們就破壞了曾經許下的承諾；如果破壞了太多的承諾我們就失去了信任。
棧、對列、保齡球和FitNesse程序（譯註1）
Cedric抱怨的所有有關TDD（譯註3）的例子都是些不重要的小事，像是棧、對列、和那些保齡球遊戲程序。你有理由去懷疑這樣簡單的例子，因爲它們不是真實的。但這樣簡單的例子的存在也是有理由的，那是因爲它們與當時環境吻合。所以這是個老問題，而且Cedrick也不是第一個提出它的人了，它是在35年前的那場無休止的關於結構化編程的爭論中被提出的。
然而，Cedric對於沒有重要例子的觀點是錯誤的，我想爲Cedric介紹一下FitNesse程序。它有30,000行Java代碼，先寫的測試，而且測試的代碼覆蓋率（譯註4）達到90%以上。我非常建議他去學習學習FitNesse程序，這既是個正面的例子，也有的反面的。FitNesse是一個擁有真實客戶和真實問題的真實應用程序，它是一個web驅動的程序，有後臺數據庫和一些相當複雜的業務規則，而且涉及多個獨立進程和多種語言。
測試不是程序行爲的描述
當然測試是，它是程序行爲的清晰描述。我也同意測試不能說明所有事情，power-function就是個可以說明的例子（雖然我很想問問Cedric他拿什麼來確保它的軟件是能工作的）。你不能用測試來描述所有東西，但你卻可以描述很多。實際上，你可以通過編寫測試來做到描述系統的絕大多數重要的行爲。
這可不是什麼新花樣，帕納斯表就是一個能用測試來清晰描述的例子，決策表也是一個。實際上，軟件行爲最好可測試，否則系統的測試就會無章可循。
Cedric認爲你無法依賴於測試去描述你的系統，這是對的，但他關於通過測試來描述系統的原則是錯的。除了編寫測試並使之通過，幾乎沒有比這更清晰、通用的方法了。
任何不能測試的都是無用的
如果你不能測試它，你就不知道它能運行。如果你不知道它能運行，它就是沒用的。如果你有一個需求，可是無法證明你能實現它，那這就不是一個需求。
但你可以測試
計算機的任何行爲都是可測試的。而且，對於任何運行於有限內存中的計算機程序，你都能用有限的測試（具體數目可能會很大）來證明它是能夠按照預期工作的（就算是power function）。因此，最終描述一個程序行爲的是能夠示意其行爲的完完整整的一系列測試。當然，每人能測試那麼多（覆蓋程序全部行爲），所以我們選用統計手段。我們選擇代碼覆蓋而不是路徑覆蓋（譯註5）；我們確保每一行代碼都能在測試中執行到；我們確保每一個程序分支都被測試到；如果我們測試過每一行代碼，每一個程序分支，這個系統就能按照預期所描述的工作，而且，我們就實現了風險的考量（在此情況下確實如此）。我們稱此爲“一份耕耘，一份收穫”。
Cedric所談論的“風險的考量”，他可能是在說一種在比上述所談更初級的階段。如果一個開發團隊，他們花了足夠的努力在測試上，而且做到了讓所有代碼行和程序分支都被覆蓋到了一個很高的層級，而且他們清楚這樣的覆蓋層級上，程序的缺陷密度會被控制在一個足夠低的級別中，那麼他們就算是做到了風險的考量，那是因爲一份耕耘，一份收穫。
進而，我們就不會再講像是“我上週在筆記本上運行過，看起來能正常工作啊。”的話了。
敏捷人是認同它的
其實，敏捷人是認同它的。我們非常的認同，而且我們一直以來都在幫助這個行業的其它人也接受它。現在，幾乎公司無論大、小，幾乎都至少用過敏捷開發方法的一、兩種。還有很多很多在此技術上下了很大的功夫，而且他們現在正在享受着敏捷所帶來的好處。
敏捷不是銀彈；敏捷也不是答案。但是敏捷技術，尤其是TDD，是能夠確保軟件寫好的強大技術，而且也是確保整個行業的專業水平得到提升的強大技術。
譯註：
1，Fitnesse，一個知名的驗收性測試（譯註2）框架，Object Mentor公司開發。
2，驗收性測試，又成爲容忍測試，敏捷方法認爲，如果一個構建（build）通過了驗收測試，基本上這個構建就可被“接受了”。
3，TDD，測試驅動開發，一種典型的敏捷開發方法，詳情可見相關文章。
4，代碼覆蓋，code coverage，實際上作者此處是指白盒測試中的語句覆蓋和分支覆蓋，即statement coverage和branch coverage。語句覆蓋是最起碼的結構覆蓋的要求，語句覆蓋要求設計足夠多的測試用例，使得程序中每條語句至少被執行一次。分支覆蓋，又稱判定覆蓋，它要求設計足夠多的測試用例，使得程序中每個判定之少有一次爲真值，有一次爲假值，即程序中的每個分支至少執行一次。每個判斷的取真、取假至少執行一次。
5，路徑覆蓋，path coverage，設計足夠多的測試用例，覆蓋程序中所有可能的路徑。這是覆蓋面最廣的測試方法，也是對程序最徹底的測試，但需要大量複雜的測試用例纔可實現。
（原文鏈接網址：http://www.butunclebob.com/ArticleS.UncleBob.AgilePeopleStillDontGetIt; Robert C. Martin的英文blog網址： http://www.butunclebob.com/ArticleS.UncleBob）
譯者注：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年的編輯。