一次有益的敏捷嘗試

發布: 2007-4-22 19:48 | 作者: 張恂 | 來源: IT之源 | 查看: 86次 | 進入軟件測試論壇討論

PRM 項目所反映的問題和現象是非常典型的程序員高手和篤信編程技巧大于一切的觀察家們會指著PRM 案例說這明顯是開發人員的水平不夠頁面處理太笨數據庫設計太次……要是我早就搞定了可是這果真是技術問題嗎?

俊生：

你好!

當我第一次在DW 上讀到這篇文章漫談企業應用項目的軟件開發過程一個PRM 系統實施的經驗與教訓，就發現它是一篇非常難得的好文章。國內類似這樣的軟件工程案例分析太少了，很多人沒有時間寫或不愿與他人分享家中的寶貝，何況這篇文章還是專門針對XP RUP 實踐的。不管結果如何，原文篇幅不長，卻有很多值得我們借鑒學習的地方。除了你總結的經驗和教訓之外，我還看出了一些另外的問題，有一些新的聯想于是寫下來與你交流探討。

印象最深刻的是，原文中的PRM 系統雖然準時交付使用但是由于后來出現性能問題，數據庫死鎖，大數據量處理和顯示慢等，過了8 個月仍然沒有通過客戶的驗收，不但有幾十萬尾款沒有收到，而且還影響了其它項目的投標。我個人認為這個項目從商務角度看是比較失敗的，至少曾一度讓開發商和客戶都陷于非常被動。這些麻煩究竟是什么原因造成的，有沒有可能事先避免呢？我想PRM 項目出現問題可能有這幾方面原因，在你概括的基礎上：

1 受XP 影響對需求工程的重視不夠

由于進度很緊，2 個月完成的進度計劃可能一開始就定得不太合理，團隊成員包括客戶在內都把注意力放在了按時完成功能上，卻忽視了關鍵的非功能需求。（原文教訓2）

在需求獲取階段沒有明確地了解系統的性能指標等非功能需求，從而導致架構設計對于多并發用戶和大數據量的處理存在缺陷。這可能是PRM 項目所犯的根本性錯誤。正是由于需求不完備，沒有及時發現遺漏了關鍵的隱含的性能需求，才直接導致了項目后期的被動。XP 用非正式的寫在索引卡片上的用戶故事來定義需求，像并發用戶數頁面一次顯示的數據量之類的約束，往往很難通過這些簡單的用戶故事被發現，只有細致認真全面的需求分析才有可能捕獲這些潛在的需求。不過由于XP有現場客戶，因而能在一定程度上減少遺漏需求的風險。雖然PRM 項目采用了用例來管理需求，在嚴格性上比XP 前進了一步，但缺點在于只重視了實現功能需求，忽視了提取非功能需求。

完善的需求工程非常強調捕獲非功能需求，而且該項目的客戶參與度不夠，缺少正式規范的需求和架構評審過程，導致沒有能及時發現遺漏的需求，給成功帶來了很大的隱患。這一事例再次向我們強調了全面需求分析的重要性。

2 沒有實施有效的風險管理，做到真正的迭代式開發盡早排除架構性能上的風險。
迭代不僅僅意味把整個系統開發任務逐一分解，按階段分步驟來實現。如果迭代的含義僅僅停留在這個層面上，那么提出用迭代演進式過程取代瀑布型開發模型也就毫無意義。因為我們做任何工作本來就是要一周一周一天一天一塊一塊地來完成，不管瀑布型還是演進式皆如此。

迭代真正的主要目的其實是為了通過加速客戶反饋，顯著地消除開發風險。這就要求每次迭代結束必須有一個可運行可演示的系統。這時的系統可能功能上還不完整，僅僅是一個骨架，但它總是系統開發中最難最重要，也就是風險最大的部分。所以真正的迭代式開發能夠在項目早期就允許客戶對可運行的系統進行驗證，從而使項目的風險減到最小。開發工作也應該根據風險的大小來安排，通過迭代及時調整優先級，風險越大的任務越應該及早設計實現測試和反饋。
PRM 項目雖然模仿了XP 迭代周期，甚至每天都開例會，這有點像Scrum。保證了初始版本的準時交付，在保證PRM 前期進度方面，迭代還是有功勞的，卻仍然沒有能夠防止較大風險的發生。交付系統幾個月后才逐漸暴露出性能和架構上的質量問題，可以說這并沒有達到XP 或RUP 迭代開發的最終目的。

在項目初期沒有把合同中已經提到的數據遷移視為一個關鍵風險是一大失誤。我想如果嚴格按照RUP 風險驅動的迭代演進式開發進行管理，在半年多的時間里應該還是有機會盡早發現這個問題的。

