Extreme Programming 採取較為謹慎且規範化的軟體開發程序。方法論研究者 Alistair Cockburn 將 XP 視為具備輕量級、低儀式性、高規範性等特質的方法論。這個方法強調團隊作業,管理者、客戶、開發人員,都是達成高品質軟體的一部份,缺一不可。XP 以簡單卻有效的方法,實現以團隊為基礎的開發程序。
XP 改善軟體專案開發的方法有四:溝通、簡化、回饋與無懼。這四個環節彼此相扣。開發人員彼此之間,以及與客戶間進行溝通,讓設計維持簡單與清晰。開發過程必 須不斷地進行測試,從中得到回饋,儘早將系統交付客戶,實現對方建議的更動。以此為基礎,開發人員得以勇敢地因應需求與技術上的變更。
在軟體專案的適用性上,XP 適合大約在 2 至 12 人之間,較小的開發團隊。不過成功案例中也包括 30 人的大型專案。XP 特別適合應用在需求經常更改的領域,例如客戶本身對於系統並無確定概念,或系統的功能若干月即會發生變動。在不少軟體環境中,需求的不確定性可能是其中唯 一可以肯定的事,這是 XP 最佳的切入點。
XP 要求讓客戶加入開發過程,將時程規劃的權力交付給客戶。同時,XP 也讓開發人員有評估開發作業的權力。客戶透過 User Story 表達希望達成的功能,開發人員則評估在這些功能上所需耗費的時間,以及在一定時間內可以完成的比例。客戶依此決定功能完成的順序,以及何時與多久釋出可運 作之系統。
小範圍的釋出,是 XP 相當強調的概念。開發工作應基於最小的可運作功能集合,不必要的冗額功能不應該事先進行開發。儘早並經常釋出,每次釋出只增加少許功能。為了達成儘早與經 常釋出,簡化的設計是必要的。XP 要求使用可達成目標的最簡單設計,由於目前的需求到了明天有可能就會改變,所以只需做那些可滿足今日要求所需的 工作。
XP 由簡單的規則與實踐規範所組成,其中包括 12 條核心實踐規範。XP 在實踐規範中明確地指出測試的重要性。簡言之,整個 XP 開發流程都離不開測試程序。測試在 XP 中分成兩個層面:單元測試(Unit Tests)與接受度測試(Acceptance Tests,又稱為功能測試,Functional Tests)。
單元測試是由開發者自行發展的自動化測試程序,目的在於測試程式碼的功能性。單元測試一般僅測試單一或小部份類別。單元測試多以單元測試架構,加以完成。
接受度測試由客戶加以規範,測試整體系統是否如預期。此類測試以客戶定義的 User Story 為基礎,當某 User Story 相關的所有接受度測試都已通過,表示該 User Story 已告完成。
XP 提出了某些在實際開發程序中,容易被人忽略的規範。對於開放源碼專案來說,盡管開放源碼專案缺乏正式的客戶,同時也免於預算與時程的壓力,但 XP 仍然對這類專案具有參考與應用價值。開放源碼同樣必須重視測試的價值,特別是客戶的接受度測試。目前 XP 的測試工具皆屬開放源碼,藉由這些工具,測試將更容易實行。不論除錯或新增功能,開發者應對手中的程式碼加以測試。
沒有預算壓力雖然使開放源碼專案多半可免於嚴苛的釋出期限,然而經常自使用者與客戶取得回饋,對於專案的存活卻至關重要。專案前進的步調越小越好,將每次 的更動最小化,如此不僅可減少測試與除錯的規模,也可降低各更動間的整合作業,此外,也有益於定期釋出。Subversion 便是最好的範例。Subversion 每隔三星期會釋出新的 snapshot,同時擁有 beta 與 final 釋出版本的相關目標。
簡言之,XP 的目標是讓軟體專案開發流程簡化,讓龐大的開發工作分成許多較小單元,使得開發時程更容易預測與規劃。專案得以盡早且經常釋出,獲取使用者的回饋,針對使 用者的需求更改專案的進行。Subversion 是專案管理上一個相當好的範例,該專案有著良好的測試程序,重用其他專案的優良程式碼,並擁有穩定、可預測的釋出時程。XP 提出的規範也許不是全新的,但絕對足以有著開放源碼專案得以參考與加以實際應用的地方。
相關網址: