Interview by Elden Nelson Translated by Gigix
每個人都在談論敏捷開發（Agile Development）。但是，你是否選擇了正確的方法學？你所選的方法是否正常運轉？你是否應該請求顧問的幫助？你應該如何管理開發的過程？還有，如何修補那些“先天不足”的代碼？輕量級方法學的大師Martin Fowler 將回答這些問題。
應該問什麼？
記者：在尋找適合自己團隊的方法學時，開發經理應該提怎樣的問題？
Fowler：首先，他們需要 對自己的項目有一個充分的瞭解。他們需要了解項目中主要的風險，同時應該瞭解企業的文化和涉及此項目的團隊成員。我一直都認爲：你應該選擇適合於團隊的方 法學，而不是相反。實際上，“敏捷宣言”的主要規則之一就是：個人之間的交流比過程、工具更重要。團隊中的個人以及這些個人協同工作的方式，這是項目成功 的一個重要因素，比對過程和工具的選擇要重要得多。
記者：回到前面那個問題。第一件應該問的就是：“你所做的是什麼項目？”是這樣嗎？
Fowler：準確地說，應該 是“你所做的是什麼類型的項目”。涉及上百人的航空軟件項目和只涉及六個人的網站項目，它們採用的方法學肯定是不一樣的。曾經有一個人跟我談起他的工作。 以前他認爲由小變大是一個困難的過程，但是後來他發現由大變小也同樣困難。大型項目所選擇的方法學對於小型項目通常就不適用了。另外，軟件產品的類型也是 影響因素之一。嵌入式系統和商用軟件，它們採用的方法學肯定也是不同的——這有一點猜測的成分，因爲我從來沒有開發過嵌入式系統，只開發過商用軟件。
記者：你剛纔還提到，開發經理應該瞭解他們可能遇到的風險？
Fowler：是的，開發經理 必須知道哪些因素可能導致項目失敗。例如，敏捷社羣一直關注的一個重要問題就是需求的易變性。如果需求不確定、無法將需求固定在某個合理的層面上，那麼選 擇敏捷方法就會比較合適。傳統的軟件工程方法總是要求你將需求固定住，並且在後續過程中不再變化。因此，需求的易變性就會成爲一個重要的風險源。我認爲， 這種風險對於“是否選擇敏捷方法”起着決定性的作用。
記者：你剛纔提到的第三點是“企業或者開發團隊的文化”。你好象認爲這比方法學本身還要重要，爲什麼？
Fowler：很明顯，如果我 能有一打頂級的程序員，而他們又能很好地合作，我就會讓他們自己去盡情發揮。這時，使用什麼過程根本就無所謂，因爲他們的天才一定會讓我們勝出。這是我們 這一行中的一個決定性因素：如果優秀的人能很好地合作，那麼他們一定比普通團隊做得更好，因爲他們自己就會找到最適合他們的工作方式。實際上，這也是敏捷 過程的一個非常重要的概念。OTI 的Dave Thomas 說，這個世界上有兩種開發者：適合他的和不適合他的。他的方法學就是：僱傭那些適合他的人。這正是OTI 之所以獲得成功的重要因素之一。
記者：假如你的公司裏沒有一個真正意義上的“明星程序員”，而只有一些不那麼出色的、需要大量管理工作才能保證代碼質量的程序員，你會怎麼辦呢？你有什麼辦法彌補人員上的缺憾嗎？或者你要把他們全都解僱掉，然後再從頭開始？
Fowler：呵呵，如果可行 的話，我就會把他們解僱掉，然後重新僱一批聰明的人來。不過，這通常都不可行，你必須充分利用手上的資源。你必須認識到：即使沒有一批天才，只要讓一批庸 才很好地合作，也能獲得很好的效果。而作爲經理，你應該做的就是：給沒有良好傳統的團隊灌輸一個合適的過程。同時，對於個人能力不那麼突出的團隊，我會非 常重視提高他們的能力。如果你能提高他們的個人能力，那麼你也能獲得更多的優勢。不過，這並不意味着我要放棄過程的引入。
記者：現在，開發經理已經知道自己要開發的是什麼樣的項目，也知道項目的主要風險所在，對企業文化也有了足夠的瞭解。那麼，他應該如何藉助這些信息來指導他的團隊選擇正確的方法學呢？
Fowler：在瞭解了 這些情況之後，就應該去閱讀各種不同的方法學，並拿你擁有的這些信息去和這些方法學的約束條件作匹配，從中做一個最佳選擇。然後，讓你的團隊實施所選的過 程，並堅持幾個月。注意：應該完全按照這種方法學所說的去做，哪怕它所說的聽起來並不是一個好主意，也照着它去做。我看到很多人選擇一種方法學，卻不照着 它所說的做。這是一個非常嚴重的問題。比如說，在極限編程（Extreme Programming，XP）的典型情況下，人們會說：“我們想要進行極限編程，不過不想採用其中‘測試’那一部分。”當然了，如果你不按照XP 的要求那樣進行嚴格的測試，整個過程都會失敗。因此，你應該根據自己的經驗來判斷哪種方法學適合於你，然後全力以赴地實施它。這是敏捷開發的一項重要原 則。
何時尋求幫助？
記者：假設一個開發團隊已經提出了恰當的問題，挑選了一種方法學，並且開始嘗試⋯⋯但還是遇到了困難。開發團隊應該在什麼時候尋求外部的幫助呢？
Fowler（笑）：我的公司從事大量的顧問工作，恐怕我的答案會有個人因素吧？正如我前面說過的，經驗豐富的、聰明的、優秀的程序員，他們總是能幹出卓著的成效。因此，引進一些好的經驗和一些好的建議總是會有所幫助的。
記者：外部的幫助對開發團隊有什麼好處？
Fowler：有幾種不同的方 式。很多幹這一行的人採用的都是“導師制”的方式：從團隊之外帶來一個人，讓他作爲整個團隊的導師。這個人要成爲項目組的一員，並且確實做一些開發工作， 但他的主要職責是指導其他人。顯然，如果你涉足一個比較新的領域，導師制會是一個不錯的選擇。我們在ThoughtWorks 採用的方式則是所謂的“合作制”：開發團隊中大約1/3 甚至1/2 的人來自顧問方。這些人有兩件事要做。首先，他們幫助項目獲得成功；同時，他們還要教給其他人如何工作。合作制的好處在於：顧問能更好地理解團隊的工作， 團隊的成員也能獲得更合理的指導，並從中學到更多的東西。
記者：哪些跡象表示團隊需要幫助呢？
Fowler：哦，我是 堅定不移地相信迭代式開發的，也就是說，我們應該在每次迭代結束時都發布有商業價值的代碼。如果你發現某次迭代發佈的東西不夠多，或者發佈的質量不夠好， 這就意味着你遇到困難了。此時，你就應該尋求幫助。的確，迭代式開發很有價值。比起瀑布式開發，迭代式開發能讓你更好地跟蹤項目的進度。開發者可以管理自 己嗎？
記者：能不能讓開發者自己管理自己？或者，在什麼時候需要專門讓一個人來管理開發者？
Fowler：呃，這個 問題的答案取決於你如何看待“管理”這個詞。任何一個團隊中都有非常重要的管理者：他們幫助人們分工協作，他們保持團隊中、團隊與外部良好的人際關係。這 些東西，從傳統角度來看並不屬於“管理”的範疇，但這的確是管理者的責任。爲了進入軟件開發這個行業，你必須有一定的才華。我是說，在軟件開發者這個圈子 裏，哪怕比較差的那一部分，他們也是相當聰明的。只有那些才華橫溢的人才可能出人頭地。所以，我一直都認爲：軟件開發是一項專業工作，正如律師、醫生的工 作是專業工作一樣。而軟件開發者，他們所做的是專家的工作，也應該得到專家的待遇。你不可能讓一個普通行業的管理者到律師事務所去教這些律師怎麼工作，也 不可能讓一個非醫學專業的人到診所去教醫生如何治療病人。同樣，你也不應該讓一個沒有技術背景的人去指揮程序員、設計師們的工作細節。因此，管理很重要， 但我們所說的這種“管理”和大多數人所理解的“管理”根本不是一回事。
記者：那麼，管理者應該做什麼呢？
Fowler：呃⋯⋯創造一個良好的環境，讓所有人能齊心協力解決問題。然後，保證團隊所有成員都能順暢地彼此交流。我見過一位非常優秀的經理，他就很善於促進團隊成員之間的交流。在他的團隊中，每個人都知道項目的進展情況，成員能夠很好地協作解決問題。
重構適用於什麼地方？
記者：你可以算得上是“重構之父”了。重構似乎在很多方法學中都適用。你對於重構的定義是怎樣的？
Fowler：重構（refactoring）是這樣的一種技術：在不對代碼的功能特徵作任何改變的前提下，修改現存代碼的結構，以提高設計的質量。
記者：你認爲重構適用於開發過程的什麼地方？
Fowler： 人們通常會在兩個地方使用重構。最顯而易見的就是：當你接手一塊設計質量不高的代碼時，你可能想要改進它，因此就需要使用重構。如果代碼的設計質量很糟 糕，那麼新功能的添加和錯誤的修復都會非常困難。但是你又不願意從頭開始重新編寫整個軟件，因爲工作量太大。這時，重構就給了你第三種選擇：你可以藉助這 一系列技術有條不紊地逐步改進軟件的結構。對於重構的第二種用法則是在XP 項目中的那種方式。在進行極限編程時，你會持續不斷地使用重構。每天你都會對自己寫下的代碼做一些重構。所以，每當你要開始一個新任務時，你就會看着以前 的代碼說：“這些代碼能讓我輕鬆地加入這項新的功能嗎？”如果不行，你就會重構它，使得新功能的加入更容易。在努力讓測試能夠通過的過程中，你可能並不太 關心設計的質量，而只是關心如何實現功能；但是，一旦測試能夠順利通過，你就必須進行重構，將設計質量提高。總之，在進行極限編程時，你會持續不斷地對代 碼進行重構，以保證設計質量不會降低。因此，這種方式與前面所說的“處理遺留代碼”的方式有所不同。不過，如果你成功地通過重構將遺留代碼的質量提升到了 一個相當高的標準上，那麼你應該會採用XP 的風格進行後續的開發。
記者：除了XP 之外，重構還適用於別的方法學嗎？
Fowler： 重構適用於任何方法學。只要你現有代碼的設計質量不合你的要求，你就應該考慮重構它。不過，如果有一整套自動化測試的支持，那麼重構會更有保障，因爲自動 化的測試是重構的一個重要的前提條件。如果你無法使用自動化重構工具的話，至少要有自動化的測試。有很多人在瀑布式的開發中也成功地使用了重構。所以，只 要你希望改進代碼的質量，重構就是值得考慮的技術。
記者：有沒有哪種方法學不鼓勵重構呢？
Fowler：我想，的確有一些方法學試圖降低對重構的需要。基於工程的方法學的核心思想就是：在寫任何一行代碼之前，你必須先完成整個設計。這種思想認爲：如果你的設計做得正確無誤，你就不需要重構，因爲代碼質量一定是非常高的。當然，實際上很難把設計做得那麼好。
記者：既要讓開發者有重構的自由，又不能失去對代碼和配置的控制，開發經理要如何應對這種矛盾呢？
Fowler： 重構與代碼的所有權並不矛盾。不過，在那種強調代碼所有權的方法學中，的確難以進行重構。在我看來，代碼的所有權大抵有三種形式：強所有權、弱所有權、以 及集體代碼所有權。XP 鼓勵的是集體代碼所有權，有人認爲這是“沒有代碼所有權”，但實際上這意味着“所有人擁有所有代碼”——任何人都可以在任何時候修改任何一部分的代碼。之 所以將它稱爲“集體代碼所有權”而不是“無代碼所有權”，是因爲團隊作爲一個整體負責保證所有代碼的質量，因此代碼就是集體所有的。“強代碼所有權”則是 另一個極端：這種模型將代碼分成幾大塊，交給每個開發者一塊，每個開發者只能修改自己的那一塊代碼。而在“弱代碼所有權”的模型中，仍然需要將代碼分成 塊，並分配到人，每個人負責確保自己那一部分代碼的設計質量。但是，如果有需要，其他人可以來修改他負責的代碼。這也可以看作是與代碼的擁有者之間的某種 合作關係。可以看出，強代碼所有權的開發模式並沒有阻止開發者進行重構，但在這種模式下重構的確會變得困難。一個典型的例子就是給方法改名：你的代碼中有 一個方法，它的名稱不能很好地描述它的用途，因此你希望將它改名，給它起一個更具有描述能力的名稱。但是，如果你的團隊採用了強代碼所有權的開發模式，而 你想要改名的又是一個公開的方法，你就必須費很大的力氣才能完成這次改名。因爲這個方法可能被很多其他的地方調用到，而那些調用它的代碼可能是由其他人來 擁有的。在這種情況下，你必須將改名之前的舊方法標記爲“不推薦使用”，並使其調用改名後的新方法。這會大大降低你的效率，並且讓你感到非常煩躁。而在弱 代碼所有權的模式下，你也許就完全可以直接修改那個方法的名稱，並修改它所有的調用者。這並不是說沒有人對其他的代碼負責，只不過他們可以給你一定程度的 方便，讓你完成你的修改。如果你使用了自動化重構工具的話，這樣的方便就尤其重要了——在這種工具中，給一個方法改名只需要點擊一個按鈕並輸入新的名稱就 行了。如果要選擇弱代碼所有權或者集體代碼所有權的開發模式，就必須同時選擇一個同步控制系統來進行源碼控制。CVS 就是這樣的一個系統，它允許多人同時更新同一塊代碼，並通過沖突檢測等技術來保證不會把事情
搞亂。
要不要敏捷開發？
記者：什麼時候不應該使用敏捷開發？
Fowler：當你能獲得固定不變的需求時。如果你知道需求是固定不變的，你也瞭解自己要使用的技術，對於開發團隊的能力也很清楚，那麼傳統的軟件工程方法會更合適。
記者：你遇到過這種時候嗎？
Fowler： 呵呵，問題就在這裏，不是嗎？實際上，我們總是遇到無法確定的需求。那麼，你要怎麼面對這些變化不定的需求？敏捷開發者們說：好吧，讓我們假設“無法確定 的需求”是隨時都存在的，並提出一種能夠包容它的開發過程——實際上，還不僅僅是包容，而是歡迎這種不確定性。傳統的軟件工程方法教我們如何將需求固定下 來。Alan Cooper、Larry Constantine 和Lucy Lockwood 所提倡的交互式設計方法很大程度上正是爲了這個目的。有很多人從事於需求工程的工作，他們也是朝這個方向在努力。他們說：“我們要將需求固定下來。爲了這 個目標，我們全力以赴。”但是，對於一個項目，你必須要判
斷它的需求是否天生就無法固定。如果有可能將需求固定，這樣的開銷是否值得？傳統方法和敏捷方法，哪一種的性價比更高？說實話，我對這兩者之間的權衡並沒有太多的發言權，因爲我幾乎都沒看到過有誰成功地將需求固定下來的。