敏捷教練都該下課——Fred George訪談錄
記者：很多人為了編寫易變更的代碼，在采用敏捷時，拋棄許多習慣用法，由你的經驗出發，這樣做是否屬于重造輪子?
Fred George：這一行為實際是從傳統編程轉向面向對象編程。我目前的編程方式也有所不同，并且這個新方式與敏捷方式是兼容的。比如我曾經寫過大的Java應用程序，那里面平均一個方法只有不到3行的實際代碼，平均一個類使用不到25行的實際代碼。我也曾經用有1400個類的新系統來替換只有72個Java類的系統。這只是不同風格的編程方式罷了。
因此，如果你打算寫大的類和大的方法時，你會發現它們將很難被改變，這也往往會阻礙敏捷程序的進展，讓程序員感到沮喪，導致項目失敗。如果你寫小的類，每個類只做一件事情，并且不允許其他的類插手這一事情，那么程序修改起來就會變得更加容易。任何變動都不會觸及其他類，它們將在修改中完好如初。
記者：敏捷開發者可能這樣想，“工具不能讓你變得敏捷(盡管有所幫助)，管理體系也不能讓你變得敏捷(也會有所幫助)。敏捷的成功，植根于士氣高漲、充分授權的工作者身上”，是否體現了敏捷的實質?
Fred George：對，完全正確。敏捷并不是關于工具或者管理的，而是關于程序員在做他們認為正確的事情。我最近開始探討一些敏捷中必要的信任轉移的話題。傳統的思路是，客戶提出他們想要的，一大群BA抓住這些要求進行細化，隨后PM將其分成小任務，分配給各小組，小組長再進行進一步劃分。在此過程中，客戶和程序員之間經歷了多重分離。客戶的零散需求可以被程序員一一滿足，但是客戶本人卻始終不能與程序員溝通!
敏捷嘗試著在客戶與程序員之間建立持續的對話。在雙方精彩觀點雙向流動的過程中，信任關系也確立起來了。然后，正如您所說的“士氣高漲、充分授權”的程序員就開始理解問題的實質，并為客戶提供快速、持續的解決方案。
記者：如能得到準確的數據支持，敏捷實施能夠更好地開展下去，請問如何量化敏捷方法的實施?另外，敏捷實踐下的程序員工作指標又將如何衡量?
Fred George：我過去常探討關于如何衡量一名程序員的問題。很多衡量技巧并不是與客戶價值相關聯的，因而相當復雜。敏捷技巧中的結對編程，使這個問題變得更加復雜。再加上敏捷管理方法，往往會將最困難的問題分配給***的程序員，將最簡單的問題交給新手。這樣看來，什么衡量法才能奏效呢?
如果你確實想要知道一名程序員的價值，去問問跟他合作的其他人的意見吧。觀察伙伴對待他的態度。***的程序員就是那種人人都搶著跟他搭配的程序員，反之，人人避而遠之的那位就是你應該拋棄的對象了。誰承擔了難度***的卡片并且準時交付任務?誰是其他程序員尋求幫助的對象?通過細致的觀察，對一個***的程序員的判斷結果就是顯而易見了。盡管去問你的團隊吧!
記者：TDD被很多敏捷開發者奉為圭璧，但也有很多開發者避之唯恐不及，請問您如何看待之中的差別?此外，測試真的能保證敏捷的實施成功嗎?
Fred George：TDD是敏捷的奠基石，尤其對新的敏捷團隊來說，更是如此。如果有團隊避開了它，那可能是沒能真正理解它的價值。
寫測試代碼首先達到了以下幾個目標。***，它保證了你已做好寫代碼的準備了。如果你心中沒有計劃的話，很難寫出測試代碼來。反之，如果你寫不出測試代碼來，可能是你做的計劃還不夠。第二，***的代碼應該是那種設計出來為其他代碼所用的。而測試代碼則成為此代碼的***使用者，并且通常能帶來清晰的界面。第三，測試能告訴你什么時候該停止寫代碼。程序有時候很容易被寫過了頭，也就是說，為了解決可能的未知情景，很可能寫出來的代碼超出實際需求。這不僅會耗費過多時間，還會產生過多冗余代碼，也可能會帶來更多漏洞，這都是我們不希望看到的。***，一大堆自動形成的測試能告知你何時破壞了哪些原有代碼。
TDD有如此多的優點，為何仍有些團隊不愿意采用呢?通常來說，這種團隊可能是 “沒有足夠的時間”。殊不知，這種團隊會寫過多的代碼，產生更多難于發現的漏洞，生成繁復的界面。這種額外的代價是看不見的，相比之下，TDD顯然更經濟。
對于新團隊來說，他們通常對TDD持懷疑態度。但是當他們親眼看見我使用它在同等時間內寫出了比他們多三倍的代碼時，他們開始考慮，然后嘗試使用，***，基本再沒有拋棄過它。
TDD不能保證成功，但是缺少它卻往往能導致失敗。
記者：對于未來幾年敏捷開發的發展，您希望看到哪些新方向?有何建議?
Fred George：我提倡“無政府主義編程方式”。它支持敏捷方法的所有原則，但是提倡拋棄許多常見的操作實踐。我認為它是自然而然的、敏捷和精益方法的進化，雖然有些同事喜歡稱它為“后敏捷方式”。它也是Facebook所采用的模式，并取得了成功。簡單說來，這個方式就是要求企業為它們的系統設置一些目標，然后在無人監控的情況下，由程序員實施完成所有細節。錯誤當然不可避免，但是程序進展的奇妙節奏與當今網絡社會的需求相當吻合。他們要做的不是盡力避免錯誤，而是聚焦在快速發現并改正錯誤。真正以快速方式輕易解決錯誤，“快速的失敗”遠勝過“預防錯誤”。這當然對客戶與程序員之間的信任關系提出了更高的要求。
記者：對于精益等敏捷方法的流行，你持如何的看法呢?這是否是一種新的吸引眼球的管理風尚呢?
Fred George：我認為“精益”只不過是敏捷的另一個時髦術語。20世紀80年代，我讀碩士時就學習了“精益”(當然那時候它的名字還不是這個，而是“Just In Time”，簡稱JIT)。到了1990年代，我將它應用于敏捷項目的編程中。現在新專家們將這種方式稱為“精益”，但它其實還是我一直慣用的敏捷方式。
但是為老的思想貼上新的標簽還是很有價值的，它會因此獲得更多受眾，導致更多的人采用更好的方式。所以看到TDD被重新命名為DDD(領域驅動設計)或者BDD(商業驅動設計)，是件很有意思的事情，但無論如何，給新的轉變賦予新的名字還是有價值的。
記者：目前中國也出現了很多敏捷“教練”的角色，您對這一趨勢如何看待?
Fred George：我不信任敏捷“教練”這一角色，我覺得這種類比是不對的。體育領域中的教練輔導運動員如何表現更出色，但是他們自己不需要身體力行。教練本身都是年紀比較大、反應比較遲鈍的。
事實上，程序員們在目睹敏捷做法的過程中獲益。顧問需要和他們一起寫代碼、寫測試、部署系統。而許多敏捷教練僅僅告訴你做什么內容，然后坐在一邊看著，保證你確實在按照他的要求做。程序員們對此會持懷疑態度，一旦教練離開，他們就馬上放棄了這種實施。
敏捷顧問不同于體育中的教練，敏捷的推崇者應當坐下來與團隊一起工作，并且身體力行引導團隊。程序員不會“太老”或者“太遲鈍”;但對敏捷教練，會有“太懶，不愿動手”的說法。
原文鏈接：http://www.programmer.com.cn/6116/
【編輯推薦】
