從CMM視角看終極編程

摘要：終極編程(XP)近來已被當作一種適應快速多變的網際網路世界和網路軟體開發的程式設計方法而受到倡導。本文從軟體能力成熟度模式(簡稱CMM，是為軟體機構規定開發程序改進優先的五級模式)的觀點重新檢視這一廣受歡迎的方法論，概述XP和CMM，並從軟體CMM角度對XP作出評論。結論是：一些羽量級的方法論，如XP，倡導了許多良好的軟體工程慣例，但是一些慣例尚有爭論，且如果在使用的時候超出其狹窄的適用範圍後，使用起來的效果則適得其反。由於XP可以被用來處理很多CMM第二級和第三級的慣例，對開發程序改進有興趣者應仔細考慮後方能採用XP中的觀念，將其應用於軟體機構的商業環境中。反言之，使用XP的機構也應仔細考慮CMM描述的管理和基礎結構問題。

關鍵字：軟體CMM、能力成熟度模式、CMM、終極編程、XP、靈活的方法、羽量級的開發程序

近年來，終極編程(XP)已作為一種適應快速多變的網際網路世界和網路軟體開發的編程方法而受到倡導，其特點是“羽量級”或“靈活”。雖然XP是一種規範化的開發程序，還是有人在爭議中使用它，而不是像由軟體工程研究所（SEI）開發的軟體成熟度模式這樣嚴格的、為軟體機構規定開發程序改進優先的五級模式。許多進入電子商務領域的機構都有現成的基於CMM的行動(也許還有要求有成熟的開發程序的客戶)，渴望對XP是否以及怎樣能勝任處理CMM的問題有所瞭解。

本文概述XP和CMM，並從軟體CMM的角度對XP作出評論。雖然XP可被形容為一種輕巧靈活的方法論，不像CMM等模式那樣強調程序定義（definition）或者度量，但CMM下開發程序的寬泛性也是得到認可的。本文的結論是：雖然一些原則尚有爭論，且超出其狹窄的適用範圍後，使用起來適得其反，但一些羽量級的方法，如XP，仍然倡導了許多良好的軟體工程原則，而且若在合適的環境裏運用得當，能處理許多CMM第二級和第三級的原則。對開發程序改進有興趣者應仔細考慮後方能採用XP中的觀念，將其應用於軟體機構的商業環境中。反言之，XP的使用者也應仔細考慮CMM描述的管理和基礎結構問題。

軟體能力成熟度模式[見參考書目5，6]是一個建立組織能力的模式，已經在軟體及其它方面廣泛採用。軟體CMM分為五級，其功能是為軟體機構描述良好的工程和管理慣例，對改進優先度作出規定。這五個成熟度級別見圖1。

雖然介紹CMM的專著厚近500頁，但達到第五級的機構的要求用52句話就可以簡要地說明：正式描述這一模式的18個關鍵開發程序範圍（KPAS）的目標。慣例、潛慣例和充實該模式的例證都是指導軟體專業人員作出合理而有見地的決定的大量資訊來源。這些決定和在多種環境——網路環境下2-3人的專案和建立：堅強的，即時的、有生命週期的系統，500人的專案——中大幅度開發程序改進的適度性有關。

軟體CMM中的大量資訊來源主要是集中在客戶開發或維護環境下的大型專案和大型機構。即便如此，只要運用常識，在完全不同的環境諸如小型新公司，小型專案或電子商務環境使用CMM需要解釋和調整的程度就相對較輕[見參考書目7，4]。軟體CMM的分級指標內容十分抽像，以至少從機構優勢的角度出發，獲得關於表現出色的軟體機構的”普遍真理”。分級指標內容見表1。

標識	KPA目的和目標
	成熟度第二級……可重複性
