摘要：極限編程是近年來非常流行的敏捷軟件開發(fā)方法，與其它敏捷軟件開發(fā)方法一樣，強調(diào)軟件開發(fā)過程的自適應性和以人優(yōu)先的價值觀[1]，這與傳統(tǒng)的重量級軟件開發(fā)方法強調(diào)對開發(fā)過程的控制相反。那么，敏捷軟件開發(fā)方法能否開發(fā)出高質(zhì)量的軟件產(chǎn)品呢?本文探討在極限編程中如何進行軟件質(zhì)量控制，既保持“敏捷”的特點，又能作為一種成熟的軟件開發(fā)過程，為客戶提供高質(zhì)量的軟件產(chǎn)品。

　　Abstract: Extreme Programming is the most popular method among all the Agile Software Development methods, which are characterized by the self-adaptive nature and people-first orientation[1]. Can Agile Methods provide same quality product such like the process-oriented heavyweight method? This paper explores the potentiality of Extreme Programming to produce high quality software, and discuss how to control software quality in Extreme Programming and make it become a mature software process while still keeps agile.

　　關(guān)鍵字：

　　極限編程 質(zhì)量控制 過程控制 軟件過程成熟度模型

　　Keywords:

　　Extreme Programming Quality Control

　　Process Control CMM

　　1. 概述

　　1.1 極限編程

　　極限編程是基于簡潔、交流、反饋和勇氣4個價值觀的一種敏捷軟件開發(fā)方法。它以其13個核心實踐為標志[2]：

　　1)現(xiàn)場客戶(On-site Customer)：要求至少有一名實際的客戶代表在整個項目開發(fā)周期在現(xiàn)場負責確定需求、回答團隊問題以及編寫功能驗收測試;

　　2)計劃博弈(Planning Game)：將軟件開發(fā)過程劃分成許多迭代周期，在每一個迭代周期前結(jié)合項目進展和技術(shù)情況，確定下一周期要開發(fā)與發(fā)布的系統(tǒng)范圍;

　　3)小型發(fā)布(Small Release)：強調(diào)在非常短的周期內(nèi)以遞增的方式發(fā)布新版本，從而可以很容易地估計每個迭代周期的進度，便于控制工作量和風險，同時，也可以及時處理用戶的反饋;

　　4)客戶測試(Customer Tests)：在每次小型發(fā)布之前，由客戶編寫測試用例，參加產(chǎn)品的合格性測試;

　　5)簡單設(shè)計(Simple Design)：代碼的設(shè)計盡可能的簡單，只要滿足當前功能的要求，不多也不少;

　　6)結(jié)對編程(Pair Programming)：由兩個開發(fā)人員在同一臺電腦上共同編寫解決同一問題的代碼，通常一個人負責寫編碼，而另一個負責保證代碼的正確性與可讀性;

　　7)測試驅(qū)動(Test-Driven Development)：強調(diào)"測試先行"(Test Before)。在編碼開始之前，首先將測試寫好，而后再進行編碼，直至所有的測試都得以通過;

　　8)設(shè)計重整(Refactoring/ Design Improvement): 又稱代碼重構(gòu)，在不改變系統(tǒng)行為的前提下，重新調(diào)整、優(yōu)化系統(tǒng)的內(nèi)部結(jié)構(gòu)以減少復雜性、消除冗余、增加靈活性和提高性能;

　　9)持續(xù)集成(Continuous Integration)：提倡在一天中集成系統(tǒng)多次，而且隨著需求的改變，要不斷的進行回歸測試;

　　10)代碼集體擁有(Collective Code Ownership)：開發(fā)小組的每個成員都有更改代碼的權(quán)利，所有的人對于全部代碼負責;

　　11)代碼規(guī)范(Coding Standard)：強調(diào)通過指定嚴格的代碼規(guī)范來進行溝通，盡可能減少不必要的文檔;

　　12)系統(tǒng)隱喻(System Metaphor)：通過隱喻來描述系統(tǒng)如何運作、新的功能以何種方式加入到系統(tǒng);

　　13)適當?shù)墓?jié)奏(Sustainable Pace)，又稱每周40小時工作制。

　　1.2 軟件質(zhì)量控制

