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