摘要：極限編程是近年來非常流行的敏捷軟件開發(fā)方法，與其它敏捷軟件開發(fā)方法一樣，強(qiáng)調(diào)軟件開發(fā)過程的自適應(yīng)性和以人優(yōu)先的價(jià)值觀[1]，這與傳統(tǒng)的重量級軟件開發(fā)方法強(qiáng)調(diào)對開發(fā)過程的控制相反。那么，敏捷軟件開發(fā)方法能否開發(fā)出高質(zhì)量的軟件產(chǎn)品呢?本文探討在極限編程中如何進(jìn)行軟件質(zhì)量控制，既保持“敏捷”的特點(diǎn)，又能作為一種成熟的軟件開發(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個(gè)價(jià)值觀的一種敏捷軟件開發(fā)方法。它以其13個(gè)核心實(shí)踐為標(biāo)志[2]：

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

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

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

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

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

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

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

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

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

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

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

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

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

　　1.2 軟件質(zhì)量控制

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

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

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

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

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

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

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

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

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

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

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

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

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

　　a) 代碼規(guī)范

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

　　b) 結(jié)對編程

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

　　c) 設(shè)計(jì)重整

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

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

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

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

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

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

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

　　2級 KPA滿足度3級 KPA

　　滿足度高級 KPA滿足度

　　需求管理√√組織過程焦點(diǎn) 軟件過程管理--

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

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

　　軟件子合同管理--集成軟件管理--故障預(yù)防√

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

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

　　同行評審√√

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

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

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

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

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

　　4. 結(jié)論

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

　　參考文獻(xià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è)于國防科技大學(xué)計(jì)算機(jī)軟件專業(yè)，主要研究方向：軟件工程。曾制定西安衛(wèi)星測控中心軟件工程以及軟件過程規(guī)范，負(fù)責(zé)神舟飛船測控軟件的質(zhì)量保證工作。2002年9月 ——2003年9月于英國謝菲爾德大學(xué)計(jì)算機(jī)科學(xué)系作訪問學(xué)者，進(jìn)行極限編程方法研究，同時(shí)任該校學(xué)生極限編程項(xiàng)目組顧問。