項目接近尾聲，需求也逐漸收斂。面對需求變化頻繁、迭代版本周期較短的客觀情況，傳統模式已不能在此生搬硬套。雖現有的開發過程談不上正規敏捷，也算接近小步快跑的節奏。下面分‘需求開發&代碼開發、版本控制、版本發布、增量升級’幾個部分，記錄一些體會，歡迎指正：
  （1）需求溝通&代碼開發：
        1、針對有可以復用的現有模塊時，和開發人員溝通主體思路，由開發人員著手開發，開發人員在開發期間與需求人員充分溝通，碰到疑問及時澄清、解決。
        2、針對沒有可復用的模塊且涉及較復雜的業務流程時，需求人員畫原型圖（緊急情況手繪草畫），開發人員按原型圖或草圖著手開發。
        3、需求人員記錄開發過程中和開發人員、客戶溝通的需求變化點。
        4、功能開發完成、客戶驗收后，及時補充到《需求規格說明書》。
  （2）版本控制：
        1、代碼提交前做比較再合入版本庫（嚴禁合入非自己修改的文件）。
        2、合入代碼需填寫修改信息，新版本開發只填寫修改信息，優化修改還需在BUG管理系統自提單，以做BUG管理。
        3、在試商用、商用環境上升級，必須由升級接口人閘口執行并得到負責人同意。非特殊情況，嚴禁開發人員在試商用、商用環境上自行修改代碼（修改后要到開發環境上做代碼同步提交）。
  （3）版本發布：
        1、需求人員輸出《需求規格說明書》，用于研發指導、市場支持。
        2、測試人員做全量回歸測試，輸出《測試用例》、《測試報告》，用于測試維護、說明測試結論。
        3、開發組長將正式版本打包、封存。輸出《版本安裝手冊》，用于版本安裝過程的指導。
        4、需求、測試人員整理《數據配置手冊》，用于版本安裝的初始化配置。  
  （4）增量升級：
        1、升級列表：需求人員牽頭、測試人員參與，整理本輪版本升級的功能列表（含新功能、上一輪的遺留問題）。
        2、代碼提交（本地開發環境）：開發組長約定當天所有開發人員提交代碼的時間點。
        3、升級包制作（本地測試環境）：當天所有代碼提交SVN后，升級包制作人（開發組長或測試組長）制作升級包T01。
         制作說明：
             1.升級前關注開發過程中模塊的關聯影響，如：表結構變動涉及第三方工具的代碼調整，表結構變動涉及平臺內關聯模塊的代碼調整。 
             2.升級前，開發人員提交代碼的時間必須由開發組長統一安排，如：什么時間點之前必須完成代碼提交并給組長回執確認、哪些代碼還沒開發完此輪版本不做提交，避免測試人員制作升級包后，開發人員又要提交代碼、導致測試人員又要重新制作升級包。
             3.集成開發環境中記錄代碼的提交時間，測試人員用文件比較工具按照時間段（如早上8：00～下午18：00）將有變動的代碼文件搜索出來，形成此輪的升級文件。
             4.數據庫客戶端開發工具，針對測試庫和開發庫進行數據庫腳本（表結構、視圖、存儲過程、觸發器等）比較、自動生成升級腳本。
             5.將升級文件、升級腳本打包成增量升級包，在本地測試環境（連接遠程數據庫）上做升級包驗證。
        4、升級包驗證（本地測試環境）：測試人員將升級包T01在本地測試環境做部署、測試，迭代3輪（發現的問題知悉開發人員修改代碼重新提交、測試人員重新從SVN上取代碼制作升級包在本地測試環境驗證），發布升級包。
        5、升級包部署（遠程試商用環境）：將發布的升級包部署到試商用環境。
        6、升級包驗證（遠程試商用環境）：需求人員牽頭、測試人員參與，在試商用環境做結對測試（發現的問題知悉開發人員修改代碼重新提交、測試人員重新從SVN上取代碼制作升級包在本地測試環境驗證）。
        7、升級包部署（遠程商用環境）：試商用環境升級、驗證通過后，同步升級到商用環境。
        8、升級包驗證（遠程商用環境）：需求人員牽頭、測試人員參與，在商用環境做結對測試。