敏捷開發大家談（四）

（五） Extreme Programming

Extreme Programming（XP，極限程式設計） 是一種輕量級的軟體開發方法，它使用快速的反饋，大量而迅速的交流，經過保證的測試來最大限度的滿足使用者的需求。XP強呼叫戶滿意，開發人員可以對需求的變化作出快速的反應。XP強調team work。專案管理者，使用者，開發人員都處於同一個專案中，他們之間的關係不是對立的，而是互相協作的，具有共同的目標：提交正確的軟體。XP強調4個因素：
交流(communication)，XP要求程式設計師之間以及和使用者之間有大量而迅速的交流
簡單（simplicity），XP要求設計和實現簡單和乾淨
反饋（feedback）通過測試得到反饋，儘快提交軟體並根據反饋修改
勇氣（courage）。勇敢的面對需求和技術上的變化

XP特別適用於需求經常改變的領域，客戶可能並系統的功能並沒有清晰的認識，可能系統的需求經常需要變動。
XP也適用於風險比較高的專案，當開發人員面對一個新的領域或技術時，XP可以幫助減低風險
XP適用於小的專案（人員上），人員在2-12人之間，XP不適用於人員太多的專案，事實上，在需求經常變化或風險比較高的專案中，少量而有效的XP開發人員效率要遠遠高於大量的開發人員。

下面是XP的開發流程


XP的原則和實踐：

1 Planning:

1)user stories。
User stories類似use case，描述使用者所見的系統功能，但避免使用大量的文件，user stories由使用者編寫（不僅限於描述使用者介面）。User stories使用使用者的語言編寫，不使用技術性的語言，每個user stories限於幾句話。User stories用於在release plan會議上對開發時間進行評估，也用於產生驗收測試（acceptance test），必須使用可以自動進行的驗收測試保證軟體的正確性。User stories與傳統的使用者需求的區別在於詳細的程度，user stories並不會確定需求的每個細節，它只是用來簡單的描述系統功能，供開發人員進行估計開發進度，

在開發過程中開發人員和使用者會不斷的交流以討論細節問題。User story應該專注於功能，不應該過分注重使用者介面等細節。一般一個user storiy在1-3周的時間完成，如果估計超過3周，說明user story太大了，需要細分。

2)release plan.
召開一個release plan會議，產生release plan。Release plan將用於指定每個iteration的計劃。開發人員對每個user story估計開發時間（在不被打斷，無其他工作情況下的開發時間，包括測試），使用者對user stories給出優先順序，release plan會議並不制訂每個iteration的計劃。Release plan要使用者，開發人員和管理者都同意，在完成功能範圍（scope），使用資源（resource）,時間（time）和質量(quality)上達成一致（一般質量是不能改變的）

3) small release
often and small release是XP的一個原則，每個release完成一些使用者有意義的功能集合，儘快的提交給使用者以獲得反饋，及時調整，提交的越晚，調整越困難。
4）project velocity
團隊在開發過程中要收集資料，以便於對自己的開發速度進行評估，用於以後的releazse plan

5)iteration
每個small release的週期稱為iteration，每個iteration約為1-3周，在一個專案中保持每個iteration的時間相等，不要超前制定計劃，每個iteration的計劃在iteration的開始時制定。這樣能夠更靈活的應付變化。不要急於完成本次iteration沒有包括的功能。要注重每個iteration的時間限制，當團隊覺得不能按時完成iteration時，召開一次iteration plan會議，重新評估，減少一些user stories。

下面是iteration的圖示：

 

6）iteration plan
在每個iteration開始的時候召開會議，從release plan中選擇還沒有實現的使用者最迫切需要的user stories。上一個iteration中沒有通過驗收測試的功能也要在這個iteration中實現。可以根據上一個iteration的實踐調整團隊速度。User stories和失敗的測試被分解成programming task，task使用技術語言編寫，作為iteration plan的詳細描述。程式設計師主動領取task並估計完成時間，每個task應該在1-3天內完成，超過3天的task應該被細分。如果整個團隊需要的時間多於或少於規定的iteration時間，調整user stories。

7）move people around
不要使每個開發人員侷限於一項工作，不要使某項工作依賴於一個開發人員，增加知識共享，減少資訊孤島，多進行交流和培訓。當專案中的所有人對所有模組都瞭解並可以進行開發時是效率最高的，鼓勵開發人員在不同iteration中開發不同的模組。

8) stand-up meeting
每天工作開始之前，開5-10分鐘的stand-up會議（站立會議），站立的目的是為了強迫節省時間，會議的目的是交流，提出存在的問題，但不要在會議上解決問題。開一個所有人員參加的短會比多個個別人員參加的會議要高效。在會議上提出的問題可以由少數人討論解決，這個少數人參加的會議如果涉及到程式碼，可以在計算機前討論。

9) fix XP when it breaks
XP並不是一成不變的，當團隊覺得需要修改的時候，可以根據自己的情況進行修改，任何修改都要經過整個團隊的討論和達成一致

2 Designing

1) Simplicity
保持簡單的設計，在完成同樣的功能的情況下，選擇簡單的設計，不要急於設計沒有計劃的功能，應該認識到：keeping a design simple is hard work

2）system metaphor
使用統一的術語描述系統，在使用者，管理者和開發人員之間使用統一的術語。這將使交流清晰。

3）CRC card
使用CRC(Class, Responsibilities, and Collaboration) card進行系統設計，鼓勵更多的人參加設計。每個CRC卡片表示系統中一個物件，寫上物件的名字，責任和每個責任需要互動的其他物件。可以模擬物件之間的互動。CRC卡片是易於理解的，但是是非正式的，如果需要正式的文件，要將卡片轉換為相應的文件。

