[全程建模]響應張恂之《青潤的《中國軟體工程應用技術調查報告》》第四篇——迭代與交付周期

今天終於在張先生的頁面裡看到了一些關於響應的更新，我這裡也一篇一篇回複。這裡先談一下關於迭代與交付周期的問題。

說實話，在這篇響應文字中我仍然沒有看到任何實際項目的資料分析，而所有的內容都是張先生一廂情願之猜想，比如：關於我是否知道迭代，關於RUP還是因為我的全程建模造成交付時間延長的問題。

張先生的原文引用

 “

評青潤的《中國軟體工程技術應用調查報告》

[訪問量:1651]

作者：張恂 發表日期：2007 年 4 月

更新日期 2007-5-13 11:31:07

<首頁>  <上頁>  <下頁>  <末頁>   
第 1/10 頁 前言第 2/10 頁 胡扯一、XP 的普及度第 3/10 頁 胡扯二、RUP 在國內的適用性第 4/10 頁 胡扯三、中國有無軟體架構師第 5/10 頁 胡扯四、專案管理的普及度第 6/10 頁 胡扯五、白盒與黑箱測試第 7/10 頁 胡扯六、自動化的測試工具的普及度第 8/10 頁 胡扯七、XP 與自動化的測試第 9/10 頁 胡扯八、測試的認同度第 10/10 頁 胡扯九、迭代與構建頻率“關於 RUP 相關資料的評論：從軟體企業的開發過程和實踐來看，完全採用 RUP 的過程架構進行開發在中國國內是不太現實的，因為 RUP 過程本身的複雜度和管理上的重量是國內從大型企業到小型企業都無法承受的。”

—— 這段明顯是胡扯！

作為一名研究 RUP 的專家應當知道，RUP 是一個過程的架構（青潤已經提到了）。Framework 是什麼意思？既然是架構，就意味著豐儉隨意，既可以定製出 heavyweight RUP，也可以定製出 lightweight RUP（比如 Agile UP），不需要我引用國內外的著名文獻和案例了吧。RUP 架構和 RUP 過程是兩碼事。事實上，經過這些年的發展，統一過程（UP）已經發展成為一個過程方法的大家族。

作為一名 RUP 的實踐者，應當知道實施 RUP 通常都需要定製！而 RUP 中的絕大部分工件、步驟和角色都是可選（Optional）的，它們擺在那兒的目的只是作為工作指南、方法指南，需要用的時候就可以去參考。就像 MSDN Library，RUP 架構同時又是一個豐富的過程知識庫。沒有人會覺得 MSDN Library 很笨重，有人會質疑圖書館很笨重嗎？

RUP 怎麼去和 XP 比較？XP 是一個具體的過程，而且比較嚴格，有那麼 12 條軍規（老版本），如果你做不到那關鍵的幾項，項目就可能面臨重大的風險。RUP 是一個靈活的、抽象的架構，既可以這樣，也可以這樣，你怎麼去比？我們應該從 RUP 架構中定製出一個輕型的過程（執行個體）去和 XP 比，就像 Robert Martin（Bob 大叔）曾經調出的雞尾酒（過程） - dx 那樣。

所以，當青潤給出“RUP 過程本身的複雜度和管理上的重量”、“國內從大型企業到小型企業都無法承受”的論斷時，我給予了“胡扯”的評價。事實上，RUP 過程既可以是重型的（重型的並非不好，關鍵看項目的需要），也可以是輕型的、敏捷的。從青潤的介紹來看，他好像有過 RUP 方面的實施經驗，大概均是些失敗的重型 RUP 案子。他對 RUP 的這種片面理解和曲解，對於 RUP 的本質、精髓和 common sense 的無知，出乎我的意料。

在 4 月 7 日的回複中，青潤再次提到“應用 RUP 等重量級過程模型的確可以在一定程度上提高軟體品質”，說明在青潤的腦子裡：RUP = 重量。這裡再重申一遍：RUP 是個一個豐富而靈活的過程架構，不是一個重量級過程！

