Extreme Programming介绍
Extreme Programming介紹
計劃
?User stories的編寫
?開發計劃的制定
?經常構造版本
?Load Factor因子的確定
?將項目分解為各個迭代期
?每個迭代期開始時制定計劃
?人員集中
?站著開每日晨會
?當實施遇到困難時及時修正XP
設計
?簡單化.
?采用編程規范
?設計時使用CRC卡片
?使用Spike Solution 方法
?不要過早添加新功能
?盡可能保持程序的簡潔性
編碼
?始終獲得用戶的支持
?代碼的書寫必須按照規范
?所有代碼均采用配對開發
?一次只能有一對開發人員進行Release
?代碼經常集成
?代碼共享
?將優化放在最后
?不要加班
測試
?所有代碼均需進行單元測試
?在Release之前所有代碼必須通過單元測試
?Bug發現后應馬上測試
計 劃
l???????? User stories的編寫
l???????? 制定開發計劃
l???????? 經常構造版本
l???????? Load Factor因子的確定
l???????? 將項目分解為各個迭代期
l???????? 每個迭代期開始時制定計劃
l???????? 人員集中
l???????? 站著開每日晨會
l???????? 當實施遇到困難時及時修正 XP?
User Stories
User stories與use case類似，它主要是在Plan Game過程中對時間以及開發風險進行評估。此外它還用于代替傳統開發中所寫得大量的需求文檔。User stories是由用戶來寫的，在其中要寫出所有需要系統完成的功能，在此也可以描述用戶界面。User stories必須采用用戶的術語來寫，而不能采用任何技術術語。后期的功能測試也是信賴于此，并由此判定功能是否完成，是否正確。User stories必須足夠的詳細，這樣才能對開發工作量有一個比較準確的評估。一個User stories應對應1至3周的工作量，如果超過3周就應當將其繼續細分。一個典型的項目一般由80+/-20個User stories構成。User stories的另一個特點就是它是面對用戶的，因此在其中不應包含任何有關技術、數據庫以及算法在內的術語。我們應當將精力放在用戶的需要以及GUI方面。
Planning Game
通過Planning Game階段，我們可以對整個項目制定一個開發計劃表，并且以后還要依靠此計劃表制定出每個迭代期的開發表。它應當是技術人員以及市場人員共同協商的結果。Planning Game的主要工作是評估每個User stories所需的工作量（以理想情況下的工作日為單位）、風險以及優先級。具體執行時，首先將所有的User Stories打印出來或者是寫在卡片上，然后將其放在一起，由用戶以及開發人員一起對它們進行優先級劃分，確定實現的先后順序，最終的結果是：盡早提供一個有用的、可測試的并且在商業上有意義的早期版本。此外最好能在前期就將高風險的功能加以實現。Load factor在此用于判斷實現User stories需要多少時間，以及在指定的日期之前我們可以完成那些內容。Load Factor是基于理想的工作日而定的。
經常構造版本
在Planning Game階段，我們發現了那些從商為角度上看有意義的功能，在實現過程中應盡可能早地實現這些功能，也就是說要經常構造版本，并及時地將有關版本其交付給用戶試用。采用這種方式的好處在于，我們可以及時從用戶處獲得有用的反饋信息，否則等到開發的后期才獲得這些信息，此時留給我們進行改動的時間也不多了。
Load Factor
Load Factor用于度量項目的開發速度。Load Factor相當于在理想狀態下完成一個任務所需花費的工作時間。一開始時我們并不能確切地知道Load Factor是多少，通常可以設置為2或者3，但在以后的開發過程中可以不斷對其進行修正。如果在開發中發現Load Factor與最初所設置的值有較大的差別，那我們就需要對Planning Game進行相應的調整了。在項目進入維護階段以后，同樣需要對Load Factor進行調整。
迭代開發
迭代開發為開發過程增添了靈活性，一般來說，應將整個項目劃分為若干個不超過兩到三周的迭代期。注意：不要過早制定開發計劃，而應在每個迭代期開始時通過計劃會議制定本迭代期的開發計劃。此外不要提前實現任何不在本迭代期計劃中的功能！只有這樣才能保證對變化的需求的及時響應。
迭代期開發計劃的制定
在每個迭代期開始時才制定相應的開發計劃。一般迭代期的長度應控制在一到四周之內，計劃的制定是依前期Planning Game中為每個迭代期所選擇的User Stories而定的。 User Stories以及測試中出錯的問題在此均轉換為開發任務，并被寫在卡片上。任務一定要填寫的足夠詳細以便為本迭代期制定計劃。每個任務應能在一至三個理想的工作日中加以完成。開發人員分配到任務后再根據自身的情況加以估計需要多長時間才能完成。Load Factor在此用于評估本迭代期的開發工作量是否過多或過少。最終的開發時間的估計等于理想開發時間再乘以Load Factor。如果工作量過大，則應減少此周期中所需完成的User Stories。如果User Stories的完成進度慢了下來，那就要注意了。通過是將難的任務放在前期，容易的放在后期，這樣就可以保證開發速度越來越快。
在此應注意以下幾點：不要添加額外的靈活性，除非現在必須這樣做；不要添加新功能，除非其已列在計劃中，否則會減緩開發進度；注意Load Factories的變化，以便及時改進開發計劃。
人員集中
將開發人員集中起來，這樣可以避免有關信息的丟失以及開發的瓶頸。配對開發一方面可以提高開發質量，另一方面可以防止由于人員流失造成開發進度受阻。
站著開每日晨會
每天早上大家站在一起開個會，以便相互討論所遇到的問題，解決方案，確定團隊的工作重點。所有人均站著并圍成一個圓圈以避免長時間的行討論，而且可以增加大家對討論內容的重視。
通常開會時我們的大部分精力并沒有放在會議主題上，大量的開發時間浪費在很多瑣碎的小事上。同時由于項目成員參加了過多的此類會議，損失了大量的項目資源，從而造成了開發進度的失控。由于參加人員不多，大部分此類會議可以直接在計算機前開，所以可以在討論中直接瀏覽代碼并對新的想法加以驗證。
當實施遇到困難時及時修正XP
??? 當實施遇到困難時及時修正XP。在制定XP時不可能考慮到每個項目的特殊情況，所以在實施XP時也不要想象著它可以滿足你的項目的所有需求，或者是它可以不加修改地直接在你所在的環境中執行。在實施過程中應及時開會討論那些內容是有效的，那些是沒有效果的，并不斷對XP加以修正以提高項目組的開發水平。
設 計
l???????? 簡單化
l???????? Choose a system metaphor
l???????? 在設計中使用CRC卡片
l???????? Create spike solutions to reduce risk
l???????? 不要過早添加新功能
l???????? 盡可能保持程序的簡潔性
簡單化是關鍵
??? 通過將復雜的設計簡單化將會節省大量的時間。因此如果你發現某些復雜的設計可以采用簡單的方法加以實現時，采用簡單的方式。記住：盡可能采用簡單的方法，盡可能長時間的采用簡單的方法，如果沒有將其包含在計劃中一定不要提早實現新功能。但同時應注意：保持設計的簡單化是一個并不輕松的工作。
采用編程規范
系統中變量、類以及方法的命名均應采用約定的規則。統一的命名對了解他人的設計以及代碼的重用均是十分重要的。
CRC卡片
使用“類、職責、協作”（CRC）卡版進行系統設計。采用CRC的一個好處在于它可以使你自然地采用面向對象的方法加以思考問題，另外它還可以讓更多的人加入到系統的設計過程中，從而使設計更加合理與健壯。
??? 一個的CRC卡片代表一個獨立對象的實例。在卡片的上邊記錄有類的名稱，在卡的左邊列出了此類所要實現的功能，在卡的右邊列出了與此類相關的其它類的名稱。通過將所有的CRC卡放在一起，不同的人負責一個或幾個CRC卡，大家一起協同工作以模似當前所設計的軟件最終動態的運行情況：哪個類發出一個消息，哪個類接收到這個消息并執行某一特定的動作…。采用上述“走讀”方式，我們可以方便地發現設計中的問題。總得來看，此處的CRC方法與在ROSE中采用Class Diagram是相同的。如果發現有過多的人同時在移動/談話，則可以限制一次站起并移動卡片的人的總數。只有當一個人坐下后才能允許其它人站起來。
采用CRC卡的一個不利之處在于它缺乏設計文檔。當然也可以將所有卡中的內容保存在一個文檔之中。
使用Spike Solution 方法
為了解決一個技術或者設計上的問題，我們可以采用“Spike Solution”方式（類似于我們常說的“技術原型”）。此方法只關心所要解決的問題本身，而不關心其它內容。大部分的“Spike Solution”是一個粗糙的不能再用的程序，一般試驗完成后就不再用了。使用這種方法的目的是減少技術問題的風險，并且可以提高我們對User Stories評估的準確性。
不要過早添加新功能
保持產品功能的單一性，不要添加你認為以后可能會用到的代碼。只有10%的多余代碼會在以后用到，因此過早加入多余的代碼會導致你浪費90%的時間。多余的代碼及功能還將降低開發速度并浪費開發資源。所以只做計劃中要做的事情。
保持程序的簡潔性
很多時候，當程序的結構已被改的支離破碎，或者程序代碼已被改的面目全非時，我們仍試圖將其維持下去。但這一些均不會發生在XP中。在XP中，一旦發現上述情況就會將原有的結構/代碼推翻重新進行設計/編碼。雖然看起來這樣的花費比維持原有狀況代價更大，但從長遠的角度來看將會節省更多的人力資源。不論在程序開發中哪一個階段，如果發現程序中存在冗余的代碼、無用的函數以及過時的設計，刪掉它們！這在XP中被稱為“Refactor”。
通過Refactor可以避免程序的冗余以及復雜化，使之盡量簡化。只有這樣才能保證代碼容易為他人理解、修改以及擴充。不要等到系統已混亂不堪時再花時間去解決問題。
編 碼
l???????? 始終獲得用戶的支持
l???????? 代碼的編寫必須符合規范
l???????? 所有代碼均應采用配對編程方式加以開發
l???????? 一次只能有一對開發人員進行Release
l???????? 經常集成
l???????? 代碼共享
l???????? 將優化放在最后進行
l???????? 不要加班
始終獲得用戶的支持
在XP開發中有一條原則是：始終保持與用戶的聯系。用戶不但可以幫忙開發團隊，而且是開發團隊的一部分。在XP的各個階段中均需要與用戶的交流，最好是坐在一起面對面的交流。如果可能的話，最好在開發團隊中分配一至多名用戶。需要注意的一點是：在此我們需要的是用戶中的專家，而不是新手。
User Stories是由用戶在開發人員的幫助下編寫的，并且用戶需要幫助確保系統所需的功能均已涵蓋在User Stories中。
計劃階段，用戶幫助開發人員為每個迭代期選擇需實現的User Stories，確定每個開發周期的長短。如果有商業目標的改動，應由用戶做出最終的決定。迭代期確定的最終原則是讓用戶盡早拿到一個可用的早期版本。
編程規范
??? 編碼時一定要遵守編程規范，以使代碼具有可讀性，易于為項目組中其它人員所理解。
配對編程
??? 所有的代碼均應在采用配對編碼方式下產生，即由兩個開發人員共同編寫。配對編程在不影響開發周期的前提下提高了軟件的質量（多用15%的時間，但提高軟件質量23%）。
按順序Release代碼
???? 因為并行開發的原因，所以同一時刻可能有多對開發人員在對代碼進行Release，由于大家均沒有將自已的當前改動放到服務器中，所以在這種情效況下進行的Release并不能保證最終所有代碼全部更新后再次Release的正確性。為此應當規定：同一時刻只能有一對開發人員在進行Release，當其保證有關代碼正確并更新至服務器后才允許其它開發人員對其私有代碼進行Release。
經常集成
為了提早發現問題，盡可能地經常地進行代碼集成，最好不要超過一天。通過代碼集成可以發現不同部分之間的配合問題，如果集成的周期過長，將會導致修改成本的上升。并且通過經常集成代碼，可以保證當前服務器上始終有一個可用的版本。另外，采用此方法，還可以更好地實現代碼的重用。
代碼共享
??? 確保項目組中的每個人均能看到所有的代碼，并且為了修改BUG可以對每個源代碼文件進行修改。這樣可以避免由于某個人的缺席造成開發中的瓶頸。此外應讓所有開發人員對程序的整體結構有一個清晰的認識，而不要將有關知識只掌握在一兩個人頭腦中。
最后做優化
只在開發的后期才進行優化。不要在開發的過程中想當然地認為何處是瓶頸，只有實際測試之后才能發現真正的瓶勁。首行保證代碼能工作，然后保證工作正確，最后再想辦法提高運行速度（Make it work, make it right, then make it fast）。
不要加班
??? 不要加班，這樣會榨干開發人員的精力并減弱開發積極性。如果是為了保證按時完成計劃而加班的話，那么最終無論你怎么做，均無法實現這個目標。正確的做法是：減少軟件所要實現的功能或者延長開發時間。在開發進度延后的情況下增加開發人員同樣也是不可取的。
測 試
l???????? 所有的代碼必面做單元測試
l???????? 版本發放之前所有代碼必須通過單元測試
l???????? 發現一個BUG后就要為其創建一個測試用例
單元測試
單元測試是XP開發方法中的基石。與其它的單元測試方法有所不同，XP中的單元測試具有以下特點：首先你需要創建或者下載（從www.XProgramming.com中下載）一個單元測試框架以便實現自動化的單元測試；第二點，必須測試所有的類（可以利用VC中的Profile功能進行代碼的覆蓋性測試）；最后，在編寫代碼之前就必須先考慮有關測試的內容。
在編碼之前就考慮測試可以使開發人員對需求具有更好的理解，對程序結構會有更好的把握，并且在代碼開發完后馬上就可以進行測試，及時獲得有用的反饋信息。沒有經過.測試的代碼是不允許被包括在Release版本中。
只有當所有的代碼均進行并且通過了單元測試之后，才能Release一個新版本。
針對每個User Stories應創建相應的功能測試。功能測試屬于黑盒測試，由用戶來判斷測試結果是否正確，并且它的執行必須在Release之前。測試時最好有自動測試工具。
一旦發現一個BUG，立即為其創建一個相應的測試用例，以防止以后再次出現此類問題。
Extreme Programming總結
XP的主要特點
?????? 是一個輕量級的軟件開發過程
最大限度地滿足用戶的需求
?????? 強調團隊的協作
?????? 強調項目管理（基于評估以及制定計劃）
?????? 將有限的時間投入到真正的開發中（拋棄不必要的會議、文檔以及評審）
?????? 見效快
XP適用對象
??? 是一個輕量級的開發過程
適用于2 – 10人，3個月 – 1年的小型項目
適用于需求經常變更以及高風險的項目
XP在實施中的四個主要特點
?????? 溝通、簡單化、反饋、勇氣 (Communication, Simplicity, Feedback, and Courage.)
Communication takes place between people, documents are secondary.
XP與RUP的關系
?????? 是RUP的最小實現集（A minimal RUP process）
又被稱之為dX （Object Oriented Analysis and Design with Application, 3th）
?????? dX在表述上采用了RUP的表述形式
XP實施中的注意事項
?????? 以體系結構為中心 （architecture-based）（has a very strong architecture focus）
?????? 以用戶需求驅動 （requirement-driven）
?????? 強調軟件的良好的內部結構
?????? 并不排斥分析及設計（包含在代碼中，沒有多余的外部文檔）
如何開發實施XP
可以從一個全新的項目開始
可以針對正在進行的項目開始
可以全部采用XP的方法
可以只采用部分XP的方法
參考資料
?????? www.extremeprogramming.org
?????? www.XProgramming.com
?????? www.objectmentor.com
?????? 《Design Patterns》
?????? 《Software Architecture》
XP工作流程圖
總結
以上是生活随笔為你收集整理的Extreme Programming介绍的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： es--Restful API查询
- 下一篇： 长春四月飞雪！！