敏捷軟體過程的侷限性

曲俊生 (junshengqu@yahoo.com.cn)

本文以一個PRM專案為例， 探討了目前國內軟體開發企業在軟體開發過程中，尤其是企業應用系統專案開發中，面臨的問題以及如何利用敏捷軟體開發方法的解決方案。

一、 專案與公司背景

該專案是一個PRM (Partner Relationship Management)系統，為世界著名的快速消費品品牌在中國大陸的合作伙伴提供訂單管理以及其它輔助功能。該系統原來是基於PHP實現的，已經執行將近2年的時間，但是由於系統功能問題，需要對系統進行重新開發，新的系統基於J2EE框架實現。

專案預期情況如下：

專案開始時間： 2002年7月1日 預期交付時間： 2002年9月1日 專案金額： 70萬RMB

專案開發商是亞洲領先的電子商務解決方案供應商，在J2EE架構的專案執行方面有豐富的經驗，結合RUP與Web Software Engineering形成了自己的一套電子商務專案實施方法論，並在多個專案中成功進行實施。

二、 專案實施情況

專案由於客戶預算等原因，原有的軟、硬體系統繼續使用，同時，應用系統平臺也採用開源專案。

專案部署時的系統情況如下：

硬體：   作業系統： Solaris 主頻： 400M 記憶體： 1G 硬碟： 20G 應用平臺：   Web伺服器： Apache 1.3.21 應用伺服器： Tomcat 4.0.6 資料庫伺服器： Oracle 8.1.7

專案人員配置與專案規模：

專案團隊   專案經理： 1 技術經理： 1（兼） 客戶經理： 1 開發人員： 4 測試人員： 2 HTML人員： 1（兼） 專案規模   Use Case： 32 程式碼行數： 65000 JSP頁面： 198

專案真實執行情況：

開始日期： 2002/7/1 交付日期： 2002/9/2 驗收日期： 2003/5/8 維護時間： 230 人小時 目前專案盈利： 20000

目前，專案由於效能問題，仍然沒有驗收，維護時間日益增長，目前仍然有30萬左右的尾款沒有收到；更為嚴重的是，目前專案開發商正在投標的另一快速消費品行業著名客戶的合作伙伴與該客戶有很大的重疊，因此，對於潛在專案的招標造成一定的影響。

三、 經驗與教訓

從專案規模中可以看出，該專案的時間還是比較緊張的；另外一方面，專案交付是在合同規定日期之前完成，而且通過了所有的功能測試。從一定意義上的講，專案的開發是取得了一定的成功的。

3.1 經驗

在專案開發前，專案開發商已經通過其它專案，實施了以XP為代表的敏捷軟體開發方法的部分最佳實踐，並取得了很大的成功。因此，在該專案的執行過程中，專案開發商繼續採用了XP的部分實踐以及其它軟體開發方法中的推薦做法[1][2]：

• 每日晨會：在專案實施過程中，每天早晨開發小組都要參加一個持續15分鐘左右的會議，由專案經理主持，聽取每個成員的進度，並根據進展情況，對於進度和資源進行調整。
  
  由於會議是每天進行的，PM很容易從中獲得真實的專案情況－"掀開地毯下面的東西"[4]，從而對風險有了較好的控制。
• 交叉稽核：專案組在最初的時候原本是想採取"成對程式設計"的實踐，但是沒有獲得物理和管理上的支援，因此，只能採取交叉稽核的方式進行。
  1. 需求獲取：由PM和一名對於原有系統較熟悉的開發人員進行需求獲取和SRS (Software Requirement Specification) 的撰寫。技術經理和其它開發人員進行需求的稽核。
  2. 分析與設計：由一名開發人員進行系統框架的設計，其它人員進行稽核；在系統框架設計進行過程中，由於系統去除訂單處理以外的其它部分比較獨立，因此，將其它模組分配給開發人員，而將核心部分交與技術經理進行分析與設計。開發人員在每個迭代週期內，都會在分析與設計做完後，每2人一組進行稽核。
  3. 編碼：每天下班前，2人一組，對對方的程式碼進行Review，發現問題及時解決。程式碼Review的時候，語法與規則的檢查，通過Check Style的工具進行；開發人員將審查的重點放在功能實現與效能優化等方面。
  4. 測試：在需求文件形成以後，2個測試人員分佈編寫分配模組的Test Case；而在具體測試的時候，兩人交叉測試對方的模組和更新文件。
  在系統開發Verification的各個階段，都有Check List，詳細的資訊請檢視參考文獻[3]。
• 測試先行：測試在軟體開發中的重要作用已經得到了越來越多的重視，但是，由於習慣勢力的影響和對於"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來說，效能還是可以接受的。但是，新系統的設計中客戶提出考慮系統使用者習慣一致性的問題，就照搬了舊系統的頁面設計；同時，在架構設計上，對於這種頁面顯示大量資料的情況，也沒有給予充分的考慮，為後來的效能問題，埋下了伏筆。
  
  教訓一：沒有考慮新平臺的影響，照搬舊系統的功能以及頁面設計。