原文提到該項目在系統維護期間對代碼進行走查，修改了很多對于性能有影響的語句。需要提醒的是這種方式可以消除局部的缺陷，但卻很難發現全局性的架構問題，對于軟件架構頭痛醫頭腳痛醫腳的做法往往是行不通的。曾經有朋友告訴我這樣一個真實的故事，在進度高壓下有一位架構師成功開發了1 個J2EE 應用系統。正當他為此興高采烈時，客戶卻告訴他原來的性能要求需要修改平均響應時間應該從15ms 減少為5ms 這時他才發現，原來自己辛辛苦苦花了3 個月時間設計出來的架構對于這樣一個性能指標的調整完全不能適用，需要推倒重來。此時他的心情是何等沮喪可想而知。

PRM 項目的性能出現問題是在系統交付幾個月之后，如果事先沒有經過充分的架構設計和評審，誰知道以后還會發生什么情況？誰又能保證今后不會出現類似的或新的問題？

3 合同缺陷

作為使用者代表的客戶方IT 負責人，負責銷售和簽訂合同的開發商客戶經理以及開發商內部負責系統實現的項目經理/架構師這三方之間能否對合同的范圍和技術可行性進行充分的溝通，達成清醒的共識，對項目的最終成敗起到至關重要的影響。

從原文分析看與客戶簽訂的這份合同明顯存在著缺陷，它對需求的理解是片面的，主要描述的是系統功能性的需求，而沒有非功能性需求的規定。對進度計劃也過于樂觀，事后看即使用去了10 個月，開發商也付出了不懈的努力，客戶仍不愿意驗收和支付尾款，顯然項目的實際進度已經遠遠超出了當初的估計，既然如此，何必當初。一開始 PRM 團隊其實并沒有必要心急火燎地趕在2 個月內交付系統，如果事先能多做些客戶的工作，早期客戶一般都對開發商充滿著期盼和信任，把合同進度和條款定得寬松一些，把數據遷移和系統驗收/ 測試以及適當的返工時間和必要的補償措施也考慮在內，給雙方留有一定的余地，把基礎打好，做得更扎實一些，結果就可能要樂觀得多。

對此我們可能有些一廂情愿，為了應對激烈競爭，贏得商機，開發商往往對項目的前景作出過于樂觀的估計，而客戶也往往對軟件開發的復雜性估計不足，甚至憑借買方市場優勢，對開發商要求過于苛刻，這些因素迫使開發商哪怕不行也要縮短工期，壓低報價，硬著頭皮上，結果必然是兩敗俱傷。然而這不意味著在此種情況下規范的軟件工程就無能為力了，沒有必要做出正確的項目估算和計劃，如果開發商有了充足的理由和數據支持，至少可以據理力爭。在知情的情況下，有意而為之，防范于未然，比因超時超量的意外而驚慌失措、亡羊補牢要好得多。

4 對客戶的啟發引導反饋和協作不夠

原文提到在開發過程中客戶經理由于業務拓展的原因，并沒有在項目上分配多少時間進行審查，而客戶在交付前也沒有花費很多的時間研究系統，也沒有提交很多的反饋報告（原文教訓5）。

我把它更多地視為一種項目管理制度的缺憾，客戶以及作為現場客戶替代者的開發商客戶經理沒有依據迭代計劃及時提供反饋，這也是導致PRM 項目失敗的重要原因�，F階段國內項目完全實施現場客戶的難度較大，因而我們不能指望通過現場客戶來提高項目的成功率，而實際上很多成功的項目也沒有或者沒有必要做到現場客戶。其實XP 的反饋環不一定要全部通過現場客戶來實現，它只是達到明確需求強化反饋的一種形式。在不同條件下，可以有不同的變通處理方式。對于PRM 項目而言，我以為在迭代周期中引入由客戶參加的正式架構評審，使關鍵問題能夠被盡早發現可能比現場客戶起到的作用更大。

人們愛說客戶是上帝，從事軟件工程千萬不能抱著這樣的觀念其實是一種欺騙，因為上帝是無所不能、無所不知的，而客戶絕不是萬能的。他/她們經常會犯錯誤，很多內幕細節客戶不了解、不知情也不可能比你更懂軟件。所以我們不能等著客戶來主動告訴我們應該如何去做，抑或對客戶百依百順�？蛻粢庖娬諉稳盏慕Y果只能是自吞苦果。

軟件工程更應該提倡客戶是朋友，是合作伙伴的正確觀念。只有通過規范的軟件工程、過程和正確的軟件項目管理措施，在客戶和開發商之間建立起良好的溝通橋梁和協作機制，雙方將心比心、互相理解、引導和啟發才能增加共贏取勝的機會。我還想起了D. Dikel 在軟件架構組織原則與模式拙譯（機械工業出版社2002 年8 月第1 版）中總結的架構組織--反模式。不幸的是PRM 項目出現的情況好象正好符合電話鈴未響和遺漏的部分兩個反模式。由于電話鈴一直未響，在開發過程中客戶溝通不暢，很可能是因為客戶放心地認為開發商的客戶經理非常了解業務，所以不愿親自操心項目組，也就沒有預見到在數據遷移后的大用戶量情況下可能出現的問題，并提前采取措施。

