敏捷開發(fā)和最小化功能組合的好處是能持續(xù)得到客戶反饋，快速迭代，防止無用程序的產(chǎn)生。但是隨著時間的推移，如果開發(fā)人員不注意，那些為早期客戶編 寫的程序會變得笨拙不堪，難以維護(hù)，無法擴(kuò)展。你最終會諷刺的得到和敏捷方法完全相反的結(jié)果。而且問題的嚴(yán)重程度會隨著公司的壯大呈指數(shù)級增長。合理的解決方案是什么？把產(chǎn)品“重構(gòu)重寫”。

對于處于快速變換的市場中的一個公司，這通常是走向滅亡的開始。

看似很合理

我剛好和一位朋友在加州的Palo Alto共進(jìn)午餐，他是一個科技公司的創(chuàng)始人，現(xiàn)在出任董事會主席。幾年前他聘請了一位職業(yè)經(jīng)理做CEO。我詢問他工作做的如何(“非常好，謝謝你的關(guān) 心，五年來，公司現(xiàn)在的市值已經(jīng)達(dá)到5千萬美元”)，但他卻想跟我談一個在他腦子里想了很久的問題。“隨著公司的壯大成長，我們對市場變化和客戶反饋的反 應(yīng)越來越遲鈍。雖然現(xiàn)在我們的營業(yè)收入看起來還不錯，但如果我們不能使公司的產(chǎn)品平臺跟上客戶需求的快速變化，一兩年內(nèi)我們就可能完蛋。我們的CEO沒有 技術(shù)背景，但他也為公司不能開發(fā)出他想要的一些新功能和平臺(Facebook,iPhone,Android等)而沮喪。在最近的一次董事會會議上，我 們主管技術(shù)的副總裁指出問題的根源在于‘我們的程序積累了太多的技術(shù)債務(wù)‘，程序?qū)嵲谑窃阃噶?，我們現(xiàn)在根本沒法處理。他告訴董事會，如果想在其上做我們 想要的修改，那只能重寫這個產(chǎn)品。”我的朋友補(bǔ)充道，“這聽起來很合理，所以CEO打算批準(zhǔn)這個計劃。”

舉槍自殺

“那么董事會在聽到這種魯莽的計劃后沒有做任何反應(yīng)嗎？”我問道。“沒有，”朋友回答道，憂郁的搖搖腦袋，“董事會成員都感覺這像個好主意。”

[[18846]]

經(jīng)過更詳細(xì)的詢問后，我了解到他們的已經(jīng)膨脹巨大的代碼庫中還保留著公司早期在拓荒階段為客戶開發(fā)的代碼遺跡。當(dāng)初針對客戶的產(chǎn)品技術(shù)設(shè)計對于公司當(dāng)前所面對的新平臺的擴(kuò)展任務(wù)來說并不是正確的設(shè)計。

我提醒我的這位朋友，我從來沒有做過技術(shù)管理，所以任何我給他的建議都是來自于經(jīng)歷過這種事情的他人。

引誘非技術(shù)出身的CEO的美妙海妖歌聲

CEO在其職業(yè)生涯中至少會遇到一次這樣的“重寫”問題。如果他是被請來替代技術(shù)創(chuàng)始CEO的，那這個決策似乎很好定 —— 只需要對比一下負(fù)責(zé)技術(shù)的副總裁提供的重寫(短期)進(jìn)度計劃和保留老代碼、增加新功能(長期)的進(jìn)度計劃就行了。而事實上，這是個愚蠢的決定。技術(shù)團(tuán)隊也 許會知道使用舊程序的困難和問題所在，但不會知道如果重寫代碼庫將會面對多少的困難和問題。

曾經(jīng)經(jīng)歷過重寫噩夢或理解程序的復(fù)雜性的CEO會知道，沒有最初的技術(shù)開發(fā)團(tuán)隊，重犯以前曾經(jīng)犯過的錯誤的幾率會非常的高。加之會引入以前不曾犯過的錯誤，根據(jù)墨菲法則，不受約束的樂觀主義會使1年期的重寫計劃變成數(shù)年。

我的觀點是，CEO和主管技術(shù)的副總裁混淆了因果?？蛻舨⒉灰笮碌某绦颉Ｋ麄円氖切碌墓δ芎推脚_ —— 在當(dāng)前。他們不太關(guān)心這 些功能是由一堆糊涂代碼、還是由外星飛船、還是由一個新產(chǎn)品提供的。當(dāng)你在代碼重寫的過程中，那些不癡迷于架構(gòu)血統(tǒng)純度的競爭對手會擴(kuò)展他們的功能、平 臺，拉攏客戶、增加市場份額。這種目前就增加這些功能、還是一兩年后再增加這些功能之間的區(qū)別代表著收入增長、還是被淘汰出局兩種境況之間的區(qū)別。

誰想要老的產(chǎn)品

也許這著手搞程序重寫最危險的副作用就是當(dāng)你對舊的程序宣告死亡時卻沒有可替代的產(chǎn)品存在。當(dāng)副總裁和CEO宣告公司將來要采用新的程序時，誰還會 去重視這充滿問題的舊程序呢？當(dāng)管理者說出“重寫”這個詞時，老的程序就死掉了。這后果就是，CEO沒有退路可走。如果技術(shù)副總裁的開發(fā)進(jìn)程最終是花了4 年時間，而不是設(shè)想的1年，那么在這幾年期間對于系統(tǒng)新功能的增加不會有任何的進(jìn)展。

這是一種預(yù)測的失敗

我認(rèn)為這看起來像是技術(shù)副總裁藍(lán)景設(shè)計上的失敗 —— 再加之沒有代碼重寫經(jīng)歷的CEO推波助瀾 —— 再經(jīng)過想不出具有建設(shè)性的方案的董事會們的攪和。

給朋友的建議？指出市場的快速變化和競爭性，指出這種動作會使公司致命。公司在前進(jìn)道路上的探索不應(yīng)該在時間對于市場至關(guān)重要的情況下、在客戶的需求快速轉(zhuǎn)換的情況下對代碼庫進(jìn)行重寫。重寫是在競爭周期比較長的市場條件下才可行。

我建議他應(yīng)該在董事會會議上把這些情況陳列清楚。要求CEO詳細(xì)列出什么時候需要什么樣的功能和平臺特征，用什么樣的手段對進(jìn)度計劃管理的風(fēng)險進(jìn)行 控制。弄清楚這種完全不同的技術(shù)方案是否真的可行。(是否可以只重構(gòu)目前需要追加新功能的部分模塊？在新的代碼庫上開發(fā)要求的新平臺系統(tǒng)？啟動一個獨立的 分支工作團(tuán)隊來開發(fā)新平臺？等等)

原文鏈接：http://steveblank.com/2011/01/25/startup-suicide-%E2%80%93-rewriting-the-code/

【編輯推薦】

1. 敏捷開發(fā)中的成效評估模型
2. Visual Studio 2010敏捷利劍：詳解Scrum
3. 淺談敏捷開發(fā)思想中的簡單***原則
4. 敏捷開發(fā)中的Scrum流程和術(shù)語
5. 敏捷開發(fā)中的架構(gòu)設(shè)計