1、軟件開發方法-XP宿為民2002年6月6日主題o 什么是XP方法？o 發展沿革o 主要思想o 項目應用案例？什么是XP方法？o eXtreme Programmingo XP 是以開發符合變化的客戶需求的軟件為目標而是以開發符合變化的客戶需求的軟件為目標而產生的一種方法，產生的一種方法， 它的成功得益于它對客戶滿意它的成功得益于它對客戶滿意度的特別強調，度的特別強調，XP 使開發者能夠更有效的響應客使開發者能夠更有效的響應客戶的需求變化，哪怕在軟件生命周期的后期。戶的需求變化，哪怕在軟件生命周期的后期。o 是一種經歷過很多實踐考驗的軟件開發方法是一種經歷過很多實踐考驗的軟件開發方法. . 已經

2、已經被成功的應用在許多大型的公司，如：被成功的應用在許多大型的公司，如：Bayeris che Landesbank , Credit Swis s Life,DaimlerChrysler, First Union National Bank, Ford Motor Company and UBS.發展發展1990s，Kent Beck and Ward Cunningham together had experienced an approach to software development that made every thing seem simple and more effic

3、ient. March, 1996, Kent started a project at DaimlerChrysler using new concepts in software development. The result was the Extreme Programming (XP) methodology. What Kent came to realize is that there are four dimensions along which one can improve any software project, which are Communication, Sim

4、plicity, Feedback, and Courage. These are the four values sought out by XP programmers.The Rules and Practices o Planningo Designingo Codingo TestingPlanningo User stories are written.o Release planning creates the schedule.o Make frequent small releases.o The Project Velocity is measured.o The proj

5、ect is divided into iterations.o Iteration planning starts each iteration.o Move people around.o A stand-up meeting starts each day.o Fix XP when it breaks.User storieso 類似于use cases但不一樣o 用于估計release planning meeting的時間o 替代詳細的用戶需求規格說明書o 由用戶書寫，類似于用戶“場景”，但不局限于界面的描述o 沒有技術術語o 能夠成為驗收測試的依據Release planning

6、o 通過召開 release planning meeting 來制訂一份發布計劃o 發布計劃詳細描述用戶所要求的各版本要求，這為后面的迭代計劃打基礎small releaseso 經常向客戶發布系統的迭代版本o 在release planning meeting上確定哪些功能單元對用戶業務有重要影響并可在早期加入到系統中o 越晚向用戶介紹系統的重要特征，開發隊伍所獲得的“搞定”系統的時間就越短。Project Velocityo 項目周轉時間是衡量項目工作進度速度的值。o “負載因子”近期被引進用于項目周期的測量Iterationso 迭代式開發增加了開發過程的敏捷性o 將總體進度劃分為一系

7、列長度為1-3周的小的迭代過程. 迭代周期固定且一致，成為項目的“心跳” 。Iteration planningo 在每個迭代的開始召集迭代計劃會議，明確本次迭代任務o 每次迭代1-3周長o 由用戶在 User stories中確定最有價值的特征作為本次迭代的目標o 上次迭代時沒通過驗收測試的特征應當加入本次迭代Move people aroundo 讓所有人多掌握技能，避免知識孤島和開發瓶頸o 交叉培訓，“結對編程”o 并非一個人掌握所有的代碼，而是要每個人掌握大多數的代碼，所需要的人員可以隨時被指派到最需要的地方，實現人員的“負載平衡”o 每次迭代每個人試圖做系統新的部分，Pair pro

8、gramming 能夠保證這種形式stand-up meetingo 目標：在整個開發組（而非個別開發人員）中進行溝通o 每天早上一次站立會議，主要溝通問題、方案，以集中小組注意力o 避免了策劃會議的時間o daily stand up meeting 不同于一般浪費時間的會議Fix XPo 一旦破壞了XP流程，就馬上更正！o 可根據具體項目制定XP規則，一旦制定就必須執行，直到規則變更o 所有人員都明確知曉規則Designingo Simplicity.o Choose a system metaphor.o Use CRC cards for design sessions.o Creat

