目前，項目由于性能問題，仍然沒有驗收，維護時間日益增長，目前仍然有30萬左右的尾款沒有收到；更為嚴重的是，目前項目開發商正在投標的另一快速消費品行業著名客戶的合作伙伴與該客戶有很大的重疊，因此，對于潛在項目的招標造成一定的影響。
三、 經驗與教訓
從項目規模中可以看出，該項目的時間還是比較緊張的；另外一方面，項目交付是在合同規定日期之前完成，而且通過了所有的功能測試。從一定意義上的講，項目的開發是取得了一定的成功的。
3.1 經驗
在項目開發前，項目開發商已經通過其它項目，實施了以XP為代表的敏捷軟件開發方法的部分最佳實踐，并取得了很大的成功。因此，在該項目的執行過程中，項目開發商繼續采用了XP的部分實踐以及其它軟件開發方法中的推薦做法[1][2]：
- 每日晨會：在項目實施過程中，每天早晨開發小組都要參加一個持續15分鐘左右的會議，由項目經理主持，聽取每個成員的進度，并根據進展情況，對于進度和資源進行調整。
由于會議是每天進行的，PM很容易從中獲得真實的項目情況－"掀開地毯下面的東西"[4]，從而對風險有了較好的控制。 - 交叉審核：項目組在最初的時候原本是想采取"成對編程"的實踐，但是沒有獲得物理和管理上的支持，因此，只能采取交叉審核的方式進行。
- 需求獲�。河蒔M和一名對于原有系統較熟悉的開發人員進行需求獲取和SRS (Software Requirement Specification) 的撰寫。技術經理和其它開發人員進行需求的審核。
- 分析與設計：由一名開發人員進行系統框架的設計，其它人員進行審核；在系統框架設計進行過程中，由于系統去除訂單處理以外的其它部分比較獨立，因此，將其它模塊分配給開發人員，而將核心部分交與技術經理進行分析與設計。開發人員在每個迭代周期內，都會在分析與設計做完后，每2人一組進行審核。
- 編碼：每天下班前，2人一組，對對方的代碼進行Review，發現問題及時解決。代碼Review的時候，語法與規則的檢查，通過Check Style的工具進行；開發人員將審查的重點放在功能實現與性能優化等方面。
- 測試：在需求文檔形成以后，2個測試人員分布編寫分配模塊的Test Case；而在具體測試的時候，兩人交叉測試對方的模塊和更新文檔。
- 測試先行：測試在軟件開發中的重要作用已經得到了越來越多的重視，但是，由于習慣勢力的影響和對于"Test-Driven Development"的不熟悉，開發小組并沒有實施完全意義上的測試先行。
對于系統框架的核心類設計過程中，項目小組采取了TDD的方式進行開發。在后續的系統開發中，每個開發人員在進行開發前，首先要完成一個功能測試 ( Function Test ) 列表，將要完成的Use Case中的主要業務邏輯以及關聯邏輯都要羅列出來，在提交測試人員進行集成測試之前，開發人員需要保證完成Function List中的所有選項。
在每個開發人員的模塊完成并通過個人的功能測試后，測試人員進行集成測試，同時編寫測試腳本，并通過自動測試工具 (Rational Robot) 進行記錄。每天下班之前，測試人員會啟動測試工具，進行回歸測試。在第二天向PM和技術經理提交測試報告并將Bug提交至Bug Trace系統（Rational Clear Quest），由PM進行Bug的分發。每個開發人員需要在下一個迭代周期完成前，修正前一個迭代內分配的Bug。 - 持續集成：在測試先行的基礎上，開發一組平均每天都會進行已經完成模塊與以后系統的集成。集成由專門的人員，在開發人員將已經通過功能測試的源碼Check in到源碼控制系統 (ClearCase) 中以后進行，在部署應用結束以后，通知測試人員進行集成測試。
- 小步發布：項目有專門的測試與發布服務器，每天都有集成的系統在運行和接受測試。由于沒有現場客戶，對于已經發布的系統，是由"客戶領域專家"（這個項目是由Business Development人員來充當這個角色）來進行審查的。他對于系統的意見和發現的問題，在經過PM和技術經理審核后，進入ClearQuest，分配給開發人員進行修改。
由于項目一開始就注意組織內部以及與客戶的溝通和交流，同時采用了很多敏捷軟件開發過程的實踐，項目如期交付使用。
3.2 教訓
項目在交付以后，最初的兩個訂貨季節沒有出現功能與性能上的問題。但是，由于合同中有數據遷移的條款，在項目交付2月后，項目開發商將舊應用系統中的數據導入新系統以后，在下一個大的訂貨季節中，持續的出現性能上的問題。在代碼修改和硬件環境提高以后，系統性能目前獲得了一定的改善。
從項目驗收日期的日益推遲中，我們可以看出，該項目還是有很多地方做的不夠，例如：
- 系統二次開發效應："第二個系統效應"是Brooks在《人月神話》中提出的一個普遍的問題，一般而言，第二個系統會傾向于過分設計[4]。
對于這個項目而言，沒有犯這個錯誤，卻發生了另外一種情況：舊系統中，對于訂單信息以及產品信息的展示，不管是多是少（系統頁面最多顯示上千條記錄），都是在一個頁面中顯示。這對于沒有明顯的層次結構，直接在Script中調用數據庫記錄的PHP來說，性能還是可以接受的。但是，新系統的設計中客戶提出考慮系統用戶習慣一致性的問題，就照搬了舊系統的頁面設計；同時，在架構設計上，對于這種頁面顯示大量數據的情況，也沒有給予充分的考慮，為后來的性能問題，埋下了伏筆。
教訓一：沒有考慮新平臺的影響，照搬舊系統的功能以及頁面設計。 - 非功能性需求：項目合同中主要描述的是系統功能性的需求，而沒有非功能性需求的規定；同時，在需求獲取解決，也沒有明確的了解系統的性能指標等非功能性需求。主要原因在于項目開發商之前沒有大規模業務系統開發的經驗，對于非功能性需求沒有足夠的重視；同時，在測試階段，也沒有對于系統負載和性能做過測試。
因此，在項目交付以后，由于舊系統數據遷移后，數據量有了很大的增長，同時，在秋季的定購高峰中，有大量的并發用戶訪問，出現了下列問題：- 數據庫死鎖；
- 大量數據計算與顯示頁面速度很慢，頁面要經過5～10分鐘才能夠完全顯示；
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/
