極限編程中的關聯性分析

郭峰

(北方工業大學信息學院，北京 100144)

0 引言

在軟件開發過程中，需求變更幾乎是不可避免的，傳統的軟件過程模型對于需求變更雖然采取了剛性的措施，最早的瀑布模型要求在需求分析階段把需求固定下來，之后不可有變化，體現了對需求變更的不友好甚至是排斥的態度。RUP[1]做為傳統軟件過程模型的集大成者，完美體現了軟件工程系統、規范、可度量的特點，采取迭代、并發等多種措施解決需求的變化問題，但仍然是被動消極的應對方案。在中小型項目中，應用RUP通常存在一定的困難，最典型的問題是按照RUP模型，在整個軟件生命周期內，大部分時間多個任務并發執行，中小型項目在人員分工管理方面通常不足，無法滿足RUP模型的要求。

2001年2月17位著名的軟件專家聯合起草了敏捷軟件開發宣言，標志著敏捷方法的出現。“敏捷”一詞意味著快速、簡單、靈活，敏捷方法代表了一種積極的態度，經典的敏捷方法書籍《解析極限編程》的副標題是擁抱變化[2]，與傳統的軟件過程模型被動消極的態度不同，敏捷方法不排斥需求的變化，強調積極面對需求的變化，采用柔性的手段，通過過程、管理以及實踐盡可能滿足用戶的需求，不看重以合同的形式分割需求的界限。敏捷開發的基本理念是以最簡單有效的方式快速地完成開發任務，在開發過程中針對需要及時響應的外界變化迅速做出調整。

敏捷軟件開發方法不是一個具體的方法，而是一個涵蓋性術語，用于概括那些應需而生的具有類似價值觀的軟件開發過程和開發方法，這些方法通常都具備以人為本、循環迭代、響應變化等特征，更注重能高質量地快速交付客戶滿意的軟件產品，而不強調規范嚴謹的過程和面面俱到的文檔。代表性的敏捷軟件開發方法有：極限編程、SCRUM、特征驅動軟件開發、動態系統開發、自適應軟件開發、Crystal等[3]。

1 極限編程概述

敏捷方法是一類方法的統稱，極限編程屬于敏捷方法中的一種，獲得了較為廣泛的關注，并在實踐中獲得大量的應用。極限編程是一個輕量級的、靈活的軟件開發方法，同時它也是一個非常嚴謹和周密的方法。極限編程包括價值觀、原則和實踐三個部分。極限編程的基礎是4個價值觀念：

溝通-大多數項目的失敗可歸結于溝通不暢，開發人員之間、開發人員和客戶之間都需要積極的多種渠道的溝通，敏捷方法在提高客戶的參與度、增加開發人員的溝通途徑、采用高效率的會議等方式提高溝通的質量。

簡單-敏捷方法強調效率和實用性，首要目標是開發能夠滿足客戶需要的最簡單的產品，需求分析、結構設計、編寫程序和文檔的工作盡可能簡化，避免過度分析過度設計等現象。

反饋-反饋可以讓開發者把握正確的方向，少走彎路。開發者要獲取來自客戶、系統和其他開發者的反饋，并基于反饋改進分析、設計和實現。

勇氣-開發人員對于放棄系統的代碼、改進系統設計等行為通常是謹慎的，敏捷方法強調在必要的時候果斷做出決策。

極限編程在表現形式上是一組簡單、具體的實踐，這些實踐結合在一起形成了一個敏捷開發過程，項目團隊可以直接采用這些實踐，也可以增加一些實踐，或者對其中的一些實踐進行修改后再采用。極限編程在剛剛提出的時候，人們普遍認為它僅適合小型軟件項目的開發，而目前也可將其應用于大中型軟件項目之中。

極限編程的價值觀是極限編程的指導思想，實踐是具體的做法，原則是兩者之間的橋梁，原則依據價值觀指導實踐，是對價值觀的具體的解釋。極限編程的原則包括人性化、經濟學、互惠互利、自相似性、改進、多樣性、反省、連續性、機遇、冗余、及時決策、關注質量、小步前進、接受責任等。

2 極限編程實踐的關聯性分析

敏捷方法的價值觀是：(1)個體與交互重于過程與工具；(2)可以工作的軟件重于面面俱到的文檔；(3)與客戶的合作重于與其合同的談判；(4)對變化的響應重于對計劃的遵循。極限編程的價值觀是溝通、簡單、反饋、勇氣。兩者的價值觀是互通的，是從不同角度的闡述。

