[破門點(diǎn)滴]當(dāng)敏捷遇到過程

這份文檔也是醞釀了很久，想對(duì)自己長(zhǎng)久以來一直未能全面貫徹執(zhí)行一次敏捷開發(fā)項(xiàng)目的遺憾做個(gè)分析和小結(jié)，另外從自己親身的體會(huì)來對(duì)比一下敏捷開發(fā)與傳統(tǒng)開發(fā)過程的文化沖突，期望能對(duì)各位支持敏捷開發(fā)和支持傳統(tǒng)過程的同好有所幫助或提示。

破門

2007年5月6日于深圳

引言

自從2002年接觸XP（極限編程）以來本人一直自封為敏捷開發(fā)愛好者，也算是國(guó)內(nèi)第一批擁護(hù)和支持敏捷開發(fā)的程序員。不過一方面對(duì)于自己在敏捷開發(fā)的推廣方面無所作為感到慚愧，另一方面則對(duì)于一直未能在一個(gè)實(shí)際項(xiàng)目中徹底地貫徹一次敏捷開發(fā)實(shí)踐感到遺憾。去年又一次在合作型項(xiàng)目中親身經(jīng)歷敏捷開發(fā)與傳統(tǒng)過程的文化沖突，便有了認(rèn)真總結(jié)一下的想法，本文算是開個(gè)頭，也希望各位同行一起來探討一下。

讓我們還是先從“敏捷宣言”說起吧。

敏捷宣言

2001年2月11日到13日，在美國(guó)猶他州Wasatch山的滑雪圣地Snowbird的一幢大樓里，17位輕量級(jí)過程專家通過這次會(huì)議形成了敏捷軟件開發(fā)運(yùn)動(dòng)，其中包括了：極限編程（eXtreme Programming, XP）、Scrum、動(dòng)態(tài)系統(tǒng)開發(fā)方法（Dynamic Systems Development Method，DSDM）、自適應(yīng)軟件開發(fā)（Adaptive Software Development，ASD）、Crystal方法、特性驅(qū)動(dòng)方法（Feature-Driven Development，FDD）、實(shí)用程序設(shè)計(jì)等。會(huì)議的結(jié)果是17名與會(huì)者共同簽署并發(fā)布了“敏捷軟件開發(fā)宣言”（The Manifesto for Agile Software Development）,宣告：

“ 我們通過實(shí)踐尋找開發(fā)軟件的更好方法，并幫助其他人使用這些方法。通過這一工作我們得到以下結(jié)論：

• 個(gè)體和交流勝于過程和工具

• 工作軟件勝于綜合文檔

• 客戶協(xié)作勝于洽談協(xié)議

• 回應(yīng)變革勝于照計(jì)劃行事”

敏捷方法實(shí)踐者

敏捷宣言中明確提出了四個(gè)核心觀點(diǎn)，是否能夠正確地貫徹執(zhí)行這四個(gè)核心點(diǎn)決定了一個(gè)項(xiàng)目是否真正使用了敏捷方法——當(dāng)然也包括了XP。事實(shí)上，這也是我本人最支持的四個(gè)觀點(diǎn)，拋開對(duì)具體實(shí)踐規(guī)則的執(zhí)行程度——比如 結(jié)對(duì)編程（Pair Programming, PP）等XP實(shí)踐，我還是可以比較自豪地宣稱自己的確是一個(gè)敏捷方法實(shí)踐者 :)。

管理和交流

敏捷文化認(rèn)為傳統(tǒng)過程在編織一個(gè)美麗的神話，那就是存在所謂的“銀彈”——只要有良好的過程和管理，可以不用關(guān)注開發(fā)人員的技能提高。“我們需要軟件藍(lán)領(lǐng)！”自從我接觸到CMM這類的過程文化的時(shí)候，就認(rèn)為這個(gè)提法傷害著我作為程序員或者軟件工程師的自尊，這也是為何極限編程從一開始就引發(fā)我狂熱激情的根本原因。敏捷文化從根本就是程序員的文化，再次揭示了一個(gè)簡(jiǎn)單的卻被管理者們忽視的根本事實(shí)——軟件是人開發(fā)出來的！ 忽視了開發(fā)人員的素質(zhì)提升，用過程屏蔽開發(fā)團(tuán)隊(duì)之間的交流，如何獲得優(yōu)秀的軟件產(chǎn)品？