　　所謂軟件質(zhì)量，可以用軟件中的錯誤密度表示。質(zhì)量越高，錯誤密度越小，由于軟件開發(fā)過程中隨時可能引入軟件錯誤，軟件質(zhì)量控制的目的就是要排除軟件中的錯誤。傳統(tǒng)上，評審和測試是進行軟件質(zhì)量控制的基本方法。評審是對軟件的中間產(chǎn)品如軟件需求規(guī)格說明、軟件設(shè)計說明、軟件測試設(shè)計進行錯誤檢查和規(guī)范遵從性檢查的主要手段，而測試主要是查找軟件的最終產(chǎn)品，即軟件運行代碼中的錯誤。

　　軟件開發(fā)過程的質(zhì)量控制通常是與開發(fā)階段的劃分相關(guān)聯(lián)的。在典型的瀑布開發(fā)過程中，軟件開發(fā)過程通常劃分為軟件需求分析、軟件設(shè)計、軟件實現(xiàn)和軟件測試等階段。對軟件質(zhì)量進行粗控(如圖1所示)時，把每一個軟件開發(fā)階段當作一個黑盒子，對每一個黑盒子的輸入輸出進行質(zhì)量控制。該控制方法又可稱基線控制方法：將軟件開發(fā)過程劃分為若干條基線，每一條基線意味著上一開發(fā)階段的結(jié)束和下一開發(fā)階段的開始，因此在每一條基線到來時需要評審或測試本階段的工作產(chǎn)品，進行缺陷修正后，結(jié)束本階段工作，而該階段產(chǎn)品作為下一階段工作的輸入。

　　在有些項目中，需要對軟件質(zhì)量和軟件過程作更加嚴格的控制，項目各開發(fā)階段不再被當作黑盒子，而是一個透明的玻璃盒子，在各階段內(nèi)部過程中被插入若干控制點，使用多種方法如同行評審、走查、審計等方法查找軟件錯誤，對軟件質(zhì)量進行監(jiān)控。這種質(zhì)量精控的過程如圖2所示。

　　圖1軟件質(zhì)量的粗控

　　圖2軟件質(zhì)量的精控

　　評審和測試是軟件質(zhì)量保證的基本技術(shù)，在已定義的質(zhì)量控制點使用軟件質(zhì)量保證技術(shù)是軟件質(zhì)量控制的過程化方法，如何保證這些方法的有效性，監(jiān)督這些方法的有效執(zhí)行則是質(zhì)量管理的內(nèi)容。

　　2. 極限編程的質(zhì)量控制

　　極限編程看似一個順乎人本能的、自由的軟件開發(fā)過程，而事實上其核心實踐卻包含了嚴格的質(zhì)量控制技術(shù)。

　　2.1 極限編程軟件質(zhì)量的外部控制過程

　　極限編程的整個軟件開發(fā)過程是由若干小的迭代周期完成，每一周期實現(xiàn)部分用戶需求，完成后進行一次小型發(fā)布，然后根據(jù)用戶的反饋和進一步的要求，開始下一周期的開發(fā)。在每次小型發(fā)布之前，通過客戶測試對該周期完成的產(chǎn)品進行合格性檢查，而每當一個迭代周期完成后，需要確定下一周期要開發(fā)與發(fā)布的系統(tǒng)范圍，以便開始下一次迭代過程。而下一周期開發(fā)范圍的確定，是由現(xiàn)場客戶參與確認的。極限編程軟件質(zhì)量的外部控制過程如圖3所示。在此，現(xiàn)場客戶的參與相當于從用戶的角度對軟件需求進行評審，而客戶測試相當于傳統(tǒng)意義的軟件驗收測試。可以認為，現(xiàn)場客戶和客戶測試兩個核心實踐是極限編程軟件開發(fā)過程中每一個重要節(jié)點的質(zhì)量保證手段。

　　圖3極限編程的質(zhì)量外部控制過程

　　2.2 極限編程內(nèi)部軟件質(zhì)量控制過程

　　在每個迭代周期內(nèi)部，軟件開發(fā)過程仍然可以劃分為軟件設(shè)計、編碼、單元測試等過程，但這些過程不再具有完全的線性關(guān)系，而是互相交錯迭代(極限編程的每一迭代周期的實踐過程流圖如圖4所示)。除此之外，極限編程不看重軟件文檔的作用，其觀點是：編寫規(guī)范、書寫簡潔、結(jié)構(gòu)清晰的代碼本身就是最好的軟件文檔。因此，在極限編程中，基于軟件文檔的軟件評審不再適用，同時，煩瑣的小組評審制也不適宜用于“敏捷”過程。盡管如此，極限編程卻有更加嚴格的軟件質(zhì)量控制手段進行內(nèi)部質(zhì)量控制。事實上，它絕大多數(shù)核心實踐的目的都是提高軟件質(zhì)量。

