敏捷開發方法-極限編程XP
2025-02-10 15:35:59 3 檢舉
登入查看完整內容
此心智圖為《敏捷開發方法-極限編程XP》的介紹。極限編程（XP）是由肯特·貝克等人創始的一種軟體工程方法學，強調適應性而非可預測性。其目標是降低需求變更帶來的成本，並通過短交付周期、結對編程等12個核心實踐來實現。XP注重溝通、簡單、反饋和勇氣四大價值，並以快速回饋、假設簡單等五個原則為指導，以應對快速變化的開發環境。
作者其他創作
大綱/內容
极限編程的4個價值
溝通
一個軟體系統的基本任務之一
與系統的開發者交流以明確系統的具體需求
目標是向所有開發人員提供一個對於系統的共享的視角，
而這一視角又是與系統的最終用戶的視角相吻合的
而這一視角又是與系統的最終用戶的視角相吻合的
鼓勵經常性的口頭交流與回饋
簡單
從最簡單的解決方式入手
透過不斷重構達到更好的結果
只專注於對當前的需求來進行設計、編碼，
而不去理會明天、下周或者下個月會出現的需求
而不去理會明天、下周或者下個月會出現的需求
未來的需求在他們還沒提出之前是很可能發生變化。
設計與代碼上的簡化可以提高交流的質量
反饋
回饋越快越好
「反饋」與系統開發的
許多不同方面相關聯
許多不同方面相關聯
來自系統的反饋
單元測試
直觀地得到經過修改後系統的狀態
來自客戶的反饋
功能性測試
客戶還有測試人員編寫
得知當前系統的狀態
計劃2、3個禮拜進行一次
客戶可以非常容易地了解、掌握開發的進度
來自小組的反饋
客戶帶著新需求來參加項目計劃會議
小組可以直接對實現新需求所需之時間進行評估然後反饋給客戶
反饋是與「交流」、「簡單」這兩條價值緊密聯繫的
溝通系統中的缺陷
編寫單元測試
簡單的證明某一段代碼存在問題
使用者根據既定的功能需求，對系統進行周期性的測試。
在程式設計中的樂觀主義是危險的，而及時反饋則是解決它的方法。
Kent Beck
勇氣
只為今天的需求設計以及編碼，
不要考慮明天。
不要考慮明天。
避免陷入設計的泥沼、而
在其他問題上花費了太多不必要的精力
在其他問題上花費了太多不必要的精力
在需要重构他們的代碼時能感到舒適
重新審查現有系統並完善它
未來出現的變化需求更容易被實現
了解何時應該完全放棄現有的代碼
花了一整天的時間糾纏於自己設計和代碼中的
一個複雜的難題卻無所獲
一個複雜的難題卻無所獲
第二天以一個全新而清醒的角度來考慮
在半小時內就輕鬆解決
極限編程的5個原則
快速回饋
反饋即時、迅速
客戶
在整個開發過程中及時提供反饋意見
在需要的時候能夠掌控系統的開發方向
單元測試
同樣對貫徹反饋原則起到作用
假設簡單
任何問題都可以「極度簡單」地解決
傳統的系統開發方法
考慮未來的變化
考慮代碼的可重用性
極限編程拒絕這樣做
增量變化
羅馬不是一天建成的
例如
每三個星期發布一個包含小變化的新版本
一步一步前進的
擁抱變化
不要對變化採取反抗的態度，而應該擁抱它們
例如，在一次階段性會議中客戶提出了一些看似戲劇性的需求變更。
作為程式員，必須擁抱這些變化，
並且擬定計劃使得下一個階段的產品能夠滿足新的需求
作為程式員，必須擁抱這些變化，
並且擬定計劃使得下一個階段的產品能夠滿足新的需求
高品質的工作
四個軟體開發的變數
範圍
時間
成本
質量
只有質量不可妥協
極限編程
極限編程
極限編程
縮寫為XP
一種軟體工程方法學
不同
更強調可適應性而不是可預測性
創始者
肯特·貝克、沃德·坎寧安
羅恩·傑弗里斯
極限編程的目標
降低因需求變更而帶來的成本
系統需求是在項目開發的開始階段就確定下來
當項目開發進入到後續階段時出現的需求變更將導致開發成本急速增加，而在一些發展極快的領域中，這樣的變更是不可避免的。
透過引入基本價值、原則、方法等概念
降低變更成本的目的
极限編程的12個核心實踐
短交付周期
和Scrum一樣採用迭代的交付方式
每個迭代1-3週時間
迭代結束
團隊交付可運行的，經過測試的功能
這些功能可以馬上投入使用
計劃遊戲
兩個問題
預測在交付日期前可以完成多少工作
現在和下一步該做些什麼
不斷地回答這兩個問題
針對兩個問題兩個相應過程
軟件發佈計劃（Release Planning）
根據開發成本、風險和每個需求的重要性，訂定一個大致的項目計劃。
最初的項目計劃沒有必要（也沒有可能）非常準確
周期開發計劃（Iteration Planning）
開發過程中
有很多階段計劃
比如每三個星期一個計劃
在某個周期對系統進行內部的重整和優化（代碼和設計）
某個週期增加了新功能
會在一個周期內同時做兩方面的工作
有利有弊
好處
客戶可以立即知道
完成了哪些
做出來的東西是否合用
面還要做些什麼或改進什麼等
壞處
看到做出嚟的東西，可能會好唔滿意甚至中止合約
為了及早發現問題、解決問題
結對編程
兩個人坐在一台電腦前一起完成
一位程式設計師操控電腦，並且主要思考編碼的細節。
另外一個人主要關注整體結構
不斷地對第一個程式員寫的代碼進行評審
結對不是固定的
可持續的節奏
長期維持的速度努力工作
保存精力
把項目看作是馬拉松長跑
而不是全力短跑
代碼集體所有
每個人對所有的代碼負責
每個人皆可更改代碼的任意部分
結隊程式設計對這一實踐貢獻良多
在不同的結隊中工作
所有的程式設計師都能看到完整的代碼
編碼規範
所有人都遵循一個統一的編程標準
所有的程式碼看起來好像是一個人寫的
簡單設計
沒有那種傳統開發模式中一次性的、針對所有需求的總體設計
設計過程幾乎一直貫穿著整個項目開發
從製訂項目的計劃
到制定每個開發周期（Iteration）的計劃
到針對每個需求模塊的簡潔設計
到設計的複核
以及一直不斷間的設計重整和優化
整個設計過程是個螺旋式的、不斷前進和發展的過程
測試驅動開發
重構
系統隱喻
持續整合
XP開發小組用很多生動的比喻來描述系統或功能模塊是如何工作的
現場客戶
客戶
不是為系統付帳的人
而是真正使用該系統的人
客戶
隨時在現場解決問題
編寫故事
驗收測試
更頻繁的交流和討論
0 則評論
下一頁