• 非功能性需求：專案合同中主要描述的是系統功能性的需求，而沒有非功能性需求的規定；同時，在需求獲取解決，也沒有明確的瞭解系統的效能指標等非功能性需求。主要原因在於專案開發商之前沒有大規模業務系統開發的經驗，對於非功能性需求沒有足夠的重視；同時，在測試階段，也沒有對於系統負載和效能做過測試。
  
  因此，在專案交付以後，由於舊系統資料遷移後，資料量有了很大的增長，同時，在秋季的定購高峰中，有大量的併發使用者訪問，出現了下列問題：
  1. 資料庫死鎖；
  2. 大量資料計算與顯示頁面速度很慢，頁面要經過5～10分鐘才能夠完全顯示；
  上述兩種情況在少量負載的單元測試和整合測試中是不可能出現的。
  
  教訓二：對於企業應用系統，尤其是業務系統，沒有切實注意負載、效能等非功能性需求。
• 效率與設計：在J2EE中，已經成功的運用了很多設計模式的思想，為系統的開發提供了一個很好框架。但是，在專案的架構設計中，除了考慮可維護性、可複用性等問題以外，還要考慮程式碼執行效率的問題[5]。
  
  隨著計算機硬體技術的發展，"莫爾定律"被一再的驗證，系統硬體的價格逐漸降低。對於很多使用J2EE架構或者JAVA技術的專案來說，解決效能與效率問題的解決方案就是增加硬體方面的投入。而實際上，軟體開發過程中優劣演算法之間的差距是靠硬體的投入平衡不了的。
  
  該專案在系統維護期間，對程式碼進行走查，修改了很多對於效能有影響的語句；同時，在框架設計中，尤其是資料庫操作方法，利用Cache原理，從一定程度上解決了效能的問題。
  
  教訓三：系統框架設計只考慮物件導向和可維護性，沒有在完美的設計與高效率的程式碼之間做出權衡。
• 資料庫設計：JAVA是純粹的面嚮物件語言，利用J2EE開發的專案，也強調首先進行OOAD的分析，首先有物件，然後再有資料庫的設計。DBA在專案中的作用，已經遠遠沒有傳統的結構性程式設計中重要。而實際情況卻是遠非如此：大部分的業務系統，如果要對系統的效能做出優化，對資料庫層或者SQL語句進行優化是關鍵的步驟之一。
  
  對於這個PRM系統，在資料庫的設計上並沒有經過DBA的審查就開始進行開發；而在效能問題出現以後，客戶增加了512M的記憶體，也沒有請求DBA對Oracle的引數做相應的調整，造成了很大的資源浪費。
  
  在專案維護過程中，依靠DBA的幫助，開發商對於資料庫系統引數、索引、儲存過程和SQL語句都做了一定的調整，這對於系統效能的提高起了很大的作用。
  
  教訓四：在物件導向的軟體系統構建中，忽視資料庫設計以及DBA的重要作用。
• 客戶參與：在傳統的軟體開發過程中，一般情況下，客戶在簽訂合同後，專案交付前是很少有機會看到系統的，這樣就造成了系統交付後，客戶抱怨很多的情況；而在以XP為代表的敏捷軟體開發方法中，強化了客戶在軟體開發中的重要作用，XP更是提出了"現場客戶"的實踐，將客戶作為專案小組的一員，客戶對於專案的釋出計劃、內容和優先順序等方面有絕對的控制權。
  
  對於這個PRM專案，由於客戶的原因，不可能採取"現場客戶"的實踐，但是，開發商的BD對於該客戶十分熟悉，完全可以作為客戶代表參與到專案中來，因此，開發商將客戶經理作為專案組的一員。
  
  實際情況是：開發過程中，客戶經理由於業務擴充的原因，並沒有在專案上分配多少時間進行審查；而客戶在交付前也沒有花費很多的時間研究系統，也沒有提交很多的反饋報告。在系統交付出現效能等問題後，客戶經理與開發人員一起對於系統需求進行審查，提出了很多有參考性的意見。如果從一開始，就強化"現場客戶"的最佳實踐，就可以很早發現問題。
  
  教訓五：客戶或者客戶經理對於專案的參與力度不夠。

四、 結論

在基於J2EE的企業應用專案開發中，要注意以下問題：

• 權衡系統設計與效能指標，關注非功能性需求；
• 採取敏捷軟體開發過程，關注人（客戶和開發人員）在專案實施中的重要作用，如果可以的話，聯合實施XP的所有實踐；

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/14639675/viewspace-408748/，如需轉載，請註明出處，否則將追究法律責任。