　　a) 代碼規(guī)范

　　代碼的易分析性、易維護性是重要的軟件質(zhì)量因素，通過制定代碼規(guī)范，極限編程讓所有的程序員能夠編寫出風格統(tǒng)一、結(jié)構(gòu)清晰、易于理解、易于維護的源代碼，既是提高軟件質(zhì)量的重要途徑，也是代碼代替文檔的重要前提。代碼規(guī)范是質(zhì)量控制的基礎(chǔ)，而代碼規(guī)范的依從性檢查則是通過“結(jié)對編程”、“設(shè)計重整”、“代碼集體擁有”等實踐進行檢查的。

　　b) 結(jié)對編程

　　結(jié)對編程是一種典型的同行評審方式。該實踐的宗旨是兩個人的智慧比一個人強。由兩個開發(fā)人員在同一臺電腦上共同編寫解決同一問題的代碼，通常一個人坐在前端進行鍵盤操作，寫代碼，而另一個人坐在后面負責保證代碼的正確性與可讀性，相當于以個人評審的形式進行代碼審查或靜態(tài)測試。與此同時，另一個坐在旁邊還可以考慮不同的設(shè)計思路和測試思路。

　　c) 設(shè)計重整

　　又稱代碼重構(gòu)，在不改變系統(tǒng)行為的前提下，重新調(diào)整、優(yōu)化系統(tǒng)的內(nèi)部結(jié)構(gòu)以減少復雜性、消除冗余、增加靈活性和提高性能;當一段代碼的設(shè)計不夠完善、不夠簡潔、不夠規(guī)范，對其進行設(shè)計重整，設(shè)計重整是同行評審或自我評審的結(jié)果。它導致更加完善的設(shè)計或編碼。

　　d) 測試驅(qū)動的軟件開發(fā)過程

　　對測試的高度重視是極限編程的一個重要特點。極限編程中，測試劃分為單元測試、持續(xù)集成和客戶測試，這與傳統(tǒng)的單元測試、集成測試和確認測試測試過程相對應。同時，極限編程強調(diào)“測試先行”的原則，即使對于單元測試，也要求在進行編碼之前先寫測試用例，既能在編寫測試用例過程中從測試的角度對軟件設(shè)計進行評審，又能保持測試設(shè)計的獨立性。

　　綜上所述，極限編程的核心實踐提供了用于軟件開發(fā)過程內(nèi)部進行質(zhì)量控制的一套精心的手段。在開發(fā)過程的每一個迭代周期完成后，通過客戶測試完成系統(tǒng)合格性檢查，而在迭代周期的內(nèi)部，通過“結(jié)對編程”、“測試先行”、“單元測試”等實踐，幾乎在每一個設(shè)計、每一個模塊編碼完成后，都對其進行了錯誤排除，以期獲得“干凈”的軟件模塊;而每一次新的模塊加入系統(tǒng)，通過“持續(xù)集成”，排除軟件接口錯誤，又能得到“干凈”的系統(tǒng)。

　　圖4 極限編程每一迭代周期內(nèi)部的實踐過程流圖

　　3. 在“信任”與“控制”之間建立平衡

　　極限編程的許多核心實踐實際都是經(jīng)過實踐千錘百煉的準則，這些準則使得極限編程成為一個比較成熟的軟件過程，下表總結(jié)了極限編程的核心實踐對于CMM關(guān)鍵過程區(qū)域的滿足度[3]：(√表示部分滿足，√√表示在適當?shù)沫h(huán)境下幾乎滿足，--表示未涉及。)

　　2級 KPA滿足度3級 KPA

　　滿足度高級 KPA滿足度

　　需求管理√√組織過程焦點 軟件過程管理--

　　軟件項目規(guī)劃√√組織過程定義√軟件質(zhì)量管理--

　　軟件項目跟蹤與監(jiān)視√√培訓方案--

　　軟件子合同管理--集成軟件管理--故障預防√

