敏捷專家的衰落——實施敏捷必須面面俱到？

最近國外敏捷社群頗不寧靜，你方唱罷我登場。

Joel和Jeff的podcast系列，先是惹著了Kent Beck，然後又惹著了Robert Martin。

關於Scrum的是是非非，討論組裡仍是爭論不休，InfoQ這篇新聞：採用敏捷需要面面俱到，歸納了一些討論組裡的動向，在英文站上還有30多個跟帖。

而更熱鬧的是，Jurgen Appelo在部落格裡對Ron Jeffries，Robert Martin，James Shore，Alistair Cockburn以及Martin Fowler點名，以辛辣反諷的語氣，批駁了他們的觀點。

Jurgen在文中說：

現在，那些敏捷專家告訴我，為了實施Scrum，或是XP，或是其他任何形式的敏捷開發，你都必須要做重構。你沒得選。必須這麼幹。他們說每個人都需要單元測試, 還說因為Scrum忽略了一些重要（但是困難）的敏捷工程實踐，讓事情變得更遭，還說如果你不是每天至少有一次構建整合的話你就不是敏捷……這些日子以來，他們甚至聲稱agile就是按照X、Y、Z這樣的實踐做事。搞極限程式設計的人開玩笑說，把XP裡面那些起作用的技術實踐去掉就成了Scrum。

……

我們已經完全實施了Scrum，但是XP實踐還去之甚遠。我們就低人一等麼？敏捷專家們說，離開了XP實踐的Scrum，會帶來很多技術債，使生產力降低，造成專案失敗。每次我看到這種話，我都覺得哪裡有問題。我覺得我該說點什麼，但不知道怎麼說。

直到今天……

今天，我們所有的專案經理都認為，引入Scrum對我們的專案成功起到了很大幫助。我聽做開發的說，（因為有Scrum），他們終於至少有機會遠離技術債了。客戶也說我們現在的專案質量很高……

這些裡面都見不到XP。怎麼弄的？

為什麼每個敏捷專家，還有他們的大叔（譯註，這裡指的是Robert Martin，他被人稱作Uncle Bob），都在警告大家不要單純的實施Scrum而不用XP實踐，但是我們的組織卻正好按照那種做法做的很成功？為了理解所發生的一切，我們得幹一些敏捷 專家們這些年都沒幹過的事情……那就是思考，還有回溯敏捷的根源。

接下來，Jurgen先是用複雜性理論（complexity theory）中的“混沌邊界（The edge of chaos）”來支援他的觀點。

他提到，在從左到右，從“有序”到“混沌”的這樣一條譜系中，當系統位於居中的“複雜”區域內，它的適應性、創造能力等等都是最強的。對於那些一直在用有 序、結構化的方式生產軟體的公司，敏捷會把他們從左邊（即有序）向右推，推向混沌的方向，但不會進入混沌。而如果你沒有用一些恰到好處的實踐——包括技術 實踐——敏捷方法就會把你推的太遠，直至混沌。這可能就是為什麼大多數敏捷專家都在說“Scrum in not enough”。但是，大多陣列織並不是處在有序的位置。對於這種情況，敏捷方法會把他們從右往左推，推向有序的方向。這時，倘若強加一些實踐於其上，就 會跟官僚政治一樣，危害整個系統。所以一切都要依具體環境而定。

緊接著，他又談到了博弈理論中的“進化穩定策略（Evolutionary stable strategy）”。他說：

除了適應性以外，在ESS中沒有任何單個屬性是必須存在的。的確，生物體的眼和腳給他們帶來了好處，但是植物和細菌照樣過得很好。很多公司通過市場和廣告 獲益，但也有些公司根本不考慮這個。很多軟體開發專案用了自動化測試、現場客戶、結對程式設計。但也有很多專案沒用這些東西，也做的很好，我謝謝你們，謝謝你 們八輩祖宗。

……

博弈理論告訴我們，從來不會有一個最佳策略可以適用於一個環境中的所有因素……認為某些敏捷實踐必須得用，這種幼稚（或是自大）就跟認為人類基因是世界上最佳的DNA鏈一樣。

此文一出，我們自然可以料想得到社群中的反應，Ron Jeffies在部落格回帖中說：

重構這裡的關鍵點是邏輯，Jurgen，不是命令。我不會發號施令。我也不在乎你用不用重構。但是，如果你真的要用Scrum，那麼：

• 你必須從第一個Sprint起開始交付軟體；
• 你必須在隨後的每一個Sprint中交付軟體；
• 如果你在第一個Sprint裡交付軟體，那麼當時所作出的設計就會比較脆弱，因為你沒時間把一切都弄好。
• 因為這樣一個設計沒法從頭到尾承載起專案，你就不得不改進設計；

改善既有程式碼的設計，即為重構之名。

你必須做重構——改善設計，不是因為我這樣說你才做，而是因為除了改進程式碼以外你別無他法，要麼就等著專案嗝屁。不過像你這麼強悍，專案還嗝屁不了。

