極限程式設計（Extreme Programming）簡介

  極限程式設計

1.       什麼是極限程式設計

2.       極限程式設計的12大實踐

3.       極限程式設計過程

4.       極限程式設計政策

5.       極限程式設計vsCMMI

1.       極限程式設計

極限程式設計（以下稱XP）是關于軟體開發的新方法論。她是Kent Beck在參與戴姆斯.克萊斯勒公司的一個叫C3的項目時首先提出的。

XP的出現徹底颠覆了軟體工程的某些核心思想。事實證明，在某些客觀情況下，XP理論可以指導開發出高品質的軟體産品并提高生産力。

XP是基于一套并非是最新但卻是非高效的技術上的。XP要讓軟體開發項目充滿樂趣、成效卓著，并且在可控中穩定地為企業創造價值。

1.1        XP基本原理

XP最大化使用所采用的技術，是以稱之為“極限”。

a.       結對程式設計（pair programming）。一人程式設計，另一人同時在一旁審查代碼。

b.       客戶參與測試。

c.       每個程式員都成為架構師。

d.       一天數次內建測試。

e.       數周或數天一次疊代。

f.        區分商業利益和項目負責人的決策、總在程式設計之前編寫單元測試并讓所有測試保持在運作狀态、內建并測試整個系統、程式員結對而生産軟體、從簡單的設計開始項目并不斷改進以增加必要的靈活性與去除不必要的複雜性、将最小的系統迅速投産并朝證明其價值的方向發展。

“極限程式設計隻是适合于那些需求不明或需求變化快的項目中的小開發團隊的方法論。”

                                                           -- Kent Beck

1.2        XP的特性

a.       四種價值：溝通、簡便、回報、勇氣。

b.       五個準則：提供回報、簡單設計、增量的改變、熱衷于改變、品質保證工作

c.       十二個實踐：客戶入駐項目組；小的版本；隐喻；測試；簡單設計；精化；結對程式設計；計劃；每周40小時工作；持續內建；确定代碼的所有權人；程式設計規範。

1.2.1          四種價值

a.       溝通（communication）：一個項目不論是項目組與客戶之間，還是開發人員之間都需要持續的溝通。

b.       簡單（simplicity）：把一系列的工作習題簡單化。簡單明了的設計便于以後的擴充。

c.       回報（feedback）：不斷從客戶那裡擷取回報，做疊代式開發。基于測試案例的開發（Test-base programming），即先開發測試案例，再寫代碼。

d.       勇氣（courage）：綜合了上述三種價值後，我們必定是幹勁十足的，無畏的。

1.2.2          五條準則

a.       快速回報（rapid feedback）：在極限程式設計項目中，開發者盡可能快速的提供和擷取回報。

b.       簡單設計（assume simplicity）：隻為目前的疊代做設計。要求每個人做計劃，設計重構。做測試以保證将來可以加入更複雜的需求。

c.       增量式變化（incremental change）：需求、設計、代碼等等，在每次解決問題時隻對這一系列的步驟做微小的同步的改動。對于XP方法論的采用也是漸進的。

d.       包容變化（embrace change）：

e.       質保工作（quality work）：

1.3        XP是獨特的

在短的疊代中及早地，具體地，持續地回報。

增量地計劃步驟。

基于不斷變化的需求彈性的執行進度表。

信任程式員寫的測試用例。

信任程式員的團隊協作。

1.4        問題

a. 什麼是極限程式設計？

極限程式設計隻是适合于那些需求不明或需求變化快的項目中的小開發團隊的方法論。

b. 極限程式設計的四種價值？

溝通，簡潔，回報，勇氣。

2.     極限程式設計的12種實踐

2.1      現場客戶

很多軟體項目的失利都緣于對未能正确表述客戶的需求。真正的客戶應該成為項目團隊的一員，由他來定義客戶需求，回答并解決需求相關的問題，将功能排出優先級。

2.2      小的釋出版本

先實作重要的功能。短的疊代周期，制訂一到兩個月的疊代計劃肯定比六到十二個月的疊代計劃更容易。

2.3      暗喻/架構

