[破門點滴]當敏捷遇到過程

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

破門

2007年5月6日于深圳

引言

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

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

敏捷宣言

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

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

• 個體和交流勝于過程和工具

• 工作軟件勝于綜合文檔

• 客戶協作勝于洽談協議

• 回應變革勝于照計劃行事”

敏捷方法實踐者

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

管理和交流

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

過程文化支持者們肯定會說，沒有細致的管理規則和作業指導書，無法降低軟件的開發成本，到哪里找那么多高手？軟件開發過程的產生就是要降低對“牛仔”的依賴。這個觀點我是接受的，在實踐敏捷方法的初期，團隊素質帶來的困難是最大的。不過矯枉過正是人們常犯的錯誤，當過程文化過渡依賴過程神話的時候，初期對“牛仔”的依賴是不見了，“銀彈”卻產生了。最終，還是要依靠團隊的某個超牛的“牛仔”來挽救項目危機。

我現實經歷的無數個項目，都是依靠我們團隊中的高手來渡過難關，俗稱“救火隊員”。他們才是我眼中的“銀彈”，哦，偶的神哪，你敢說他們是什么藍領？軟件項目依靠藍領和過程就夠了？

我們要認真地體味敏捷文化的精髓，那就是依靠團隊的交流，快速提升個人素質，抓住軟件項目管理的實質，那就是人和協作——我們的軟件開發團隊。

文檔和軟件

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

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

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

協調和控制

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

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

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

需求和進度

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

不是嗎？用戶的需求什么時候反饋的最多？就是你告訴用戶“我們開發完成了，系統可以開始使用了”的那一天。因此，敏捷文化和過程文化都強調對用戶需求的理解，同時也強調對需求的分析處理。不過由于雙方的核心觀點區別也就帶來了在具體處理方式上的不同。過程文化強調對需求的精確分析，強調詳細的計劃，因為這樣才能準確的貫徹過程體系，但是誰又能保障對需求的準確把握和精確分析呢？沒有人可以。

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

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

究竟誰更簡單？

用這個問題來作為本文的結束，其實朋友們心中早就有答案了。

這個問題實際上是在問：軟件系統開發簡單么？答案自然是——不簡單！

世界上沒有真正意義上簡單的東西。

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

無論你采用傳統開發過程還是敏捷開發方法，在軟件的道路上，大家依然任重道遠。

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