圖1 極限編程的實踐對需求變更支持的強度

敏捷方法以及極限編程要解決的一個重要問題就是積極、靈活、有效地處理需求變更。極限編程的核心是12條實踐，這些實踐作為一個整體體現敏捷方法和極限編程的原則和價值觀。如平穩的工作效率體現人性化的原則，更容易使開發人員長期保健康的心理和生理狀態，有利于軟件質量的提高。現場客戶體現與客戶的合作重于合同的談判的價值觀。簡單設計體系可以工作的軟件重于面面俱到的文檔。毫不留情的重構體現勇氣這一價值觀，代碼規范、測試驅動開發、集體擁有代碼相互關聯，才可以保證重構的質量。持續集成、小版本發布使得用戶能夠盡早發現問題，是響應變化的有效措施。

極限編程的實踐有些直接支持需求變更，有些對其他實踐形成支撐，從而間接支持需求變更。圖1描述了這些實踐與需求變更的關系，與需求變更的距離越遠表示實踐對需求變更的支持強度越低。

在傳統的軟件項目中，客戶一般不全程參與軟件開發過程，客戶的任務通常只包括講解需求，測試和驗收軟件系統。在極限編程中，現場客戶實踐要求客戶始終參與軟件開發，并為客戶增加以下任務：編寫用戶故事(User Story)，評估用戶故事的商業優先級，為每個用戶故事設計測試用例，參與開發計劃的制訂，參與開發過程的調控。通過提高客戶的參與度，可以更有效地解決需求變化問題。頻繁發布實踐可以保證客戶能夠有充分接觸待發布產品的機會，從而可以獲得充分的用戶反饋，并以此為依據調控開發過程(通過增加、刪除或改變用戶故事來實現)，在頻繁發布的過程中，所有的發布都要經過功能測試，可有效降低開發風險。計劃游戲的含義是項目計劃建立起來以后，需要根據項目的進展來進行調整。這三條實踐直接支持需求變更，其他實踐通過相互關聯和呼應間接支持需求變更，圖2描述了極限編程12條實踐之間的關聯關系，圖中箭頭表示一條實踐對另一條實踐形成支持。

隱喻使得所有項目參與人員都對相關的抽象概念有統一的、具體的認識，有助于相關人員的溝通，良好的溝通尤其是與客戶的溝通是明確需求的有效路徑。圖中只描述了隱喻對現場客戶的支持，實際上對其他實踐也存在支持關系，在與客戶溝通過程中隱喻的作用更大一些。

極限編程提倡毫不留情的重構(Refactor mercilessly)。由于集體擁有代碼，因此任何人有權利重構任何代碼，只要保證重構后的代碼100%通過單元測試即可。僅僅從重構的名稱上來理解這一條實踐是遠遠不夠的，在代碼規范、結對編程、集體擁有代碼以及測試驅動開發的基礎上才有可能做到極限編程提倡的毫不留情的重構，否則一定要謹慎地對待重構。

計劃游戲意味著開發計劃的調整，需要簡單設計和現場客戶的支持，簡單設計形成的設計方案往往是不完善的，基于不完善的設計方案編寫的代碼需要重構，因此簡單設計需要重構的支持。

圖2 極限編程12條實踐之間的關聯關系

通過結對編程集體擁有代碼才有可能實現，持續集成支持頻繁發布，現場客戶和頻繁發布相互支持，集體擁有代碼支持持續集成和重構。測試驅動開發、結對編程、集體擁有代碼、重構都需要代碼規范的支持。代碼規范是一個很寬泛的概念，但是在極限編程中，代碼不規范將使多個實踐受到影響。

通過這些實踐相互關聯相互呼應，才可以對需求變更不采取排斥的態度，真正做到“擁抱變化”。上述實踐作為一個整體形成極限編程方法，某些方法本質上不是極限編程特有，比如編程規范，在任何軟件項目中都應該遵循，測試驅動開發目前已經稱為流行的軟件開發模式，但是由于這些實踐之間存在關聯關系，只有這些實踐的全部或者大部分都在項目中得以應用，才能發揮極限編程的作用。

3 結語

學習和應用極限編程，通常從12條實踐入手，這些實踐往往可以在軟件開發過程中獨立應用，但是孤立地應用一條或幾條實踐不能有效地發揮其作用，這些實踐相互呼應，才能實現擁抱變化的初衷。本文分析了極限編程12條實踐之間的關聯性，有助于讀者在實際軟件項目開發中更好地學習和應用極限編程，以提高軟件的質量以及開發的效率。