到今天，我差不多已做了 8 年的 UP/RUP 諮詢，這裡面既有國有企事業單位，大型上市公司，也有民營企業，外資企業；既有大型企業，也有中小企業；既有實施了 CMM/CMMI 的企業，也有採用了現代敏捷方法的企業。我參與諮詢、評審、服務過的項目從幾十萬、幾千萬到幾個億的都有，涉及的行業、項目、規模、地區類型廣泛，RUP 均能和這些項目很好地契合，前提是你需要認真地學習了 RUP，對 RUP 有正確的理解和認識。我的親身實踐經曆和所見所聞，說明了 RUP 具有廣泛的適用性，同時也符合國際主流軟體工程界對 RUP 的認識和一致看法。

推薦大家讀一讀我兩年前翻譯的 Craig Larman 的文章《RUP 實施之奪命七招》。

那麼，青潤在回複中提到：

關於這段文字是不是胡扯，我有一個個人看法需要說明。

我曾經親身參與過全程應用 RUP 的項目實施，在這個項目中感覺到了 uml 的好處，後來也主動的推動了 uml 在項目中的實施，在國內的工程項目中經曆了大到合約額接近兩千萬涉及到 11 個省級電信公司和電信集團公司的項目小到幾十人天的項目幾十個。

從我對國內軟體企業的瞭解和對客戶方耐心與耐性的認識，以及我應用 RUP 的經驗分析認為：應用 RUP 等重量級過程模型的確可以在一定程度上提高軟體品質，但是，要在開發週期上，尤其是第一次交付前的開發週期上比原始的開發過程相對有所延長（大概要延長 20% 到 30%），而這個時間的延長所帶來的第一次交付的成本也相應提高（對比時間周期的延長，這個提高也在 30% 左右，這兩個都是估計數字，請勿追究其準確性）。

由於曾經的國內軟體企業的混亂管理和信譽度低，使得目前的使用者更希望的模式是：合約簽署，軟體就交付，合約就付款。而這個時間的延長，會讓使用者感覺到他們始終沒有看到軟體產品，而產生相應的擔心和對開發商的不信任。幾乎所有的合約都會因為使用者方的要求而定下一個不合理的交付時間。

所以，基於這種分析，我認為我的這段看法不是胡扯，而是由我的項目經驗，乃至很多同行第一線的軟體開發人員的經驗積累而得到的，我相信只要是在工程軟體項目第一線參與過開發的技術人員基本上都會有同樣的觀點。

他遇到的究竟是什麼問題呢？為什麼會讓他得出有關 RUP 的錯誤結論呢？解釋如下：

首先，青潤聲明他曾經“親身參與過全程應用 RUP 的項目”，並且以他“應用 RUP 的經驗分析認為：應用 RUP 等重量級過程模型的確可以在一定程度上提高軟體品質 ...”。可見，青潤把 RUP 當作重量級過程模型（需要完成大量的步驟，提交大量的文檔）是確鑿無疑的。可問題在於，根據青潤的經驗，為什麼在應用了 RUP 之後，第一次交付期會延長 20-30%？

熟悉 RUP 的人知道，迭代、遞增式開發是 RUP 的一個基本特徵，而且對於固定交付期、固定預算（fixed time、fixed budget）的項目，RUP 也有很好的解決方案。在時間、成本固定的情況下，可以通過調整（縮減）交付內容以達到按時交付，這是現代軟體專案管理的一項基本常識。所以，如果正確運用了 RUP，系統的第一次交付期是無須延長的（fixed time）。所以，說什麼“因為應用了 RUP，導致交付期、成本都增加了 20-30%”，也是胡扯，這些項目的失敗（延誤、超支）恰恰是因為沒有正確地應用 RUP。

青潤還提到由於“這個時間的延長，會讓使用者感覺到他們始終沒有看到軟體產品”。為什麼應用了 RUP，使用者會“始終沒有看到軟體產品”？我猜，大概是因為青潤不知道 RUP 過程應該迭代，使用者“始終看不到軟體產品”的過程不是 RUP。

