當前版本：3.2 draft 2005-4 本文舊版曾發表于《Dr.Dobb's軟件研發》2003年8月創刊號
一、過程成熟度與多樣性
近年來軟件過程改進在國內日益得到重視，一度出現了許多組織紛紛開展 SW-CMM 商業評估的熱潮。迄今全國已有近兩百家軟件企業通過了 SW-CMM、CMMI 各級評估（1 2 3）。這一方面說明原本作為美國軍方標準（如今已成為全球通行的國際標準）的 SW-CMM、CMMI 并非高不可攀，另一方面也說明加強軟件開發規范化管理、提高過程成熟度已經得到了業界的廣泛認同。
與此同時，國際軟件界的“敏捷熱”、“統一熱”也在持續升溫。上世紀 90年代以DSDM、Scrum、FDD、Crystal、ASD、XP為代表的輕型軟件開發方法逐漸興起，其中又以XP對傳統的“反叛”最為顯著，它憑借與傳統思維相悖的“極端”做法既獲得了許多軟件客戶、管理者和開發人員的積極擁護，也遭到了傳統過程維護者的激烈反駁。2001年2月敏捷聯盟成立以及《敏捷軟件開發宣言》的發表，標志著這場“敏捷運動”達到了一個高峰。而作為吸收了電信、國防等關鍵行業以及IBM、HP、Microsoft等多家國際著名軟件企業過程經驗的商用過程產品，統一過程RUP也在全球取得了廣泛的成功。某著名咨詢機構 2002 年對全球200位軟件相關行業IS/IT經理進行的調查表明：RUP使用率達到了51%，遠高于SW-CMM（27%）和ISO 9000（26%）；而且到2003年, 大約50%的被調查者預計其50%以上的項目會使用敏捷方法，14%的被調查者認為其所有的項目會使用敏捷方法 [2] 。
承認軟件過程畝嘌雜胱非篤涑墑於紉謊匾��！?One size does not fit all ”，事實證明不存在一成不變地適合于所有項目的過程模板。由于軟件過程的周境不同（如業務、資源、團隊、文化），層次不同（如組織過程、項目過程、團隊過程、個體過程），開發類型不同（如新產品、重用、服務、產品線），一時間出現這么多過程方法論并不足怪。
二、過程方法論對比分析
那么，敏捷、統一過程有哪些特點，與傳統過程有什么不同呢？下面我們以 SW-CMM 為參照，挑選 3 個最典型的過程方法論（ XP 、 RUP 和 TSP ）作對比分析。
SW-CMM是一套用來評估軟件組織過程成熟度的基準，闡明組織為了系統地實施軟件過程改進、提高過程成熟度應該做些什么，但沒有規定如何去做。它的目標通常適用于所有的軟件組織或項目，用來實現目標的大部分關鍵做法也適合中小企業項目，而許多關鍵做法中的子做法主要目的是舉例說明如何在大型政府、國防合同項目中實現總目標，對中小企業項目僅有參考價值。除了對過程的集成性關注不夠，SW-CMM的主要缺點還在于缺少了現代軟件過程的一些重要元素，其KPA主要集中在傳統過程的靜態文檔上（如設計、需求文檔，合同、計劃和報告等），只有很少數的KPA強調了演進式工件（如需求、設計模型，源代碼等）、開發環境的自動化水平以及基于架構的過程。 [6]
為了盡早通過評估，人們往往采用或模仿同樣是由SEI開發的PSP/TSP過程。建立在PSP之上的TSP可能是迄今為止最為嚴格的重型過程。為了提高過程的成熟度和可預測性，TSP強調對過程進行全面精確的度量，這依賴于制作大量復雜繁瑣的數據表格和文檔以及固定程式化流程配合，因而培訓、實施的成本很高。
RUP是一個以用例驅動、構件式架構、迭代遞增式開發為基本特征，可廣泛地應用于各種類型和規模項目的軟件過程框架，它的基本特征與需求管理、配置變更管理、OOAD*UML可視化建模、持續檢驗質量等做法一起集中體現了現代軟件開發的最佳實踐。RUP定義了起始、細化、構造、移交4個階段和業務建模、需求、分析設計、實現、測試、部署、配置變更管理、項目管理、環境等9個工種。階段對應著主里程碑的劃分，不同工種的工作流活動在生命周期的迭代中并發進行，具體執行強度可以按需調節，角色、活動和工件也是靈活可配置的。由于RUP提供了極其豐富的內容，所以常被誤解為一個重型過程。通過定制RUP通用框架，針對具體項目去掉不必要的元素并吸收其他敏捷方法，完全可以定制出敏捷輕型的RUP過程（如RUP的XP插件）。
極限編程 XP具有強溝通、簡化設計、迅速反饋等特點，一般只適合于規模小、進度緊、需求不穩定、開發小項目的小團隊。在其12種做法中，測試為先、持續集成、簡化設計、代碼規范、現場客戶、每周40小時工作制、小型發布等早已有之，并不是新的發明，但XP通過巧妙整合把它們發揮到了極致。而代碼集體擁有、結對編程、重構、系統隱喻、計劃游戲等做法并不是在任何情況下都適用的，使用不當往往會起到相反效果。SW-CMM與XP是互補的，Barry Boehm、Watts Humphrey等權威更認為XP與SW-CMM是哲理相容的 [5] 。主要區別在于，后者更關注過程實施在組織管理上的問題，而XP側重于具體的過程執行和開發技術，不含有被SW-CMM認為是使良好的工程和管理實踐制度化的關鍵基礎設施。
許多團隊在一定條件下實踐 XP可能會收到意想不到的好效果，但純而又純的XP的適用面可能也很小�？巳R斯勒公司的C3薪資系統項目恐怕是引用次數最多的XP成功案例，但實際上該項目后期還是由于開發團隊與管理者之間的溝通出現問題而遇到了麻煩。一個經典的XP項目偏偏在其核心的溝通要素上出現問題，的確值得人們深思。 [7]
XP以代碼為中心，編碼和設計活動融為一體，弱化了架構，這是它與以架構為中心的RUP的最大不同，而且它沒有業務建模、部署、過程管理等概念。兩者也有不少共同點：它們都采用OO技術（取代傳統結構化方法）、演進式迭代周期（取代傳統瀑布模型），強調風險驅動，以保障可用產品的持續性交付為前提，盡量減少不必要的過程工件，使度量、文檔最小化以獲得彈性和應變能力。由于RUP、XP結合了具體的開發方法，因此比TSP具有更好的可操作性。
敏捷、統一過程滿足了 SW-CMM絕大部分目標及2、3級KPA的要求，對4、5級KPA基本沒有涉及。然而，服從類似SW-CMM這樣高質量的過程框架，并不一定會開發出高質量的產品，生產出高質量產品的真正高質量的過程卻理應被評估為成熟的過程 [6] 。事實上，國際上不少采用RUP的組織已經達到或超過了SW-CMM 3級的水準。通過SW-CMM評估要求組織在過程制度化建設上付出大量復雜、高成本的努力，但過程改進的有效性與復雜性、高成本之間沒有必然聯系。過程選擇的多樣性和SW-CMM目標的通用性決定了過程改進途徑的多樣化。
三、我們的對策
針對國內軟件過程改進的現實，我們應該采取什么對策？本文試圖提出一種初步的解決方案。
1. 選擇正確的生命周期模型
首先，選擇一個合適的生命周期模型對于任何軟件項目的成功都是至關重要的。大量項目嚴重拖延、產品遲遲不能交付，究其根本原因往往是與錯誤運用了存在明顯缺陷的瀑布模型有關，所以現代過程方法論，不論輕型、重型， XP、RUP或TSP，無一例外地都推薦、主張采用能顯著減少風險的迭代演進式生命周期模型。早在1994年美國國防部就作出了一個重大決定，用新的軟件開發標準MIL-STD-498取代舊標準DoD-STD-2167A，而在498所要解決的20個關鍵問題中就包括：去除隱含的對瀑布型開發過程的偏好，改進與遞增演進式開發方法的兼容性以及改進與Ada等其他OO方法的兼容性 [8] 。這一態度的明顯轉變為我們提供了重要信息。
然而，由于種種原因，上世紀 70年代提出的瀑布模型多年來一直被我們的軟件工程教育奉為經典來傳授。而在實踐中，我們采用的許多生命周期模型卻不倫不類地介乎瀑布模型和正確的迭代模型之間，毫無規律性可言，從而為軟件開發的成功埋下了嚴重隱患。應該說這是一個歷史性錯誤，可惜國內許多客戶和開發商對該問題的重要性長期沒有引起足夠的重視，美國人已經為此付出了慘痛的代價，卻不知道我們有多少人現在還蒙在鼓里，愿意繼續支付學費。
迭代是 OO開發的本性（Grady Booch）。正確做到迭代開發遠比字面理解要難得多。世界領先的軟件組織其項目迭代開發周期往往呈現圖1的形態，每個迭代開發的內容、速度和質量都很穩定，這也是RUP、XP團隊所能達到的理想狀態（參見《軟件架構》節奏原則一章 [3] ）。如果度量我們許多組織的開發工作，結果可能都會表現為類似圖2的形狀：迭代速度不均，每次交付的內容忽多忽少，而且往往迫于外部壓力而犧牲質量。時常見到，開發人員加班隨意而頻繁，問題卻始終層出不窮，進度也總是無法保證�？杀氖穷愃频默F象屢見不鮮，反而讓我們認為開發節奏紊亂是一種正常態。
2. 適度度量
CMM/PSP/TSP度量體現的是一切用數字和文檔說話。企業要轉變粗放式管理，提高效益，就應該注意對度量數據和實踐經驗的積累。有了歷史與今天的對比，才談得上明天的進步。另一方面，SEI開發CMM/PSP/TSP的主要目的就是為了評估美國軍用軟件承包商的過程能力。在巨額國防經費的驅動下，顯然保證軟件的可靠性和質量、過程可預測可度量往往是軍用軟件項目應該滿足的首要目標，甚至可以為之不惜代價，提高生產率和降低成本則在其次。PSP/TSP基于歷史統計數據的收集分析對過程進行預測、管理、控制、評估和改進，這必然需要長期積累，而大量樣本、數據的收集、維護相對成本很高，如果沒有自動化工具支持、嚴格的紀律保障和在基礎設施上大量投入，全面度量的實效將難以保證。這種度量強度適合于組織內外環境和需求相對穩定，綜合實力強、開發生命關鍵或可靠性要求高的大中型軟件組織，以及那些需要對過程能力作出客觀預測和評價的大型工程、異地外包項目。
圖 3 、 TSP 周期 [4]
任何過程的成熟度都應該以最終交付產品 /服務的質量和ROI為最高評判標準。在民用商業軟件開發環境中，及時推出滿足客戶和市場需求、適用的產品是第1位的，速度常常比盡善盡美更為重要。因此，RUP、XP與倡導統計過程控制的PSP/TSP在度量的范圍和強度上有著較大差別，但這不意味著RUP、XP不需要度量，不能在敏捷、統一過程的框架中引入必要的度量機制。度量產品本身與度量開發產品的過程有所不同（如圖3）。在測試水平還較低、質量保證相對薄弱的國內軟件組織中，加強產品度量也尤其重要。我們不應為了追求過程成熟度而使度量面面俱到，應該在敏捷思想的指導下實現適度（按需）度量。
3. 建立 AUPF
是否一定要采用類似 XP那樣極限的做法項目才能取得成功？答案顯然是否定的。實施過程改進以達到SW-CMM目標，是否只有走PSP/TSP一條道路呢？相信答案也是否定的。組織一旦選定某種過程方法論，就在所有項目上一成不變地照搬執行，排斥其他方法，是不明智的。Alistair Cockburn指出，“不同的項目需要不同的方法論，一個項目的最佳過程是這個項目所能負擔的最小過程”，選擇過程的原則：1）越大的團體需要越大的方法論；2）越關鍵的系統在構建的正確性方面需要越多的透明度/更大的密度；3）在方法論體積或密度上相對小的增加會導致項目成本相對大的增長；4）最有效的溝通方式是面對面的互動。
圖 4 、軟件過程計劃譜系
Barry Boehm根據幾種過程模型計劃性的強弱，描繪了它們在計劃譜系中的相對位置 [1] �？梢钥吹�，里程碑風險驅動的RUP位于最極端的敏捷過程XP和里程碑計劃驅動的TSP之間。Mark Paulk建議，“應該在組織業務環境中恰當的地方仔細考慮采納敏捷運動的想法�！� [5] CMM、XP是互補的，RUP可以和PSP、 XP集成，XP、ASD與Scrum也天然地相吻合，這些事實都說明重型、輕型過程方法論之間并不存在根本性的矛盾沖突。把這些互補方法論拼在一起，恰好可以發現整個軟件過程體系全貌的一部分，可能這就是事物復雜性的原本反映吧。
基于以上討論，我建議，軟件企業可根據自身的實際情況，以統一過程（如 RUP）為基礎建立起符合ISO 9001、SW-CMM 和CMMI SE/SW等基準的組織軟件過程體系，同時包含敏捷過程（如XP、Scrum）和重型過程（如TSP）等內容。我把這種混合/集成過程體系叫做“敏捷統一過程框架”（Agile Unified Process Framework，AUPF）。這就像飯店的廚師準備了豐盛的自助餐，吃些什么，吃多吃少，按照什么順序來吃，企業的各個項目團隊應該獨立作出最恰當的選擇。
AUPF為什么不以XP或TSP為基礎？首先，盡管XP有敏捷高效等好處，但它很容易被誤解誤用�，F階段，國內過程管理和軟件工程水平還比較低。迫于固定工期和預算的壓力，客戶和開發商往往只重視編碼，輕視/忽視需求分析、計劃估算、架構設計、文檔編寫、有效測試以及良好的開發文化和制度，指望減少前期投入通過事后重構來改進軟件，可是重構一旦失敗造成的損失往往更大。架構設計正是復雜項目成功的關鍵，AUPF參照以架構為中心的RUP，通過構造出穩定可靠的架構原型可以為適應需求變化奠定穩固的基礎。
其次，針對許多管理者、開發者在提高開發效率、改進軟件質量方面應該做些什么、如何去做尚感到千頭萬緒、束手無策的局面，與大踏步跨越到重型的 PSP/TSP相比，從在短期內相對更容易取得成效的敏捷、統一過程入手，可能更符合國內大部分企業的實際。
企業實施 AUPF，應拋棄舊有的不規范的軟件過程，做到適度度量，采用正確的生命周期模型和敏捷、統一過程的最佳實踐，并根據實情對個別做法進行調整或舍棄。即使組織已有的過程很成功，也可以借鑒吸收AUPF方法以加強過程的敏捷性。能否讓大型復雜軟件的開發過程敏捷起來呢？任何大系統、大組織都是由小系統、小團隊組成的，所以應該也可以把敏捷方法運用到大項目的子系統子模塊的開發中。例如，在起始和細化階段采用RUP完成需求和架構基線，在構造階段采用XP實現某個模塊。
TRW公司于1987-1994年間為美國空軍開發的導彈預警和地面指揮控制系統CCPDS-R是歷史上非常著名的、融合統一過程（該項目所采用的過程方法后來形成了RUP的一個主要來源）和敏捷思想的成功范例。該獲獎項目的規模為75人、6年、100多萬行Ada代碼，采用了類似RUP 4個階段的迭代遞增、架構優先過程。它不僅按進度和預算交付了大型關鍵任務系統，而且還使用戶獲得了超出預想的功能，在生產率和質量方面取得了2倍的增長。 [1][6]
在整個項目過程中， CCPDS-R承受了大量需求的變化，甚至包括開發后期的一個合同范圍變更。同等程度的需求變化扼殺了大部分采用傳統管理方法的項目，而CCPDS-R卻由于采用了風險管理、設計階段架構的不斷集成以及基于演示的評審方法，有效控制和穩定了變更成本，取得了超乎尋常的成功。CCPDS-R在注重個人互動、可用的軟件、客戶協作和響應變化等方面都做得非常出色，可以說完全實現了敏捷價值觀和目標。（10年前�。�
4. 提高組織和個人的軟件工程基礎技能，全面提升競爭力
過程能力并不是保障成功的惟一因素，影響產品 /項目質量的關鍵因素還包括開發技能和組織管理（圖5），這三者相輔相成、缺一不可。一味地強調提高過程成熟度而忽視組織建設、提高技能，對企業的短期成功和長期健康的全面發展都是不利的。
圖 5 、軟件質量改進3要素
過程就像武術套路，開發技能就像內功。如果功力不到，招數學得再多再好，也不過是花拳繡腿，擺擺樣子。反之，如果功力達到一定程度，就可以運用自如，無招勝有招。許多敏捷、統一過程的發起者、倡導者如 Ivar Jacobson、Kent Beck、Robert Martin、Martin Fowler等人都是全球最著名的OO大師，他們既是令人敬佩的軟件思想家，能夠不斷推陳出新引領軟件開發潮流，又是具有豐厚積淀的程序員之優秀表率，達到了真正高手的境界。
與 OO方法緊密結合的敏捷統一過程要求開發人員具備更高的專業素質。XP要求開發團隊具備熟練的OO編碼、測試和重構等技能，RUP也對OO需求分析、架構設計提出了較高要求。沒有真正理解OO范式與傳統結構化方法的本質區別，缺乏OO技能，敏捷統一過程恐怕就玩不轉了。
由于歷史發展和自身局限等原因，應該承認，我們與北美、歐洲的項目經理、架構師、程序員的能力競爭是不在一個層次上的競爭。我們的軟件企業和個人，無論在過程能力，還是在技術技能、管理素養上都與國際先進水平存在著明顯差距。如果對此不加以重視，老是抱殘守缺、自欺欺人，沾沾自喜、不求進取，這些差距還有可能進一步拉大。
5. 弘揚敏捷文化
“敏捷”的意思大概有：輕巧、機敏、迅捷、靈活、高效、活力 …… 輕載——讓編程之外的一切工作減到最少的辦法——并不能等同于敏捷（當然，組織在重載的情況下也很難做到敏捷）。
我想，實現敏捷過程的真正含義應該是：以滿足客戶需要、創造客戶價值為首要目標，使企業的軟件過程容易洞察、適應市場、競爭、技術、需求等內外環境的變化，對此能夠迅速做出反應、自我調優和完善，并且在保證產品和服務質量的前提下，對交付內容、速度和資源做出正確的權衡，從而實現企業、員工、客戶和社會等多方利益的最大化。
因此，敏捷作為一種快速響應變化、客戶 /受益人利益至上的文化，應該是一切現代商業組織的生存手段和終極目標。事實上，上世紀90年代國內制造業就早已開始學習國外敏捷制造、并行工程的先進經驗了。RUP迭代遞增的開發方式實質上就是一種軟件開發的并行工程。歷史再一次給了軟件行業學習借鑒他人優秀經驗的大好機會。
敏捷文化是企業的核心文化。 AUPF的成功實施離不開高度協同的開發文化和良好的人文環境。以人為本的敏捷價值觀——注重個人及互動勝于過程和工具、注重可用的軟件勝于詳盡的文檔、注重客戶協作勝于合同談判、注重響應變化勝于恪守計劃——正是對刻板僵化的傳統過程文化的有力反叛！我們應該在現代軟件企業管理中大力提倡和培育敏捷文化，加強多方溝通與信任, 強調領導—協作而非命令—控制，盡量發揮每位員工的潛能和主觀能動性；同時，還應該防止把敏捷統一過程奉為新的教條，重蹈官僚形式主義的老路。
四、結語
學習、模仿、運用流行的過程方法論是實施過程改進的好辦法。 TSP、RUP、XP這三種互補模型的目標對象和適用環境各不相同，在理解其精神實質和基本原理的基礎上靈活運用，整合其最佳元素，我們就可能設計出適合自己的過程體系。相比其他方法，RUP處于能屈能伸的有利位置，具有更廣泛的適用性。我們相信，以敏捷思想為指導，在統一過程RUP基礎上集成其他重型過程和敏捷方法，建立敏捷統一過程框架AUPF，將是我國軟件企業尤其中小企業實施持續過程改進的最有效途徑之一。
上世紀 90年代初曾經出現幾十種OO方法繁榮競技的局面，最終OMG UML完成了OO建模語言的統一大業，如今軟件過程建模的統一標準（OMG SPEM）業已誕生�？梢源竽戭A測，隨著人們的經驗愈來愈豐富，不久的將來在進一步達成共識的基礎上，全球將會出現占據主導地位的軟件過程統一新標準。
成功的過程改進始終離不開專業判斷和常識理解，軟件組織應綜合根據應用類型、項目特點和組織文化等諸多因素確定自己的道路，不能人云亦云、盲目跟風。如何把握好各個因素的平衡是軟件工程實踐的永恒話題�，F階段我們應當著重提升軟件組織的整體競爭力，尤其要加強基礎軟件工程的實力，注意選擇正確的生命周期模型，適度度量，不可偏廢開發技能、軟件過程和組織管理任一方面。
度量數據和經驗積累的匱乏一直是我們發展道路上的羈絆。業界總是喜歡強調特殊國情，然而具有中國特色的軟件過程發展模式同樣需要事實和數據來證明。不管您的企業在過程改進方面已取得成功，還是正在計劃或已經開展了CMM/CMMI、敏捷統一過程方面的嘗試，都歡迎 聯系我們，與同行交流分享知識和經驗，既幫助別人，也幫助自己！
參考資源
[1] Barry Boehm, Agile and Plan-Driven Methods Oil and Water ? Agile Universe 2002 slides, Aug. 5, 2002.
[2] Robert Charette, THE DECISION IS IN: AGILE VERSUS HEAVY METHODOLOGIES , Agile Project Management Executive Update, VOL. 2, NO. 19, Cutter Consortium, 2002.
[3] David M. Dikel 著，張恂譯，《軟件架構：組織原則與模式》，機械工業出版社， 2002 年 8 月第 1 版。
[4] Watts S. Humphrey, Setting the Agile Context , Agile Universe 2002 slides, Aug. 2002.
[5] Donald J. Reifer, XP and the CMM , IEEE Software, May/June 2003.
[6] Walker Royce 著，周伯生等譯，《軟件項目管理：一個統一的框架》，機械工業出版社， 2002 年 8 月第 1 版。
[7] Jawed Siddiqi, An Exposition of XP But No Position on XP , IEEE Computer Society Dynabook, http://www.computer.org .
[8] MIL-STD-498 versus DoD-STD-2167A Issue Paper , Sep. 1996.
[9] 張恂，《XP的價值和局限》，2002。
[10] 張恂，《用敏捷方法實施基于 CMM 的軟件過程改進》（上海 SPIN 研討會講稿），2002。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