需求管理(RM)	就將由軟體專案處理的客戶需求問題在客戶和軟體專案之間建立共識。
RM目標1	控制分配給軟體的系統需求以建立軟體工程和管理的基線。
RM目標2	軟體計畫、產品和活動與分配給軟體的系統需求保持一致。
軟體專案計畫((SPP)	為完成軟體工程和管理軟體專案制定合理的計畫。
SPP目標1	在計畫和跟蹤軟體專案中證實軟體評估。
SPP目標2	對軟體專案活動和承諾作出計畫和證實。
SPP目標3	受影響的團隊和個人同意與該軟體專案的有關的承諾。
軟體專案跟蹤及監督(SPTO)	給實際進展提供適度的可見性，以便軟體專案執行情況明顯偏離軟體計畫時能採取有效的行動。
SPTO目標1	跟蹤實際成果和執行情況是否與軟體計畫不一致。
SPTO目標2	當實際成果和執行情況明顯偏離軟體計畫時，糾正之，並控制其結束時機。
SPTO目標3	受影響的團隊和個人同意軟體承諾的變化。
軟體外包合同管理(SSM)	選擇合格的軟體外包商，將他們有效地管理起來。
SMM目標1	總承包商選擇合格的軟體外包商。
SMM目標2	總承包商與軟體外包商相互同意其承諾。
SMM目標3	總承包商與軟體外包商保持工作交流。
SMM目標4	總承包商跟蹤軟體外包商的實際成果和執行情況是否與承諾不一致。

標識	KPA目的和目標
*軟體質量擔保(SQA)*
SQA目標1	計畫軟體質量擔保活動。
SQA目標2	客觀驗證軟體產品與活動是否遵循合適的標準。步驟和需求。
SQA目標3	將軟體質量擔保活動和成果通知受影響的團隊和個人。
SQA目標4	由高級管理人員處理不能在軟體專案內處理的違約事件。
軟體結構管理(SCM)	在整個專案的生命週期內建立和維護軟體專案產品的完整性。
SCM目標1	計畫軟體結構管理活動。
SCM目標2	中選的軟體工作產品要可識別、可控制、可利用。
SCM目標3	控制被識別的軟體工作產品的變化。
SCM目標4	將軟體基線的狀況和內容通知受影響的團隊和個人。
	軟體成熟度第三級……定義
*組織開發程序焦點(OPF)*	為提高機構的總體軟體開發程序能力的軟體開發程序活動建立機構責任
OPF目標1	全機構的軟體開發程序開發與改進活動相協調。
OPF目標2	所採用的軟體開發程序的強弱被視為與一個開發程序標準相關。
OPF目標3	計畫全機構的開發程序開發和改進活動。
*組織程序定義(OPD)*	開發並維護一套有用的軟體開發程序資源。該資源可改進整個專案的開發程序執行情況，並為機構打下累積的長期的益處的基礎。
OPD目標1	為機構開發和維護一個標準軟體開發程序
OPD目標2	收集、重溫與由軟體專案所使用的機構的標準軟體開發程序相關的資訊，並使其可供使用。
*培訓方案(TP)*	發展個人技能，擴充個人知識，使其能有效率地完成工作。
TP目標1	計畫培訓活動。
TP目標2	提供為完成軟體管理和技術工作而進行的發展所需技能和知識的培訓。
TP目標3	軟體工程團隊和與軟體相關的團隊中的個人接受完成其任務所必要的培訓。
*整合軟體管理(ISM)*	將軟體工程和管理活動整合成連貫確定的軟體開發程序。該開發程序從機構的標準軟體開發程序和相關開發程序資源中編制而成。
ISM目標1	專案確定的軟體開發程序由機構的標準軟體開發程序的剪裁而成。
ISM目標2	根據專案確定的軟體開發程序計畫和管理專案。
*軟體產品工程(SPE)*	連貫完成一個定義良好的工程開發程序。該開發程序整合了所有的軟體工程活動，有效地生產出正確的、連貫一致的軟體產品。
SPE目標1	定義、整合、連貫完成軟體工程任務，生產出軟體。
SPE目標2	軟體工作產品互相保持一致。
*團隊內部協調(IC)*	找到使一個軟體工程團隊積極參與其他工程團隊的方法，使開發程序能更好更有效地滿足客戶的要求。
IC目標1	客戶的需求為所有受影響的團隊所同意。
IC目標2	工程團隊之間的承諾為所有受影響的團隊所同意。
IC目標	工程團隊確定。跟蹤。解決團隊內部的事務。
*同級復查(PR)*	及早並有效地刪除軟體工作產品中的缺陷。隨之而來的一個重要影響是對軟體工作產品和可以防止的缺陷有了更好的理解。
PR目標1	計畫同級復查活動。
PR目標2	確定並刪除軟體產品中的缺陷。
	軟體成熟度第四級……管理
*定量開發程序管理(QPM)*	定量控制軟體專案的開發程序執行情況。軟體開發程序執行情況代表跟隨一個軟體開發程序取得的實際成果。
QPM目標1	計畫定量開發程序管理。
QPM目標2	定量控制專案的定義軟體開發程序的開發程序完成。
QPM目標3	從數量上瞭解機構的標準軟體開發程序的開發程序能力。
*軟體品質管制(SQM)*	增進對計畫的軟體產品質量的量化理解，達到特定的質量目標。
SQM目標1	設計專案的軟體品質管制活動。
SQM目標2	為軟體產品質量及其優先規定可衡量的目標。
SQM目標3	軟體產品可達到的質量的實際步驟進行量化和管理。
	軟體成熟度第五級……最優化
*缺陷防止(DP)*	確定產生缺陷的原因並防止其再度出現。
DP目標1	計畫缺陷預防工作。
DP目標2	找出並確定導致缺陷的一般原因。
DP目標3	優先並系統地排除導致缺陷的一般原因。
標識	KPA目的和目標
*技術變化管理((TCM)*	確定新技術(如工具、方法、開發程序)，用有序的方式將其轉入機構中。
TCM目標1	計畫要採用的新技術的組合。
TCM目標2	革新技術，確定新技術對質量和生產率的影響。
TCM目標3	合適的新技術成為機構的平常慣例。
*開發程序變化管理(PCM)*	不斷改進機構使用的軟體開發程序，以提高軟體質量和生產率，縮短產品開發的週期。
PCM目標1	計畫連續的開發程序改進。
PCM目標2	全機構參與機構的軟體開發程序改進活動。
PCM目標3	連續改進機構的標準軟體開發程序和專案定義的軟體開發程序。

排除軟體外包合同管理（因為假如一家機構不外包合同，該項管理就不適用），關鍵開發程序範圍及其目標可適用於任何軟體機構。關注革新甚于關注優異的操作性的公司可對連續性、可預見性和可依賴性不予重視，但即使在高度創新的環境下，開發程序優異的執行情況也是很重要的。如果三思而行，表1中的任何一個目標都能為機構帶來價值。

終極編程通常被認為是由Kent Beck, Ron Jefferis和Ward Cunningham提出的一種羽量級的(或靈活的)軟體方法論[見參考書目2，3，8]，針對面對模糊或快速變化的需求編制軟體的中小型團隊。典型的XP小組的人數應不超過十人，最好共處一地。

XP方法假設諸如目標/模式、關係型數據庫和資訊隱藏等技術已經(或能夠)解決變化的高成本。這一假設招致了批評。作為該假設的後果，由此產生的XP開發程序總是處在變化中，Beck著作的副標題既是”不斷的變化”。而且，XP小組在整個短迴圈的反覆開發週期中處理需求變化。XP開發週期的四個基本活動是：編碼，測試，反饋和設計。其活力也由四個價值顯示出來：

XP採用的大部分原則，如最底限度主義、簡單、進化開發週期、增加短迴圈次數、用戶介入、良好的編碼標準等等，已成為共識和任何規範的開發程序中正確的慣例。XP中的“終極”二字來自“就終極級別(如表2概括)達成共識”。雖然有人可能(不正確地)將慣例（如“致力於最底限度地解決問題”）解釋為：程式”挖口”，但實際上XP是一種高度規範的開發程序。簡單指著重于最高優先的開發，著重於系統最有價值的部分，將其作為當前確定的物件，而不是設計解決還不需要，而且也許當需求和操作環境改變後就永遠不再需要的問題的方案。

XP可以概括為12項原則。雖然還有許多原則也可算作XP的一部分。但這12項是基礎。

1.規劃策略——迅速決定下一次發行的範圍、商業優先和技術評估。由客戶從商業角度決定發行範圍、優先和發行日期，技術人員則對開發程序作出評估和跟蹤。

2.小範圍發佈——迅速在生產中使用小型系統。在極短的週期內（兩周）發行新的版本。

3.系統比喻——用關於整個系統如何工作的簡單、共用的故事情節卡來指導所有的開發。

5.測試——不斷編寫運行無錯誤的單元測試；由客戶編寫測試以表明功能完成。”先測試，後編碼”指不失敗的測試是成功編寫程式碼的基礎。

6.重新劃分——不改變行為地重構系統，刪除重複，改進交流，簡化，或增強靈活性。

7.雙人組程式設計——所有程式碼由兩個程式師在同一台電腦上編寫。

8.集體所有權——任何人都可以在任何時間改進系統任何地點的任何程式碼。

9.持續整合——一天多次整合和建立系統，每次完成一項任務。連續的回歸測試指作為需求變化後，功能並沒有退步。-

10.一周40小時——將一周工作不超過40小時作為一條規定；決不連續兩周超時工作。

11.現場客戶——真正的、身處開發現場的用戶，隨時回答問題。

規劃策略和小範圍發行依靠客戶提供的一套”故事情節卡”對需求的特徵進行簡短描述，這些故事和描述在每次發行中對工作的特性加以描述。發行前兩周，軟體小組和客戶必須就兩周內實施哪種故事情節卡(簡單使用的案例)達成一致。故事情節卡庫擁有客戶想要的全部功能性，但只有被確定為具備在兩周後發行時客戶最需要的特徵的子集才能隨時得到實施.。新故事情節可隨時加入庫中，這樣,需求的變化非常容易體現，但由於工具在基於庫內最需要的功能的兩周程式塊上運行，於是需求的變化得到了控制。為支援這種類型的反覆開發週期，在開發中擁有一名現場客戶是必要的。

“系統比喻”為專案提供系統構架。它可以被認為是一個高級別的層次結構，但XP強調設計，同時將設計證明減至最低限度。有人認為XP的特徵是不允許外部程式碼證明[見參考書目1]，但更準確的說，因為XP強調不斷重新設計(通過必要時的重新劃分)，詳細的設計證明的價值不大……畢竟，維護者很少相信程式碼以外的東西。程式碼編寫完成後，設計證明就被扔到一邊了。只有當客戶不能再提出新的故事情節時，設計證明才保存下來。然後將系統封存，寫一份五到十頁的系統”衛生球之旅（容易消失）”。強調重新劃分的自然而然的推論是：總是實施滿足當前急需的最簡解決方法。需求的變化似乎取代了”普遍解決方法”。

雙人組程式設計是XP中更加有爭議的慣例之一，因為它對決定專案是否使用XP的管理者具有資源上的影響。雖然看起來雙人組程式設計需要雙倍的資源，但研究表明，雙人組程式設計可以提高質量，縮短週期[見參考書目9]。對一個定型的小組而言,工作努力程度的提高可能只有15%，而週期則可減少40-50%。在互聯網時代，快速的市場增長速度值得更加努力的工作。合作將使解決問題的開發程序得到改進，質量的提高也將在維護費用方面產生明顯的影響。比之在整個開發生命週期中追加資源，雙人組程式設計可能使你的花費更少。

集體所有權指任何人都可以在任何時間改進系統任何部分的任何程式碼。XP強調持續整合和連續回歸測試，在這裏可以使用雙人組程式設計，防止出現問題。

“先測試後編碼”表明XP對測試的重視。它規定了一條原則，即應當及早對測試作出計畫，測試開發出來的案例應與需求分析同步，但傳統上注重的還是黑匣測試，即使並不經常進行，在使用週期內及早考慮測試問題仍是著名的軟體工程慣例。

XP的基本管理工具是度量制，度量制的媒介是“大型可視圖表（big visible chart）”。在XP中，一個小組通常能夠承受的度量是三到四個。這些度量應得到積極的使用，並且可以被小組看到。“專案速度”(一次反覆可以完成的給定大小的故事情節卡)是一種值得推薦的XP度量制。

採用XP（即採用XP面向開發程序改進的意見）時，推薦一次採用一個XP慣例，總是為你的小組解決最緊迫的問題，正如所希望的那樣，XP面向變化的意見是它”僅僅是規則”—— 只要在如何評估變化的結果上意見一致，小組可以隨時改變規則。XP的倡導者認識到，XP是一種社會性極強的活動，不是人人都能夠學習的。說到這裏，我們還應認識到XP是一種為緊急行動提供依據的“系統”或“方法論”，為了充分享受XP帶來的益處，一套合理完整的基本慣例還是必需的。

XP的價值存在于任何現代軟體專案，即使在其他環境下工具會完全不同。交流和簡單可以換一種說法(例如協調和簡潔)，但如果沒有它們，大型項目內部就面臨著幾乎難以克服的差異。XP的交流和簡單原則也是同時使用軟體CMM的機構的基本開發程序設計原則。定義開發程序時，機構應掌握所需的最小要素資訊，在結構定義時使用良好的軟體設計原則(如資訊隱藏和抽像)，注重有用性和可用性[見參考書目7]。迅速反饋對即時程序控制至關重要，它甚至在幾個世紀前就成了格言：“”。在定量意義上它可以被視為第四級的靈魂。也是從第一級到第二級文化轉變的結果之一，是用我們的估計、計畫和承諾的現實主義態度來證明我們的信念的勇氣。

表中大多數基於CMM的開發程序改進的形式主義，大部分是大型專案的人為現像與/或對嚴格可靠性的需求，對開發週期非常緊的（life-critical）系統尤其如此。軟體CMM的分級結構意在在18個關鍵開發程序範圍和52個目標的前後關係中支援多種工具，這些範圍和目標組成了對完全成熟的軟體開發程序的需求。

系統變得越大，一些XP慣例就越難以實施。對於越來越大的專案，將注意力放在良好的結構“哲學”上對項目成功日益關鍵。基於層次結構的設計、為變化設計、重新劃分和類似的設計哲學強調以系統的方式處理變化的必要性。這些概念的變異（包括基於層次結構的設計和整合產品小組）在小組內與XP同時使用對大型專案更為合適。在某種意義上，強調靈活性的層次結構設計是任何好的定向目標方法論的目標，所以XP（帶重新劃分）與目標定向互相契合。因為XP只針對軟體專案，所以多規則小組的存在也是成文題的。

反對運用XP為開發程序改進服務的主要理由是它僅僅觸及了少量管理和機構事務，而這些正是軟體CMM所強調的。XP假設的高度合作的環境需要有開明的管理和合適的機構基本結構。關於軟體CMM意義上的開發程序規範——該規範甚至達到嚴格的統計學上的穩定開發程序的地步——與XP對立的爭論，是沒有根據的。XP具備規範的開發程序，而且明顯是一個“定義準確”的開發程序。我們可以認為CMM和XP是互補的。軟體CMM從廣義上回答做什麼，但沒有說明怎樣做；XP則是一套最好的包括非常詳細的“怎樣做”資訊的慣例——一個用於特定環境的使用範本。即使不完全處理，XP慣例也可以與某項慣例的意圖（或目標、關鍵開發程序範圍）相容。

在CMM第二級中，需求管理由故事情節卡、現場客戶和持續整合處理。軟體專案計畫由規劃策略和小範圍發行解決。XP的規劃戰略是Humphrey名言的具體化：“如果不能將計畫做好，就經常做計畫。”

軟體專案跟蹤和監督由小範圍發行版的“大型可視圖表”、專案速度和實現承諾（故事情節卡）處理。XP的實現承諾開發程序在戰術水平上為客戶和XP小組作出明確的預計，並在項目的戰略水平上將靈活性最大化。XP對一周工作40小時的強調是一項一般的管理內容，不在CMM的處理範圍之內，但卻被認為是最好的慣例。同時XP也強調開放式工作空間、類似的“人事”，這些也超出了CMM的範圍。軟體外包合同管理不由XP 處理（而且可能也不適合物件環境）。

當一個獨立的SQA團隊不大可能成為XP文化的一部分時，可由雙人組程式設計來處理軟體質量擔保;保證編碼標準的一致性是SQA的一大責任，在XP環境中由同級壓力（peer pressure）解決。然而一個基於CMM的開發程序實施後，就具有了需求、標準和步驟的目標校驗機制。XP依賴於peer pressure，但一旦換成外部壓力（external pressure），在大多數環境中就很容易受損。軟體機構應該考慮這種易受損性。

軟體結構管理的一部分通過集體所有權、小範圍發行和持續整合處理。雖然處理得不夠充分、明確，但結構管理仍然隱含在這些XP慣例中。對大型系統而言，集體所有權是有問題的，而且可能導致SCM失敗。因為為了保證效率，大型系統的交流渠道必須更加程式化

在第三級，軟體機構開發程序焦點在小組層面而不是機構層面上處理，但一次採用一個XP慣例背後的哲學和“僅僅是規則”暗示著一個關於開發程序事務的焦點。因為XP定位在軟體工程開發程序而不是機構基層結構事務上，所以不論是否處在基於CMM的背景中，這一級和其他處於機構層面的開發程序都要由採用XP的機構來處理。同樣，機構程序定義和培訓方案的一部分由各種的書籍、文章、課程和XP網站解決，但機構資源不在XP範圍之內。其結果，整合軟體管理將不能得到處理，因為可能沒有任何機構資源可供剪裁。

軟體產品工程用XP方法論中的很多方法都可以很好地解決，如系統比喻、簡單設計、重新劃分、設計證明、編碼標準、單元測試和功能測試。在很多環境（如非常（hard）即時系統、大型系統或虛擬小組）中，缺乏設計證明是令人擔心的。在這樣的環境裏，好的設計對成功十分重要，而重新劃分的策略則十分危險。例如，當已經用諸如比率單調性分析的技術證明一個系統滿足對非常（hard）即時要求很高的之後，重新劃分意味著得再做一次分析——在這種環境下，花費是頗大的。

團隊內部協調由現場客戶和雙人組程式設計處理。XP對交流的強調的結果，是團隊內部協調的解決方法像整合的產品和開發程序開發一樣有綜合性（而且可以用來判斷一個有效的（IPPD）方法），但是其只針對軟體的背景忽視了多規則環境。

同級復查由雙人組程式設計處理。在讀碼和編程規範（literate programming）意義上，雙人組程式設計比同級復查更有作用，但是結構的缺乏可能削弱其有效性。關於雙人組程式設計的經驗性資料目前並不多，但很有前途。將雙人組程式設計和同級復查技術做一個對照和比較會發現，需要經驗性的研究做基礎，以便在二者之間作出明智的決定。

從嚴格的統計學意義上講，第四級和第五級的關鍵開發程序範圍很少能用XP處理，但是在短週期內可以用反饋處理一部分缺陷防止。至少在對XP合適的領域內，部分滿足XP的CMM關鍵開發程序範圍如表3。

毫無疑問，在實際專案中，很多部分由XP支配或本不能處理的關鍵開發程序範圍也是用XP處理的。沒有管理和基層結構支援，XP就不能生存，即使它沒有明確地被使用。XP關注技術，而CMM關注管理，但是兩者都不可避免地關心“文化事務”。

XP的大部分包括在任何情況下都應當仔細考慮的良好的慣例。但是，當我們用其他處理同樣問題的方法與任何這些慣例的優點相比發現難分高下時，它們都不應被斷然否定。

將這些慣例集合成為一種方法論，可能正如協同工程那樣，成為一個範例轉換（paradigm shift）。協同工程的概念已經存在了幾十年，將這些概念整合為一個系統就產生怎樣建立產品的範例轉換（paradigm shift）。同樣，XP提供了一個關於編程的系統觀點(如果不是唯一一個的話)，就像軟體CMM提供了一個關於機構開發程序改進的系統觀點一樣。希望提高能力的機構應集兩者所長，並學習怎樣選擇和實施那些觀點的常識。

軟體CMM關注有效、高效的管理事務，和系統開發程序改進。XP是一套特定的慣例——一種“方法論”——在共處一地的小組背景下發揮其作用。兩者都有很好的觀念，可以互相合作，特別是與其他優秀的工程和管理慣例一道使用效果更好。如前所述，XP的問題是，是否應該用於即時或高依賴性的系統。缺少設計說明和不強調層次結構可能被大多數知識豐富的專業人員視為有風險，但XP的一大優點是，在不同的環境下可以對其加以變化或改進。

改變XP的風險是，在原有背景下帶來價值的突出的性質可能變得不突出。在選擇和改進軟體開發程序方面應該強調使常識的普遍接受性——並且，當回答挑戰性的問題時，無論是否可能提出見解，都使用真實的事實（資料）。

聲明：感謝Kent Beck 和Laurie Williams對本文草稿提出的意見，特此聲明。

日期	版本	描述	作者
<2002-01-28>	<草稿>	<從CMM視角看終極編程>	<沈蘇南>
<2002-01-28>	<定稿>	修改	<朱斌>

級別	中心	關鍵開發程序範圍
5最優化	連續開發程序改進	缺陷預防技術變化管理開發程序變化管理
4管理	產品和開發程序質量	定量開發程序管理軟體品質管制
3 定義	工程開發程序和機構支援	組織開發程序中心組織程序定義培訓方案整合軟體管理軟體產品工程團隊協調同級復查
2可重複	方案管理開發程序	需求管理軟體方案計畫軟體方案跟蹤和監督軟體外包合同管理軟體質量擔保軟體結構管理
1 初始	勝任工作的人員和信心

共識慣例	XP之“終極”	XP工具
程式碼復查	從始至終復查編碼	雙人組程式設計
測試	從始至終進行測試，即使是由客戶來完成	單元測試、功能測試
設計	對每人每天的工作的一部分進行設計	重新劃分
簡約	總是對系統進行能支援其當前功能性的最簡設計	可行的最簡單的事情
層次結構	所有人員從始至終對層次結構進行改進	系統隱喻
整合測試	每天多次整合與測試	連續整合
短反覆	使反覆非常之短……幾秒、幾分鐘、幾小時，而不是幾周、幾月或幾年	規劃策略

第二級KPAS	滿足	第三級KPAS	滿足	高成熟度KPAS	滿足
RM	++	OPF	+	QPM	--
SPP	++	OPD	+	SQM	--
SPTO	++	TP	--
SSM	--	ISM	--	DP	+
SQA	+	SPE	++	TCM	--
SCM	+	IC	++	PCM	--
		PR	++