青潤把自己在實踐項目中遇到的挫折、對 RUP 的誤解和誤用當成了 RUP 的問題，這顯然是錯誤的。這些問題的造成，我想與青潤誤把 RUP 當作重量級過程、瀑布式過程有關，也可能與青潤自創的全程建模方法有關。在我看來，“全程”兩個字本身就帶有過度建模的傾向。青潤顯然也不知道，應用 RUP 過程，可以在規定的時間內交付產品，客戶不可能一直看不到軟體產品。提倡對複雜軟體系統進行 uml 可視化建模固然是 RUP 的一大特點，但 RUP 同時也非常強調通過迭代（編程實現和測試）儘早向使用者交付穩定的架構和產品。

過度建模不是 RUP，我們不能把凡是有 uml 建模的項目都叫做 RUP 項目。青潤有沒有膽量承認：20-30% 的成本和時間增加是不是由於你的全程建模造成的呢？

從以上討論和分析，我得出的結論是，青潤基本上不懂 RUP，或者說缺乏對 RUP 正確、全面的瞭解，所謂的“親身參與過全程應用 RUP 的項目”的說法是非常可疑的，這樣的項目或許只能叫做“全程建模”項目，而根本不能叫做 RUP 項目。這就是我對事實真相的看法。

”

評論青潤不懂得什麼是迭代！

這句話反而問得我不知道張先生對迭代的定義是什麼了，也許我不懂得張先生的迭代是什麼，但是我相信我很清楚迭代的意思。

我知道張先生這裡說到的是關於交付的問題，可是在國內的項目進展過程中，使用者往往要求的是直接見到全部可用的軟體版本，而不是一個一個的中間發布版本，這一點的偏差，我甚至有點懷疑張先生是否有親自參加過一個完整的國內軟體產品項目的開發經驗！！！

只要是參加過實際軟體需求、分析設計、編碼測試的人都知道，第一次交付意味著什麼。

而且在我的文字中多次表達過這樣的觀點：第一次交付的時間如果採用RUP的過程哪怕是裁減的過程也會比我們相對較為混亂或者不完全採用RUP的過程比較起來，要有所延誤，這個延誤的時間一般在三分之一左右。也就是說，10個月的項目大概要延期3個月才能進行第一次交付。

注意，這裡的交付必然是完整版本的，因為，在中國的環境下你不可能拿著一個不完整的版本交付給終端使用者，你如果敢這樣做，客戶就敢直接把你的軟體扔進垃圾箱！

當然，這個交付的版本在使用者那裡還是不能完全達到使用者要求的，還是需要修改，還是需要根據使用者使用後的感覺進行調整、最佳化、修改的。

 

青潤的交付延遲是因為他本人的全程建模的建議。

這一點，我可以告訴張先生，恰恰相反，正因為採用了我的全程建模的方法，才可以基本上讓我的交付時間與傳統的軟體開發時間十分接近，幾乎不需要延遲。

另外，聽過我的培訓的朋友都知道，我會針對不同項目的不同階段採用方法中的不同部分進行，並不會要求必須全部採用uml的表述方式來實現所有階段，因為畢竟我們的技術人員對uml的熟悉程度還並不是十分高，他們的技能還需要提高（至少我所帶過的兩隻應用了全程建模方法的團隊中的實際情況就是這樣的，這也是因為中國國內軟體企業的不穩定性造成的）。

另外，我們可以作這樣一個考慮，一個配合相對穩定和諧的團隊，他們可以省略相當多的文檔，而按照rup的建議，大量的文檔是不可缺失的，甚至不可省略的，因為每一步的交付都有它必須存在的文檔資料。在撰寫和修改這些文檔的過程中，就會產生相當多的人力和物力（注意，這裡我並不是說寫這些文檔是無用的，而是說這些文檔在一定的程度上可能會被人忽略，而由於團隊的穩定而帶來相應的節省），這難道不會造成交付的延期嗎？

而往往在實際的項目中，項目的交付是被指定的，我們可以因為一些原因而延期交付一些，比如04年初我們的一個軟體版本的交付就因為非典而獲益，得到了兩個多月的額外開發週期，這使得我們的項目團隊由死轉生，否則，我們當時的項目團隊是無論如何也不能在五月中旬交付電信集團所需要的軟體版本的。

結尾

我還是希望張先生拿出資料來，而不是僅僅在這裡做空對空的推理，或者空對資料的推理，這樣不是一個實際做事情的人應該說的話或者應該寫的文字。

我再次強調：一個做實際事情的人應該是拿資料來說話的！