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