項目組知道了明確的用戶需求合同規定的內容，卻遺漏了為了向客戶提供有價值的東西--合同之外隱蔽的需求所應該做的事情，調整架構數據庫優化等等。系統雖然及時交付了，卻由于缺少一些客戶必需的關鍵功能特性，保證大數據量處理和顯示的良好性能無法被客戶所接受。結果用戶得到的是不完整的解決方案，它帶來的負面影響足以超過任何已完成的新功能的價值。不滿意的客戶不愿繼續支付�；叵肫饋�，這些遺漏的細節卻似乎又都是顯而意見的。
如何避免重蹈覆轍，書中建議需求調研的覆蓋面很重要，規范的東西可以確保沒有東西被遺漏，采取措施讓客戶參與協作，了解你的受益人，架構評審和客戶互動等模式也有助于預防……

5 開發過程不盡完善

PRM 項目靈活采用了許多敏捷做法，每日晨會，交叉審核，持續集成，測試先行，小步發布因而在項目進度的控制上的確取得了局部成功，項目前期進度得到了保證，按時交付了系統，然而質量內容和速度永遠是個矛盾。由于風險管理沒有到位，PRM 項目看似滿足了合同的進度要求，卻在項目后期遇到麻煩。

客戶對系統的質量并不滿意，項目結案的總體進度實質上是遠遠拖后了。我們在實施軟件過程改進的過程中往往容易機械地理解一些軟件過程的規范和教科書。單純地學習某些具體個別的做法卻忘卻了軟件工程的基本原則，沒有從根源上明白XP、RUP為什么要這樣做。
原文提到主要原因在于項目開發商之前沒有大規模業務系統開發的經驗，對于非功能性需求沒有足夠的重視，同時在測試階段也沒有對于系統負載和性能做過測試。PRM 項目做到了單元測試、集成測試，但還缺少系統驗收測試。至少在合同中對此沒有明確規定。

我覺得可能不能簡單地把問題歸咎于開發經驗不足。與其說開發團隊沒有大規模業務系統開發經驗，事實說明大家的技術技能還是很不錯的，出現的一些問題后來也逐步得到了糾正，還不如說組織的開發過程不盡完善，缺乏對實施規范、軟件工程需求架構評審必要性和重要性的強烈意識，被XP 的個別做法迷惑了。我猜想，完善過程和制度很有可能可以避免類似情況的發生，如果通過迭代交付使系統盡早上線，進行數據遷移方面的試驗，既然合同上已經明確提到了這個需求，并通過嚴格的需求和架構設計評審對付頁面顯示和并發用戶訪問的性能問題就將更加從容。

6 OOAD 設計模式與DB 的關系對教訓3 4 的補充

軟件OOAD 與數據庫設計優化并行不悖，兩種技術解決的是不同領域的問題。在項目管理中應該并重，無論軟件開發采用的方法是傳統結構化還是OOAD。數據庫和DBA 的效能對于企業應用系統來說始終都是關鍵因素，對系統性能和質量有著重要的影響。有些人認為RUP、XP 對數據庫介紹的篇幅不多，好像對于軟件開發方法論、數據庫技術就不重要了。這完全是一種誤解。另外，值得指出的是，面向對象設計同樣可以產出高性能的軟件，兩者并不矛盾。不要被設計模式所迷惑，應該避免在錯誤的場合運用模式。

7 CASE 工具的局限性
PRM 項目采用了不少先進的CASE 工具，例如Rational ClearCase、ClearQuest、Robot 來進行代碼缺陷和測試等。管理應用水平在國內是屬于領先的，自動化工具對于提高效率、保證進度必不可少，但工具的作用也是有限的。工具是為人服務的，它們不能替代正確完善的軟件項目管理和開發方法論。PRM 案例恰好驗證了即使再好的工具，銀彈也無法彌補挽救，在做事方式方法上存在的缺陷歸根結蒂還是人的因素。

總而言之，PRM 項目給我們的教訓是很深刻的。我想它遇到麻煩的主要原因在于前期需求分析架構設計不足，加上系統測試存在漏洞，迭代式開發也沒有起到應有的客戶反饋效果，結果造成雖然PRM 系統被及時交付使用，但是一些關鍵需求被進度順利完成的假象掩蓋了，導致項目后期才暴露出缺陷，給開發商造成了很大被動。這正是我們通常不愿看到的，最壞結果可謂經典案例。

以上事例反映了XP 應用存在的一些典型陷阱，不能因為XP 強調敏捷極限，就省略軟件過程的一些關鍵環節和必要步驟。這方面RUP 能給我們較大的幫助。我們不能只學習XP、RUP、CMM的表面知識，更應該注重掌握軟件工程的基本原則和軟件過程的核心設計思想。

該案例還提醒我們，不能把項目的成功完全寄希望于事后重構，除非你藝高人膽大，針對架構打補丁實在是很不劃算。很不聰明的做法會讓組織和個人冒很大的風險。一旦架構瓦解，寧可與客戶一道多花些精力做好前期工作，尤其要掌握全面需求分析風險分析和控制的方法，做到善于捕捉潛在的需求和問題。