不一樣的敏捷開發實踐
項目背景
2006年年初，一位客戶聯系我的公司，希望能夠為其企業創建一個企業網站項目。根據客戶的簡單描述，這個項目本質上就是一個內容管理系統，并集成了論壇、FTP和電子郵件等功能，因此不算復雜。按照以往的經驗估計，最多一個月就可以完成這個簡單的項目。
需求分析
大體而言，該項目的主要功能包括新聞和文章發布、產品發布以及后臺的用戶管理和權限設置，還有外圍的論壇、FTP和電子郵件系統。應該是一個很簡單的Web應用程序，通常情況下寫一個簡單的概要性文檔，就可以安排開發人員進行實際編碼了。
但這個客戶是國有企業，所以簡單的概要性文檔是顯然不可能通過領導審核的。為此，我和客戶一起，將網站所有的功能整理成了列表，并標記出各個功能之間的關聯關系。功能和內在邏輯關系整理完畢后，客戶還和設計師一起將所有網頁的布局也畫成了圖表。最終，需求文檔多達50頁。
在整理需求文檔的過程中，我發現項目并不像客戶最開始描述的那樣簡單。因為客戶所在的企業有一百多個部門、車間，所以客戶要求按照部門和車間對網站的用戶進行管理。同時，權限管理是層層授權的。簡單來說就是上級部門可以，也只能給直接下級部門授權，而不能越級授權。獲得授權的用戶可以創建一個產品子類別。然后給子類別指定一個下級部門的管理員，然后再由該下級部門的管理員來創建更深層次的子類別或管理產品信息。
從表面上看，這種設計沒什么問題。但在實際操作中，這種設計要求對每一個部門的相關員工都進行培訓，讓其掌握系統的使用，增大了項目的應用成本。同時，由于繁瑣的授權模式，最終負責產品管理的人員反倒沒有充分的權力使用系統。
所以我對這些不合理的地方提出了自己的看法，希望采取更靈活更實用的設計方案。不幸的是，我沒能說服客戶接受我的意見。畢竟這是個金額較大的項目，客戶方負責人堅持己見，我也無可奈何。
雖然按照需求文檔，我把項目開發時間定為兩個月，但事實證明兩個月的時限過于樂觀。
原型系統開發和初步評審
文檔準備完畢后，我安排了開發人員和設計師進行此項目。而開發人員不到20天，就拿出了一個原型系統，雖然細節上還有不少需要完善的地方，但主要功能都已經具備了。原型系統開發完畢后，我們和客戶一起進行了初步評審。評審結果雙方都比較滿意，所以準備在余下來的時間中完善細節。
但我發現這個原型系統中權限部分實用性非常差，因此再次提出了修改意見。不過客戶顯然對于我這種“懷疑”他的做法很不愉快，最后用一句“這是我們行業特點決定的”來結束了討論。雖然我早已知道決定項目成敗的，“人”才是關鍵因素，但迫于客戶的壓力，我再次選擇了妥協。
許多開發者認為只要原型系統通過評審，整個項目就不會遇到大問題了。但實際情況有時候非常復雜。因為原型系統通常只是幾個人坐在一起簡單展示或者試用一下，和實際使用該系統的環境有著巨大區別。所以許多問題是根本不可能在原型展示階段暴露出來的。
做好后的系統卻徹底失敗
從需求文檔準備好到實際開發工作進行還不到一個半月，整個系統就非常完善了。期間由于客戶方負責人出差，客戶企業的其他聯系人要么沒有決策權，要么說不知道此事（國企通病），所以我們只有在沒有獲得進一步反饋意見的情況下繼續按照需求文檔進行開發。不過完善后的系統倒是“很順利”的通過了客戶的檢查，開始部署到服務器上進行試運行。
但就像火山一樣，系統中存在的問題超過臨界點就會爆發。短短一周以后，上門為客戶提供培訓的技術支持人員就帶回來了一份詳細的修改意見文檔和反饋意見。而我僅僅看了這些文檔幾分鐘，就明白這個項目將要進行重大修改，否則不可能投入實際應用。
修改意見文檔的內容主要集中在權限系統上，具體而言就是權限系統的設計太復雜、太死板。首先，層層授權太過繁瑣，有時候改變產品類別的名字也要找到上級管理員才行。其次，由于系統限定不能給一個管理人員分配多級產品分類的權限，所以必須每個產品分類層次都要設置不同的管理帳號。
客戶企業有10多個大類，100多個小類，上千種型號的產品。但實際上根本沒有那么多人愿意負責管理工作，最后就成了一個人用幾個帳號，當初設想的嚴格權限管理形同虛設。而且由于使用太麻煩，實際的管理工作逐漸向少部分人集中，導致這些人怨聲載道，開始對系統提出各種各樣的負面看法。
在這種情況下，我公司和客戶企業領導進行了多次會議，初步決定兩條腿走路。一方面用最短的時間修改現有系統，保證客戶企業新產品發布時，網站能夠正式推出。另一方面重新做一套新系統來替換現有系統。
重新開始，該如何抉擇？
對于軟件公司來說，一個項目如果重做，損失和影響是非常大的。因為不但其他的開發計劃要被打亂，而且公司投入的成本也要成倍增加。這個時候，如何降低損失就是最重要的事情了。好在和和客戶經過進一步協商后，客戶承擔了一半的損失。而完全重做也改為只重做權限系統部分。
根據這個目標，我首先安排開發人員對系統進行修改。砍掉了權限系統（實際上就是這一塊導致了整個系統的重做），并按照其他項目的成功經驗，對多處功能進行了修改。修改完成后的系統雖然缺乏權限管理，但其他功能經過客戶企業員工使用都反映良好。而且這樣簡化后的系統大部分功能都可以直接搬到重新開發的新系統中，最大程度的降低了成本。
同時，在我的強烈要求下，客戶企業決定安排專人負責此項目。這樣我才能保證新系統的開發不至于重蹈覆轍。#p#
引入敏捷開發
其實我公司不是第一次嘗試敏捷開發，只是這個項目由于前期做了“細致”的文檔，所以沒有按照慣用的快速迭代模式進行開發。但新系統在排除了“人”的障礙后，采用敏捷開發的條件已經很充分了。
User Story
我首先和客戶方派來的代表一起模擬了權限系統的運作方式，最終得到了一個和最初設計功能近似，但具備充分實用性的權限系統設計方案。
模擬過程類似角色扮演游戲。我先在許多張卡片上寫好各個部門及員工的名字、職位信息。然后我和客戶代表一起，手持不同的卡片扮演不同的角色。然后將不同角色之間的交互過程記錄下來。這個過程就是敏捷開發中倡導的“User Story”，雖然簡單，但是非常有效。不但能夠真正理清各個角色之間的關系，還能找出實際運用時的不足之處。
在我和客戶代表的模擬過程中，開發人員則迅速創建一個符合我們演示過程的權限系統來驗證權限系統的可行性。當然，如此高要求的快速開發還需要借助公司從以往項目中積累的大量可復用代碼以及高水平的開發人員。
快速決策和充分溝通
由于在客戶企業，一個很簡單的決策可能也要層層批復。所以經過我公司的艱苦努力，客戶企業最終決定由一位領導來專門負責該項目的決策。所以大部分決策可以在較短的時間內獲得反饋意見。
而客戶代表在整個新系統開發期間，幾乎一半時間都在我公司上班。這也保證了我公司和客戶之間的充分溝通，并且當面溝通也比通過電話更容易說服客戶接受我的意見。
實際上，不管采用何種開發模式，充分的溝通都是保障項目成功的關鍵因素之一。溝通越充分、雙方協作程度越高，項目就會進行得越順利，成功的幾率也更大。而在敏捷開發中，由于是通過小步前進的快速迭代來逐步逼近項目最終目標，所以溝通就更為重要。否則一次迭代完成后，卻得不到及時和正確的反饋，那么項目也無法進行下去。
有限的單元測試
持續集成雖然非常有用，但是對于這個項目卻不太適合。不過為了保證子系統的修改不至于影響到全局系統，我仍然編寫了一些重要的單元測試。
準確來說，這幾十個單元測試都不太符合“單元測試”的標準。因為每個測試實際上都要用到子系統的許多接口。但在項目時間壓力下，這些測試既能很大程度上保證子系統的修改不至于對全局系統產生太大的破壞作用，又不用花太多時間去維護。所以是一個折衷的選擇。
不過這里我認為這里做得很好的地方就是單元測試是由我來編寫的，并不是開發人員自己編寫的，所以更能夠反映我和客戶的意圖。同時測試重點也更偏重業務領域，而不是程序行為。
版本控制系統
雖然敏捷開發沒有對版本控制系統做要求，但使用版本控制系統可以很明顯的提高開發效率。例如我和客戶代表驗證一個想法后，發現這個設想并不好，那么通過版本控制系統，開發人員幾分鐘就可以退回到先前的代碼或者切換到其他階段的代碼。
而且版本控制系統在需求變動激烈的項目中，更是充當了一種保險機制。無意中用錯誤版本的代碼覆蓋工作拷貝的事情可以得到徹底解決。
靈活運用敏捷開發
實際上，我從來沒有采用過完整的敏捷開發。因為我認為既然敏捷開發本身強調的就是應對變化，那么敏捷開發過程本身也應該是可剪裁的。像結對編程、持續集成這些，對公司本身和開發人員的要求相對來說都更高。如果要一一達標，確實不太可能。所以有選擇性的實行敏捷開發，是我最常用的方式。
例如對于User Story，除非是客戶充分配合，否則是難以實施的。這個時候應該在前期將工作做細致，盡可能明確大部分需求。然后以最快的速度做出原型系統后，和客戶進行溝通獲取反饋意見。
同時，即便采用User Story，對于較復雜的系統，也應該深入客戶企業，了解客戶企業員工的工作流程。因為有時候客戶方負責項目的人士很可能會按照自己的想法渲染實際的工作流程或者環境，這對項目的中后期是非常不利的。
在國內，一個項目要做得順利，項目負責人還要懂得“做人”。和客戶方負責人、聯系人保持良好的關系是非常非常重要的，否則他們一句話可能就會讓項目的開發成本增加不少。這些東西的內容遠遠超過了技術領域，但卻是我們不得不面對的問題。
遲來的成功
新系統花了一個月就開發完成了，因為除了權限系統是完全重做的外，其他部分都大量利用了已有系統的結構和代碼。雖然在模擬權限系統時花了不少時間，但這樣模擬的結果保證整個系統具有充分的可用性。
這個項目是我公司迄今為止用FleaPHP應用程序開發框架開發的最復雜的應用程序。不算FleaPHP自身在內，應用程序的核心有100多個類，6700多行代碼。從與客戶意向性洽談到最后完成，足足花了六個月時間，期間開發實際上只進行了三個月不到，而且還是做了兩次。其他時間全花在溝通、協調、開會上了（有時候不得不抱怨一下國有企業僵化的機制）。
如果我一開始能夠耐心說服客戶接受我的意見，那么整個項目的開發過程可能就會順利得多。或者說我能在項目初審發現問題后通過其他渠道爭取支持，那么也可以避免后來的二次開發。不得不說我在如何“做人”方面還有許多需要學習的東西。
【編輯推薦】