然後Jurgen Appelo又回應說：

重構跟單元測試或其他XP實踐一樣，都是一種投資。人們這樣做，是為了*在將來*獲取收益。當然，隨著時間推移，脆弱的設計會變的不穩定。但最本質的問題在於，投資*何時*能夠得到回報？

舉個例子：如果我做的東西只會用一個月，而構建就要花三週的時間，那我為啥要做重構？……

另一個例子：如果我知道競爭對手在用Scrum的同時做重構，我可能就會打算不用重構。這樣就可以更快把產品做完。沒錯，程式碼設計會比較糟糕，但*我*會得到合同！！他們就得不到！！*有了*新合同以後，等交付完第一期產品，我就有錢再花時間做重構了。

這只是兩個例子，我還能給出更多，隨便什麼都行，不管是重構、單元測試，還是結對程式設計。

你說的是“你必須這樣，你必須那樣”，可你忘了這是個複雜的世界。

沒有什麼是必須的。

在xp yahoogroup中，George Dinwiddie說：

我只是想知道他們是怎麼辦到不用重構而遠離技術債的。

Jonathon Golden說：

有件事情讓我感到很驚訝，他一直在說他們做的有多棒有多棒，但最後他還是說“嘿，我們要用一些XP實踐了”。他肯定有些事情瞞著我們沒說。他們組織裡遇到 了一些問題，如果早點引入XP實踐的話那些問題可能就不會出現了。現在他就不得不說，“怎麼引入這些血淋淋的XP實踐”。我把他這種做法叫做扯淡。

論戰在Jurgen Appelo的部落格上繼續，Jason Gorman說：

你引用了複雜性理論，但是把程式碼中無可逃避的熵卻視而不見。
程式碼會變老。跟人一樣。我們會新陳代謝。我們從外界攝取有用的東西，維持我們的身體所需，但與之同時我們也會攝取進一些無用的東西。

寫程式碼跟這個很類似。軟體成長的過程中，有益或是有害的東西都會加進來。程式碼腐爛的速度是很驚人的——尤其是在第一個小發布之前。

Ron的意思是，如果你想保持生產效率——尤其是想在開發幾周以後繼續保持——那就必須與不斷增長的熵作鬥爭。

Jurgen回應說：

Jason，我當然瞭解熵。因為有熵，所以我們需要常常打掃房間。但是Ron的意思是，你*必須*打掃房間，他甚至還制定了一個頻率：每個Sprint！

我打賭，不是這樣的。

這要看房子。還有家庭。還有環境。

Ilja Preuß也反對Jurgen的說法，他說道：

Jurgen，有個有責任心的廚子會時時保證廚房整潔的。這不需要看環境，這只是幹好工作的必要條件。

我剛開始學精密製造的時候，學到的最重要的一點就是每天下午清理工作環境。這一點沒得商量，不需要看環境。不然你就沒法幹好工作。

Jurgen繼續回應：

我覺得你的類比有問題。

這也許適用於西歐國家的專業廚師，但在其他國家，其他地方就不一定適用了。你也許從沒看過中國飯館的廚房……

Ron Jeffries稍後針對Jurgen的話又寫了一篇部落格，叫做為什麼必須做重構？在部落格中他說道：

對於成功的迭代專案而言，重構是一條自然法則。下面用Scrum的名詞來解釋一下原因：

1. Scrum 需要在每個Sprint結束的時候交付“完成”的軟體。團隊來決定完成的含義，但基本上都表示著系統可以執行，經過了測試、整合，可以交付給客戶。
2. 在傳統的Scrum中，Sprint的長度為一個月，現在一般時間更短。所以團隊就得在專案剛開始的兩週或者一個月內交付完成的軟體。
3. 軟體來自於產品負責人的backlog。它必須由特徵組成。要正確的做到Scrum，我們不能叫做基礎架構之類的東西，我們要交付特徵。
4. 所以，在開始幾個Sprint中，團隊就沒時間把最終產品所需要的整個穩定的基礎架構做好。我們只能做好一小部分而已。
5. 但是，整個產品肯定需要一個大型的，效能強勁的，更加穩定的架構。
6. 所以專案中的架構必須要改，不是因為我這樣說你才這樣做，而是因為剛一開始我們沒有，而到最後我們得需要。
7. 要修改基礎架構的方法不多。我們可以每個Sprint重寫一次，或者是對它做改進。每次都重寫的話效率太低。所以我們必須做改進。軟體的改進就是重構。這就是重構。

在我們學到怎麼改進設計之前，Scrum有可能給我們帶來好處，但是我們肯定發揮不了最大的能力，時間慢慢過去，我們還會面臨速度減緩的危險。

這場論戰牽涉範圍甚眾，這個話題就先報導到這裡，回見。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/14639675/viewspace-594432/，如需轉載，請註明出處，否則將追究法律責任。