将整個系統聯系在一起的全局視圖；它是系統的未來影像，是它使得所有單獨子產品的位置和外觀變得明顯直覺。如果子產品的外觀與整個隐喻不符，那麼你就知道該子產品是錯誤的。

2.4      測試

自動測試驅動。

在編碼之前寫測試用例。

随時做單元測試與內建測試。

單元測試必須百分之百地通過。

2.5      簡單設計

簡單但須正确：能跑通所有的測試用例；代碼重用性非常高；類和方法越少越好；實作目前的所有功能需求。隻為今天而不是為将來作設計。

2.6      精煉

重構的系統裡不能包含正在改變的功能。

目标：保持設計簡潔。如果發現不合理的設計就修改，删去那些無用的代碼。

2.7      配對程式設計

兩人同時使用一台機器程式設計。一個寫代碼，另一人則考慮如何改進。

兩人的角色随時可以更換。

好處：沒有人在任何方面是内行，是以可以在工作中學習，并持續的檢測。

缺點：浪費開發時間。兩人之間不易管理。

2.8      設計

需求判定：開發的範圍，功能優先級，各版本的内容，各版本的釋出日期

技術判定：各功能子產品完成所需的時間估算，詳細闡述需求判定的結果，團隊的組織架構，進度表。

2.9      每周40小時工作時間

開發人員按時下班。任何逾時工作的項目都需要精簡，重新設計，重新做計劃。

2.10   集體代碼所有權

任何結對的程式員都可以在任何時候改進任何代碼。沒有程式員對任何一個特定的子產品或技術單獨負責，每個人都可以參與任何其它方面的開發。

2.11   持續內建

代碼完成後數小時，便開始做內建。将代碼釋出內建到目前的項目中去。運作所有的測試用例。

2.12   編碼規範

開發團隊必須統一采用編碼規範。

2.13   問題

XP的12個實踐是什麼？

簡單設計，每周40小時工作時間，持續內建，測試，設計，配對程式設計，現場客戶，編碼規範，集體代碼所有權，精煉，暗喻，小的釋出版本。

3.     極限程式設計過程

4.     XP的政策

4.1      管理政策

解釋給最高決策層聽。

管理政策 – 圓桌會議

4.2      XP管理中的角色

a.     項目經理：直接面向客戶，組建團隊，擷取資源，管理團隊及處理問題。

b.     跟蹤者：提醒團隊的工作必須與需求相符；該角色應該是由項目組成員兼職的。

c.     XP專家：幫助團隊使用與了解XP方法，指導團隊，幫助團隊的工作保持在可跟蹤範圍内。

d.     視團隊規模而定，以上三個角色可以是一個或者多個人。

4.3      靈活政策

a.     開放的工作環境。

b.     辦公桌位于辦公室的中央。

c.     辦公區的四周有很多小的辦公室。

d.     屋子給人的感覺很不錯。

4.4      計劃政策

a.     隻制訂一個計劃針對于下個版本。

b.     可行的責任。

c.     估算出每個成員的職責。

d.     在計劃中區分出優先級。

4.5      計劃：使用者平時的工作流水（User Stories）

a.     必須由真正的使用者來寫

b.     比之真正的需求說明書要簡單的多。而且裡面不附帶任何技術方面的東西。

c.     對使用者來說最最核心的需求要先被開發出來。

d.     流水模闆

e. 疊代：預估每個流水的實作時間為1到3周；根據流水的重要性來排出次序；根據流水的複雜程式把每次疊代時間控制在1到3周。

f. 版本：這些版本都是開發團隊重複地釋出給客戶去驗收測試的。在每次疊代結束後釋出；一個可運作的內建系統。

4.6      疊代細分

a.     每個疊代都被細分為一個流水的若幹個代碼實作的任務。

b.     每個代碼實作的任務在1到3天内完成。

c.     每個結對程式設計小組選擇一個或多個任務。

d.     每個小組開始設計測試用例然後逐漸去實作。

4.7      XP計劃概述

4.8      設計政策 – 規則

a.     采用最簡單的方法去實作。一個簡單的系統更容易了解和維護。