過程文化支持者們肯定會(huì)說，沒有細(xì)致的管理規(guī)則和作業(yè)指導(dǎo)書，無法降低軟件的開發(fā)成本，到哪里找那么多高手？軟件開發(fā)過程的產(chǎn)生就是要降低對(duì)“牛仔”的依賴。這個(gè)觀點(diǎn)我是接受的，在實(shí)踐敏捷方法的初期，團(tuán)隊(duì)素質(zhì)帶來的困難是最大的。不過矯枉過正是人們常犯的錯(cuò)誤，當(dāng)過程文化過渡依賴過程神話的時(shí)候，初期對(duì)“牛仔”的依賴是不見了，“銀彈”卻產(chǎn)生了。最終，還是要依靠團(tuán)隊(duì)的某個(gè)超牛的“牛仔”來挽救項(xiàng)目危機(jī)。

我現(xiàn)實(shí)經(jīng)歷的無數(shù)個(gè)項(xiàng)目，都是依靠我們團(tuán)隊(duì)中的高手來渡過難關(guān)，俗稱“救火隊(duì)員”。他們才是我眼中的“銀彈”，哦，偶的神哪，你敢說他們是什么藍(lán)領(lǐng)？軟件項(xiàng)目依靠藍(lán)領(lǐng)和過程就夠了？

我們要認(rèn)真地體味敏捷文化的精髓，那就是依靠團(tuán)隊(duì)的交流，快速提升個(gè)人素質(zhì)，抓住軟件項(xiàng)目管理的實(shí)質(zhì)，那就是人和協(xié)作——我們的軟件開發(fā)團(tuán)隊(duì)。

文檔和軟件

過程文化中最讓程序員們反感的就是鋪天蓋地的文檔了，與之對(duì)應(yīng)，敏捷文化中最受爭(zhēng)議的部分自然也是對(duì)于文檔的大刀闊斧的裁減了。程序員對(duì)文檔的厭惡幾乎是與生俱來的本能反應(yīng)，簡(jiǎn)單的說，程序員應(yīng)該就是寫程序的，如果每天要花大量的時(shí)間在那些看起來沒有人真正關(guān)注的文檔上，簡(jiǎn)直就是無聊，或者直白地說有點(diǎn)“不務(wù)正業(yè)”了！

但是過程文化強(qiáng)調(diào)文檔的原因也不是無依據(jù)的，以往程序“牛仔”們留下的一堆看不懂的代碼，以及那些幾乎無法維護(hù)的系統(tǒng)，是文檔顯得無比重要的根本原因了。我本人也親身體驗(yàn)了無數(shù)次重新翻寫整個(gè)系統(tǒng)的痛苦經(jīng)歷，用程序員的話講，“讓我改他的代碼，那還不如重寫”。

所以，就這個(gè)問題上，敏捷文化其實(shí)是支持文檔的，不過所謂“矯枉必須過正”。過程文化帶來的過度文檔頑疾要解決，就必須用刺激性的辦法。敏捷文化強(qiáng)調(diào)最小化文檔，或者干脆不要文檔（好的測(cè)試和代碼就是最好的文檔），讓團(tuán)隊(duì)把目標(biāo)重心重新放到正確的地方——那就是可以工作的軟件系統(tǒng)上來。

協(xié)調(diào)和控制

過程文化對(duì)于客戶價(jià)值的概括幾乎完全依賴于前期分析，那份可以改上一千遍的《需求分析說明書》。我見過最猛的一個(gè)項(xiàng)目是花了整整一年的時(shí)間，將《需求分析說明書》出到11.0版本，然后還沒有正式開始編碼。

反之，我自己引入敏捷文化最成功的一個(gè)項(xiàng)目則是在一個(gè)1kw級(jí)別上軟件系統(tǒng)開發(fā)過程中，先提交了運(yùn)行版本后才提交給客戶了一個(gè)《需求分析說明書》0.8版本。事實(shí)上，兩個(gè)項(xiàng)目都是在客戶現(xiàn)場(chǎng)開發(fā)的。不過在后者的啟動(dòng)階段，我花了3個(gè)月的時(shí)間向用戶和監(jiān)理公司介紹極限編程XP的概念和應(yīng)用，最終成功說服了客戶，放棄了監(jiān)理公司關(guān)于項(xiàng)目采用CMM2管理體系的建議。而最終用戶對(duì)項(xiàng)目參與程度也是我經(jīng)歷的所有項(xiàng)目中最高的，我把這點(diǎn)看作這個(gè)項(xiàng)目最重要的推進(jìn)因素。