4) spike solution
使用spike solution減低風險，當遇到技術難題或設計問題時，使用簡單的程式進行測試，找出問題，在不同的解決方法之間進行評估。在早期進行實驗可以有效的降低風險。

5）never add function early
不要過早的設計沒有計劃的功能，在一個需求經常變化的環境中，過早的設計經常是沒有用的。

6）refactoringwhenever and wherever
XP鼓勵對設計和程式碼經常進行重構（Refactoring），目的是去除冗餘，提高質量，保持設計簡單。重構必須以完全測試為檢驗條件


3 Coding

1) customer is alaways available
使用者是專案組的成員之一，使用者的參加貫穿整個開發過程，使用者與開發人員之間的交流是重要的

2) coding standard
使用統一的編碼標準，這是保持程式碼整潔和共享程式碼的基礎

3）coding unit test first
test first是XP的一個特點，在編寫程式碼之前先編寫單元測試程式碼，單元測試程式碼和程式碼由同一個程式設計師完成。先編寫測試程式碼可以使程式設計師更好的理解需求，避免直接編碼造成的理解偏差，對需求的不清晰，可以在編寫測試程式碼時就發現。測試程式碼也是檢驗程式是否完成的標準。編碼工作應該是以下工作的迴圈：
1 編寫測試程式碼
2 執行測試程式，確認失敗
3 編寫實現這個測試程式要求功能的程式碼，不需要實現其他的功能，只需要實現剛剛滿足測試程式的功能
4 執行測試程式，確認成功
實踐證明，test first方式需要的編碼實踐少於先編碼，後寫測試程式碼

4) Pair Programming
Pair programming是XP的特色，它要求兩個程式設計師在一臺計算機上同時進行程式設計工作。共用滑鼠和鍵盤，通常一個人進行戰略上的思考，程式架構和函式，類之間的關係，一個人進行輸入和戰術上的思考，完成函式和類。兩個人可以經常交換角色。Pair programming需要一段時間學習和適應，實踐證明pair programming並不消耗更多的時間(人*小時)，但是程式碼的質量得到很大的提高。（避免將兩個新手放在一個pair中）

5）sequential integration
要保證原始碼庫的狀態是可標識的，同一時間，只允許一個pair的程式進行整和和測試，這樣可以縮小問題產生的範圍。不同的pair可以在自己的機器上隨時進行整和和測試.

6) integrate often
只要有可能就進行程式碼整合，週期可以在幾個小時，最好不要超過一天。經常的整合可以避免錯誤的積累，可以增加可重用的程式碼。在一個pair認為適當的時候並通過了所有的unit test，就可以進行整合，整合後的程式碼必須通過測試。同一時間，只允許一個pair進行整合。(整合失敗是不是要退回原有狀態，供其他pair整合？？)

7) 共同擁有程式碼
鼓勵每個人對專案中的任何人提出新的想法，任何開發人員對專案中的任何程式碼都可以進行增加功能，改正錯誤和重構。沒有程式碼或開發人員成為瓶頸。（我的想法：這確實很難理解，但是這確實是我夢想的目標）。為了達到這個目標，任何的程式碼都必須有相應的測試程式碼，任何程式碼的修改必須100%通過測試。必須加強開發人員的交流和知識共享，必須堅持統一編碼標準。Pair programming可以經常交換夥伴。

8）優化工作放在最後
先使系統能夠正常工作，不要猜測系統的瓶頸，要實際測量

9）NO overtime
不要長時間的加班，大多數加班並不能挽回已有的延遲，連續超過兩個星期的加班說明有問題存在。向一個已經延遲的專案填加人員也不是一個好的選擇。

 


4Testing

1)所有的程式碼都有單元測試
單元測試是XP的基石，XP中的單元測試應該是可以自動進行的，所以可以很快的進行所有的單元測試，單元測試應該在編碼之前建立。單元測試的程式碼和程式碼一起release，沒有單元測試的程式碼不能夠release。使用自動單元測試可以系統整合時節省大量的發現錯誤和改正的時間。單元測試越完善，節省的時間越多。對物件導向的程式設計來說，應該對每個類都有單元測試。完善的單元測試也是共同擁有程式碼的保證。單元測試也是可以經常重構的保證，每次重構後的程式碼都要重新進行測試
（這裡的unit test好象不只限於測試某個模組的功能？？？，應該可以測試整合起來的整個系統，這樣才能保證整合的正確性。）

2）程式碼在release前必須通過所有的單元測試

3) 發現bug後，首先增加測試
在實際執行中發現bug,首先增加acceptance test，然後增加unit test，在增加完測試後在查詢和修改程式碼，增加的測試保證同樣的錯誤不會再出現

4) acceptance test
acceptance test根據user stories在iteration plan會議上建立，它也應該可以自動執行以便可以經常執行。User stories是否完成是以是否通過acceptance test為檢驗標準。


XP中的角色：

1 customer 使用者
在XP中，使用者是專案組的一部分，使用者負責編寫use stories，確定優先順序，和開發人員討論需求，編寫accept test，執行accept test，使用者驅動iteration(release plan, iteration plan)

2 開發人員
與使用者討論user stories，估計開發時間，將user stories細化成programming task
編寫unit test
編碼
進行重構
整合及測試，保證100通過

3 manager
負責對外聯絡，組織團隊，獲取必要的資源，管理團隊

4 tracker
跟蹤release plan/iteration plan/acceptance test

5 coach
起顧問指導作用，mentor, monitor and help
A Coach is respected, but also respectful. They’re willing to talk, but also willing to listen. They let the team explore, but provide a guard-rail in case of danger.
監督進展，確保過程和規則，必要時改變過程，幫助解決問題，也可以參加pair programming。
 

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/3433/viewspace-269189/，如需轉載，請註明出處，否則將追究法律責任。