　　軟件質(zhì)量保證√軟件生產(chǎn)工程√√技術(shù)變更管理--

　　軟件配置管理√組件協(xié)調(diào)√√過程變更管理--

　　同行評審√√

　　盡管極限編程有如此眾多的核心實踐支持軟件質(zhì)量的控制?可是這些核心實踐能被不折不扣地執(zhí)行嗎?結(jié)對編程能象傳統(tǒng)的同行評審那樣有效嗎?軟件的測試設(shè)計足夠發(fā)現(xiàn)軟件錯誤嗎?軟件的測試是否100%覆蓋了軟件需求或設(shè)計?這些問題怎么回答?敏捷軟件開發(fā)方法強調(diào)以人優(yōu)先，認為軟件開發(fā)人員是負責任的專業(yè)人員，他們有動機將程序?qū)懙帽M可能的好，測試盡可能充分，希望為客戶提供高質(zhì)量的產(chǎn)品，應該得到充分的“信任”?？墒牵幢丬浖_發(fā)人員有提供高質(zhì)量軟件產(chǎn)品的動機，可是他們具備相應的經(jīng)驗嗎?如果不加控制，敏捷方法的下場會不會象早期的快速軟件開發(fā)方法(RAD)最終變成聲名昭著的“快而臟”(Rapid And Dirty)一樣。

　　為此，在“信任”和“控制”之間建立適當?shù)钠胶馐潜匾摹?/p>

　　極限編程中的兩個角色在質(zhì)量控制方面起著非常重要的作用，他們是教練(Coach)和追蹤員(Tracker)。教練是極限編程中舉足輕重的人物，是項目的幕后指揮，總能發(fā)現(xiàn)開發(fā)過程中出現(xiàn)的真正的問題，用恰當?shù)姆绞浇o與解決。他最主要的任務是隨時調(diào)整項目組的軟件開發(fā)方向，以期達到最佳結(jié)果。而追蹤員的職責是在不影響開發(fā)人員的情況下收集項目的過程數(shù)據(jù)如計劃的執(zhí)行情況、軟件的缺陷數(shù)、軟件錯誤的改正日志等等，為教練提供統(tǒng)計數(shù)據(jù)和項目的定量分析結(jié)果。[2]

　　因此，教練和追蹤員的職責實際已經(jīng)涵蓋了CMM第4級中的兩個關(guān)鍵過程區(qū)域：軟件質(zhì)量管理和軟件過程管理。可以認為教練和追蹤員兩個角色的設(shè)置使極限編程可以走向更高的過程成熟度。

　　在實踐中，也有一些團隊仍然使用專職的有經(jīng)驗的質(zhì)量保證工程師負責質(zhì)量保證任務(對于敏捷軟件組織，一個龐大的QAG是不適合的)，承擔追蹤員的職責和教練在質(zhì)量管理方面的職責。其目的也是實現(xiàn)軟件質(zhì)量管理目標。

　　4. 結(jié)論

　　極限編程的核心實踐活動本身提供了適用于敏捷軟件開發(fā)方式的一整套質(zhì)量控制方法，設(shè)立質(zhì)量保證角色，或者重視發(fā)揮“教練”和“追蹤員”兩個角色的作用，在對程序員的“信任”和“控制”之間建立平衡，是確保質(zhì)量控制過程的實施，使極限編程方法既保持敏捷又能成為高度成熟軟件過程的關(guān)鍵。

　　參考文獻

　　[1] Martin Fowler. The New Methodology[C/OL], http://www.martinfowler.com/articles/newMethodology.html, 2003-04

　　[2] Beck Kent. Extreme Programming Explained: Embrace Change[M]. Boston: Addison-Wesley,1999.

　　[3] Mark C.Paulk. Extreme Programming from a CMM Perspective[J]. IEEE Software,2001,18(6):19-26.

　　作者簡介

　　袁靜，女，高級工程師，碩士，1992年畢業(yè)于國防科技大學計算機軟件專業(yè)，主要研究方向：軟件工程。曾制定西安衛(wèi)星測控中心軟件工程以及軟件過程規(guī)范，負責神舟飛船測控軟件的質(zhì)量保證工作。2002年9月 ——2003年9月于英國謝菲爾德大學計算機科學系作訪問學者，進行極限編程方法研究，同時任該校學生極限編程項目組顧問。