9、e spike solutions to reduce risk.o No functionality is added early.o Refactor whenever and wherever possible. Simplicity is the Keyo 決不增加沒有列入到進度中的功能o “簡單化”其實并不簡單system metaphoro 為系統選擇一種metaphor使得開發小組能夠為類及方法進行統一的命名. o 命名方式易理解.CRC cardso Class, Responsibilities, and Collaboration (CRC)o CRC cards的最大價值

10、在于引導開發人員擺脫過程模型，精確掌握OO技術o CRC Cards 允許所有的人參與設計，參與的人越多，就會有更多的好的主意引入spike solutionso 創建關鍵問題解決方案，解決關鍵的技術和設計問題o 大多數 spikes可能都不足以得到保持，有可能被丟棄. 但制作SPIKE的目標降低技術風險；o 一旦技術困難對系統的開發造成了威脅，立即派一對開發人員關注于該問題一至兩周，以降低潛在的風險No functionality is added earlyo 切記不要實施你認為日后有用的額外特征o 只有10% 的額外特征會有用o 只關注目前進度中所要求的內容Refactor whenev

11、er and wherever possibleo 隨時隨地可以對已做過的事重新考慮o 毫不留情地將設計、編碼簡單化，簡單得足夠容易理解、修改和擴展o 所有的事只表達一次o 修飾得太好的系統往往到后期趕不上進度要求Codingo The customer is always available.o Code must be written to agreed standards.o Code the unit test first.o All production code is pair programmed.o Only one pair integrates code at a time

12、.o Integrate often.o Use collective code ownership.o Leave optimization till last.o No overtime. The customer is always availableo 隨時能聯系客戶是XP方法的基本要求之一o XP的所有階段都要求客戶的強參與o 最好有客戶派員直接參與開發組o 把客戶“吊住”，并將客戶由新手培養成為專家，開發組需要專家Code must be written to agreed standardso 所有代碼必須采用統一標準以便理解o Smalltalk projects ： Smal

13、ltalk Best Practice PatternsCode the unit test firsto 創建單元測試能夠幫助開發者清醒地意識到什么是真正需要的o 需求是由測試活動明確下來的All production code is pair programmedo 所有發布的代碼都由兩個程序員在一臺機器上共同開發完成。o 結對編程的最好方式是兩人共同坐在顯示器前，將鍵盤和鼠標在兩人之間“滑動”，一人考慮所創建的方法（Method），而另一人同時考慮該方法如何在類中得到更好的體現。o 適應結對編程需要時間，必須度過開始面臨的尷尬境況Sequential Integration o 每次加入

14、一個模塊做集成 Integrate ofteno 開發人員應不斷地將代碼集成到代碼庫中，幾小時一次，絕不超過1天o 每個人需要在最后的版本上工作o 持續集成能夠在早期避免或發現一些兼容性問題。“現在付錢還是以后付更多的錢？” Use collective code ownershipo “集體擁有代碼”鼓勵每個人對項目的所有部分提出新想法o 任何開發人員都可改變任何代碼以增加功能、修改錯誤o 沒有人會成為變更的瓶頸Leave optimization till lasto 在項目快結束之前不要去優化o 永遠不要試圖猜測系統的瓶頸在哪里，去度量它、讓系統動起來、修正系統、去讓系統變的更快！No

15、overtime.o 超時工作會吞噬開發組的精神和熱情o 利用版本計劃會來改變項目的范圍和時間要求o 項目進度拖延時通過增加資源來改進也不是推薦的方法Testingo All code must have unit tests.o All code must pass all unit tests before it can be released.o When a bug is found tests are created.o Acceptance tests are run often and the score is published. All code must have unit

16、 testso 單元測試是XP方法中的小界石，但與傳統的單元測試略有不同o 1、要創建或下載一些單元測試工具以便能夠自動生成測試數據o 2、測試系統中所有的類o 3、單元測試應與其所測試的代碼一起發布o 4、沒有單元測試的代碼不能發布o 5、若發現沒有進行單元測試，則立即開始進行All code must pass all unit tests before it can be releasedWhen a bug is found tests are createdAcceptance tests are run often and the score is publishedo 驗收測試來自user stories.o 每一次迭代時的迭代計劃會都應選取適當的