b.     采用CRC Card。Class Responsibilities and Collaboration Card。設計系統的架構。讓整個團隊參與設計。每個CRC Card描述一個個體對象。

c.     選擇一個系統架構。

d.     建立一個架構核心解決方案來規避風險。

e.     不要過早的加上一些功能。其實使用者使用最多的也隻有系統中的10%的功能。是以你隻需要專注于你今天的事情。

f.     精簡：随時随地的準備以更簡單的解決方法去替換複雜的。

設計規則小結：使每件事情盡量簡單清晰；精簡；緊跟計劃。

4.9      開發政策

a.     代碼的集體所有權：讓每個人的代碼共享給開發組。

b.     編碼規範。

c.     編碼之前先寫測試用例。

d.     持續內建。

e.     每周40小時工作時間。

f.     結對程式設計：所有的代碼都是同兩人肩并肩完成的；編碼人員操作鍵盤；觀察人員在一旁指出缺陷并思考政策；兩人角色互換。

結對程式設計的優勢：兩個大腦總比一個強；兩人解決問題的思路肯定更開闊；可供選擇的設計增多；代碼品質更高；至少有兩個人知道系統的各個部分的細節；對項目組的新人而言是一種更有效的學習機制；雙倍的壓力。

    開發政策小結：編碼之前寫測試用例；代碼集體所有權；編碼規範；持續內建；結對程式設計；每周40小時工作時間。

4.10   測試政策

a.     單元測試。開發人員負責自己的單元測試用例開發。

b.     內建測試。所有之前跑通的單元測試用例全部重跑一遍以檢驗整個系統可以運作。

c.     代碼內建。

d.     驗收測試。對照使用者工作流水來做驗收測試；黑盒測試。

測試政策小結：

4.11   客戶

a.     實用性強的客戶。現場客戶。

b.     義務。寫流水；定義流水優先級；定義各版本的範圍與釋出時間。

4.12   客戶與程式員角色

a.     客戶決定“你得到什麼”以及：系統的功能範圍；系統各部分的優先級；各版本應包含的内容；各版本的釋出日期

b.     程式員決定“需要什麼成本”以及：新增一個功能的時間預估；程式員解釋涉及技術的順序，但最終決定權在客戶；團隊如何工作；每個疊代的詳細進度

5.     極限程式設計vs. CMMI

5.1      XP的優勢

a.     更适于需求與功能的變化。

b.     小的開發團隊。

c.     客戶與項目經理決定輸入。

d.     易測性。

e.     XP是根據面向對象程式設計思想設計的。

5.2      采用XP

a.     綜合各家技術之所長。

b.     逐漸采用。選擇項目中最糟糕的問題，應用XP中相應的技術去解決。

c.     必須經常回頭整理工作的各個方面。

d.     确定合同的範圍。

5.3      對XP普遍的誤解

a.     不寫設計文檔。

b.     沒有設計。

c.     XP是很簡單的。

d.     XP是不穩定的。

5.4      CMMI之于XP

a.     很多CMM/CMMI中的PA是XP中沒有涉及或隻是部分涉及到的。即使沒有被明确的指出來，XP在沒有管理及其他支援的情況下也是不能生存的。

b.     比較公正的說法，XP專注于技術層面而CMM/CMMI更關注項目管理層面的事。

5.5      問題

XP與CMMI具有什麼樣的關系？

XP與CMM沒有沖突。而在實踐中，兩者沖突比較明顯。

以需求為例：CMM要求有方法論得到文檔化的需求。

XP重視疊代，現場使用者快速回報。使用者故事+程式反映需求。

以計劃為例：CMM要求有全面的開發計劃，工期，工作量，項目規模，CCR等要作出估算。

而且估算要有依據，而XP中沒有如此要求，相反采用快速簡單計劃的方式來進行。

最根本的關鍵還在于兩者對工程師的态度上。

XP鼓勵工程師自由發揮。

而CMM要求工程師根據既定的方法論，使用指定的工具，完成指定格式的工作産品，并且接受監督。

是以XP工程師往往難于接受CMM的各項規定。

而CMM組織也不會全盤采用XP。完全附合CMM的XP是違背XP原旨的XP。不值的這樣做。