而剛過去的半年，我們則遭遇了歷史上最糟糕的項(xiàng)目管理模式，我被迫采用了商務(wù)談判的手段來嘗試解決紛爭(zhēng)，幾乎就讓項(xiàng)目徹底沉入深淵。最終，還是派出“救火隊(duì)員”依賴我們的經(jīng)驗(yàn)和痛苦的加班加點(diǎn)來緩解問題。這樣的項(xiàng)目，無論對(duì)任何人來講，都是絕對(duì)的痛苦！事實(shí)上，只要我們的合作伙伴公司與客戶的交流更深入一點(diǎn)，完全可以避免類似的項(xiàng)目風(fēng)險(xiǎn)。每次都對(duì)客戶的需求簡(jiǎn)單理解，對(duì)客戶要求的進(jìn)度簡(jiǎn)單承諾，累積下來，自然失去客戶信任，項(xiàng)目自然無法成功。

需求和進(jìn)度

上面的話題已經(jīng)談到關(guān)于客戶需求的問題，關(guān)于需求，敏捷文化的核心觀點(diǎn)用XP的實(shí)踐精神來說就是——擁抱變革。而在這方面過程文化遭遇的難題可以用一句俗語(yǔ)概括——“計(jì)劃沒有變化快”！

不是嗎？用戶的需求什么時(shí)候反饋的最多？就是你告訴用戶“我們開發(fā)完成了，系統(tǒng)可以開始使用了”的那一天。因此，敏捷文化和過程文化都強(qiáng)調(diào)對(duì)用戶需求的理解，同時(shí)也強(qiáng)調(diào)對(duì)需求的分析處理。不過由于雙方的核心觀點(diǎn)區(qū)別也就帶來了在具體處理方式上的不同。過程文化強(qiáng)調(diào)對(duì)需求的精確分析，強(qiáng)調(diào)詳細(xì)的計(jì)劃，因?yàn)檫@樣才能準(zhǔn)確的貫徹過程體系，但是誰又能保障對(duì)需求的準(zhǔn)確把握和精確分析呢？沒有人可以。

因此，敏捷文化一開始就承認(rèn)，客戶的需求是不斷變化的，雙方的有效互動(dòng)可以降低需求變化帶來的風(fēng)險(xiǎn)。讓客戶參與進(jìn)來，只關(guān)注已經(jīng)確認(rèn)無誤的特性，不過度設(shè)計(jì)，不考慮那些明天可能會(huì)拋棄的東西（You aren’t gonna need it！，YAGNI）。

通過小發(fā)布加快用戶需求反饋的進(jìn)度，同時(shí)每次發(fā)布可工作軟件系統(tǒng)都包括可以真正使用的用戶特性，也就是包含有用戶價(jià)值，這是敏捷文化中發(fā)布系統(tǒng)區(qū)別于快速原型的重要一點(diǎn)。夸張點(diǎn)說，從第一發(fā)布開始，用戶已經(jīng)不是“一無所有”了，他們已經(jīng)看到和擁有了可以工作的系統(tǒng)！這解釋了為什么引入敏捷文化后最終用戶往往更具有耐心和信任度。

究竟誰更簡(jiǎn)單？

用這個(gè)問題來作為本文的結(jié)束，其實(shí)朋友們心中早就有答案了。

這個(gè)問題實(shí)際上是在問：軟件系統(tǒng)開發(fā)簡(jiǎn)單么？答案自然是——不簡(jiǎn)單！

世界上沒有真正意義上簡(jiǎn)單的東西。

因此，敏捷開發(fā)方法和過程開發(fā)方法都是不簡(jiǎn)單的。敏捷文化誕生過程中有無數(shù)的關(guān)于“沒有銀彈”的文章和討論。所以，我在這里還是想告訴一些朋友們，無論你支持何種文化，都不要用簡(jiǎn)單來作為支持自己觀點(diǎn)的論據(jù)。

無論你采用傳統(tǒng)開發(fā)過程還是敏捷開發(fā)方法，在軟件的道路上，大家依然任重道遠(yuǎn)。

讓我們支持敏捷宣言的核心精神——“通過實(shí)踐尋找開發(fā)軟件的更好方法”！