敏捷開發二——極限編程

背景:

  • 軟件越來越複雜
  • 需求越來越多變
  • 過程越來越規範

XP概述(eXtreme Programming)

是一種全新的,輕量級的,靈巧的軟件開發方法。它強調程序設計團隊與業務專家之間的緊密協作,面對面的溝通(比書面文檔更有效),頻繁交付新的版本,緊湊而自我組織的團隊,能夠更好地適應需求變化的代碼編寫和團隊組織方式,更注重軟件開發中的人的作用

核心價值觀

溝通

問題往往是由開發人員和設計人員,設計人員和客戶之間溝通不暢造成的。XP認爲項目之間的溝通是項目成功的關鍵,並把溝通看作是協調與合作的推動因素。項目相關人員進行充分,多渠道溝通很有必要。

簡單

XP假定未來不能可靠預測,所以不應該過多考慮未來的問題而是應該集中力量解決燃眉之急。 在系統可運轉的前提下,做最簡潔的工作,堅定的專注於最小化解決方案;在開發中不斷的優化設計,時刻保持代碼簡潔、無冗餘。需求儘量的簡單,設計儘量的簡單,代碼儘量的簡單,文檔儘量的簡單

反饋

儘快獲得用戶的反饋,並且越詳細越好,使得開發人員能夠保證自己的成果符合用戶的需要。強調各種形式的反饋:小交付、短迭代、測試先行等。XP認爲系統本身及其代碼是報告系統開發進度和狀態的可靠依據。系統開發狀態的反饋可以作爲一種確定系統開發進度和決定系統下一步開發方向的手段。

勇氣

這是最重要的核心價值。因爲XP強調要“擁抱變化”,因此對於用戶的反饋,提倡積極面對現實和修改問題的勇氣,如放棄已有代碼,改進系統設計等;勇敢的重構;所有人擁有代碼;敢於極限(把好的方法做到極致)。XP認爲,軟件開發中,人是最重要的一個方面。在一個軟件產品的開發中,人的參與貫穿其整個生命週期,是人的勇氣來排除困境,讓團隊把局部的最優拋之腦後,達到更重大的目標。

12個實踐原則:

規劃策略(planing game):

業務優先級和技術估計爲基礎,決定下一版本發佈的範圍:


結對編程

結對編程是一種編程模式。兩個程序員並排坐在一臺電腦前,面對同一個顯示器,使用同一個鍵盤,同一個鼠標一起工作。他們一起分析,一起設計,一起寫測試用例,一起編碼,一起單元測試,一起整合測試(Integration Test),一起寫文檔等。基本上所有的開發環節都一齊肩並肩地,平等地,互補地進行開發工作

測試

測試驅動開發,是指在編碼前,首先將測試寫好,然後進行編碼,直至所有測試都通過。即先測試,再編碼,代碼未動,測試先行。通常包括,Unit Test、Acceptance Test( Functional Test )、Nightly Test、Stress Test

重構

重構是不改變代碼外在行爲的前提下對代碼做出修改,以改進代碼的內部結構,重構是一種有紀律,經過訓練的,有條不紊的代碼整理方法。可以講整理過程中不小心引入的錯誤降到最低。

簡單設計:

系統儘可能的簡單。

代碼集體所有權

強調整個團隊,而非個人,即“我們的代碼”。團隊中任何一個人都可以改動代碼,但是改動之後必須通過測試。

持續集成

任何時候只有要一項任務完成,就集成新代碼,構造系統並測試,持續集成是每日集成/每晚集成的極限形式。是XP的重要基礎。

測試先行是持續集成的一個重要前提,持續集成是不斷的把完整的功能模塊整合在一起,目的在於不斷的獲得用戶反饋以及今早發現bug,

現場客戶

客戶是team成員,在開發現場和開發人員一起工作。

小型發佈:

發佈過程應該儘可能地自動化、規範化。不斷地發佈可用的系統可以告訴客戶你在做正確的事情。客戶使用發佈的系統,可以保證頻繁地反饋和交流。保證客戶有足夠的依據調控開發過程(增加、刪除或改變User Story)。降低開發風險。隨着開發的推進,發佈越來越頻繁。所有的發佈都要經過功能測試。 

每週40 hour工作制

編碼規範

XP 強調通過指定嚴格的代碼規範來進行溝通,儘可能減少不必要的文檔。類型包括:格式、代碼結構、命名約定、錯誤處理、註釋等。

系統隱喻

XP通過隱喻描述系統如何運作、新的功能以何種方式加入到系統。它通常包含了一些可以參照和比較的類和設計模式。XP不需要事先進行詳細的架構設計
開發過程

用戶代表提出用戶故事,項目組據此進行討論、提出隱喻,在此活動中有可能要進行系統結構的Spike。在隱喻和用戶故事的基礎上,根據用戶設定的優先級制訂交付計劃,然後開始多個迭代過程,在迭代期內產生的新用戶故事不在本迭代內解決,以保證開發不受干擾。經驗收測試通過後交付使用。


適用範圍:

適合規模小,進度緊,需求變化大,質量要求嚴的項目。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章