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

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

3、arch, 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, Simplicity

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

5、ded 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替代詳細(xì)的用戶需求規(guī)格說明書o由用戶書寫，類似于用戶“場景”，但不局限于界面的描述o沒有技術(shù)術(shù)語o能夠成為驗收測試的依據(jù)Release planningo通過召開 release pla

6、nning meeting 來制訂一份發(fā)布計劃o發(fā)布計劃詳細(xì)描述用戶所要求的各版本要求，這為后面的迭代計劃打基礎(chǔ)small releaseso經(jīng)常向客戶發(fā)布系統(tǒng)的迭代版本o在release planning meeting上確定哪些功能單元對用戶業(yè)務(wù)有重要影響并可在早期加入到系統(tǒng)中o越晚向用戶介紹系統(tǒng)的重要特征，開發(fā)隊伍所獲得的“搞定”系統(tǒng)的時間就越短。Project Velocityo項目周轉(zhuǎn)時間是衡量項目工作進(jìn)度速度的值。o“負(fù)載因子”近期被引進(jìn)用于項目周期的測量Iterationso迭代式開發(fā)增加了開發(fā)過程的敏捷性o將總體進(jìn)度劃分為一系列長度為1-3周的小的迭代過程. 迭代周期固定且一致

7、，成為項目的“心跳” 。Iteration planningo在每個迭代的開始召集迭代計劃會議，明確本次迭代任務(wù)o每次迭代1-3周長o由用戶在 User stories中確定最有價值的特征作為本次迭代的目標(biāo)o上次迭代時沒通過驗收測試的特征應(yīng)當(dāng)加入本次迭代Move people aroundo讓所有人多掌握技能，避免知識孤島和開發(fā)瓶頸o交叉培訓(xùn)，“結(jié)對編程”o并非一個人掌握所有的代碼，而是要每個人掌握大多數(shù)的代碼，所需要的人員可以隨時被指派到最需要的地方，實(shí)現(xiàn)人員的“負(fù)載平衡”o每次迭代每個人試圖做系統(tǒng)新的部分，Pair programming 能夠保證這種形式stand-up meetingo

8、目標(biāo)：在整個開發(fā)組（而非個別開發(fā)人員）中進(jìn)行溝通o每天早上一次站立會議，主要溝通問題、方案，以集中小組注意力o避免了策劃會議的時間odaily stand up meeting 不同于一般浪費(fèi)時間的會議Fix XPo一旦破壞了XP流程，就馬上更正！o可根據(jù)具體項目制定XP規(guī)則，一旦制定就必須執(zhí)行，直到規(guī)則變更o所有人員都明確知曉規(guī)則DesigningoSimplicity.o Choose a system metaphor.o Use CRC cards for design sessions.o Create spike solutions to reduce risk.o No func

9、tionality is added early.o Refactor whenever and wherever possible. Simplicity is the Keyo決不增加沒有列入到進(jìn)度中的功能o“簡單化”其實(shí)并不簡單system metaphoro為系統(tǒng)選擇一種metaphor使得開發(fā)小組能夠為類及方法進(jìn)行統(tǒng)一的命名. o命名方式易理解.CRC cardsoClass, Responsibilities, and Collaboration (CRC)oCRC cards的最大價值在于引導(dǎo)開發(fā)人員擺脫過程模型，精確掌握OO技術(shù)oCRC Cards 允許所有的人參與設(shè)計，參與的

10、人越多，就會有更多的好的主意引入spike solutionso創(chuàng)建關(guān)鍵問題解決方案，解決關(guān)鍵的技術(shù)和設(shè)計問題o大多數(shù) spikes可能都不足以得到保持，有可能被丟棄. 但制作SPIKE的目標(biāo)降低技術(shù)風(fēng)險；o一旦技術(shù)困難對系統(tǒng)的開發(fā)造成了威脅，立即派一對開發(fā)人員關(guān)注于該問題一至兩周，以降低潛在的風(fēng)險No functionality is added earlyo切記不要實(shí)施你認(rèn)為日后有用的額外特征o只有10% 的額外特征會有用o只關(guān)注目前進(jìn)度中所要求的內(nèi)容Refactor whenever and wherever possibleo隨時隨地可以對已做過的事重新考慮o毫不留情地將設(shè)計、編碼簡單

11、化，簡單得足夠容易理解、修改和擴(kuò)展o所有的事只表達(dá)一次o修飾得太好的系統(tǒng)往往到后期趕不上進(jìn)度要求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.o Integrate often.o Use collective code ownership.o Leave

12、optimization till last.o No overtime. The customer is always availableo隨時能聯(lián)系客戶是XP方法的基本要求之一oXP的所有階段都要求客戶的強(qiáng)參與o最好有客戶派員直接參與開發(fā)組o把客戶“吊住”，并將客戶由新手培養(yǎng)成為專家，開發(fā)組需要專家Code must be written to agreed standardso所有代碼必須采用統(tǒng)一標(biāo)準(zhǔn)以便理解oSmalltalk projects ： Smalltalk Best Practice PatternsCode the unit test firsto創(chuàng)建單元測試能夠幫助開發(fā)

13、者清醒地意識到什么是真正需要的o需求是由測試活動明確下來的All production code is pair programmedo所有發(fā)布的代碼都由兩個程序員在一臺機(jī)器上共同開發(fā)完成。o結(jié)對編程的最好方式是兩人共同坐在顯示器前，將鍵盤和鼠標(biāo)在兩人之間“滑動”，一人考慮所創(chuàng)建的方法（Method），而另一人同時考慮該方法如何在類中得到更好的體現(xiàn)。o適應(yīng)結(jié)對編程需要時間，必須度過開始面臨的尷尬境況Sequential Integration o每次加入一個模塊做集成 Integrate ofteno開發(fā)人員應(yīng)不斷地將代碼集成到代碼庫中，幾小時一次，絕不超過1天o每個人需要在最后的版本上工作o

14、持續(xù)集成能夠在早期避免或發(fā)現(xiàn)一些兼容性問題?！艾F(xiàn)在付錢還是以后付更多的錢？” Use collective code ownershipo“集體擁有代碼”鼓勵每個人對項目的所有部分提出新想法o任何開發(fā)人員都可改變?nèi)魏未a以增加功能、修改錯誤o沒有人會成為變更的瓶頸Leave optimization till lasto在項目快結(jié)束之前不要去優(yōu)化o永遠(yuǎn)不要試圖猜測系統(tǒng)的瓶頸在哪里，去度量它、讓系統(tǒng)動起來、修正系統(tǒng)、去讓系統(tǒng)變的更快！No overtime.o超時工作會吞噬開發(fā)組的精神和熱情o利用版本計劃會來改變項目的范圍和時間要求o項目進(jìn)度拖延時通過增加資源來改進(jìn)也不是推薦的方法Testing

15、o 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 testso單元測試是XP方法中的小界石，但與傳統(tǒng)的單元測試略有不同o1、要創(chuàng)建或下載一些單元測試工具以便能夠自動生成測試數(shù)據(jù)o2、測試系統(tǒng)中所有的類o3、單元測試應(yīng)與其所測試的代碼一起發(fā)布o(jì)4、沒有單元測試的代碼不能發(fā)布o(jì)5、若發(fā)現(xiàn)沒有進(jìn)行單元測試，則立即開始進(jìn)行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每一次迭代時的迭代計劃會都應(yīng)選取適當(dāng)?shù)?us