敏捷開發系列之旅 第二站（走近XP極限程式設計）

紫竹風發表於2014-03-19
敏捷程式設計
上篇文章，我們探討了什麼是敏捷開發，以及敏捷開發的方法學。在這篇文章中，我們將繼續討論敏捷開發中的問題——XP極限程式設計。

在討論之前，先讓我們來了解一下XP極限程式設計產生的背景，軟體業所具有的共同的問題。

背景

  • 軟體越來越複雜
  • 需求越來越多變
  • 過程越來越規範
瞭解了背景之後，那麼就會想問，到底什麼是極限程式設計呢？下面我們就做一個簡單的介紹。

XP概述


極限程式設計（eXtreme Programming），是一種全新的、輕量級的、靈巧的軟體開發方法，是一種軟體工程方法學。它強調程式設計團隊與業務專家之間的緊密協作、面對面的溝通（比書面的文件更有效）、頻繁交付新的軟體版本、緊湊而自我組織型的團隊、能夠很好的適應需求變化的程式碼編寫和團隊組織方法，更注重軟體開發中人的作用。

核心價值觀

  • 溝通（Communication）
     問題往往是由於開發人員與設計人員、設計人員與客戶之間的溝通不暢造成的。XP認為專案成員之間的溝通是專案成功的關鍵，並把溝通看作專案中間協調與合作的主要推動因素。因此，專案相關人員之間進行充分、多渠道（最好面對面）的溝通是很有必要的。

  • 簡單（Simplicity）
     XP假定未來不能可靠地預測，在現在考慮它從經濟上是不明智的，所以不應該過多考慮未來的問題而是應該集中力量解決燃眉之急。 在系統可運轉的前提下，做最簡潔的工作，堅定的專注於最小化解決方案；在開發中不斷的優化設計，時刻保持程式碼簡潔、無冗餘。需求儘量的簡單，設計儘量的簡單，程式碼儘量的簡單，文件儘量的簡單。

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

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

12個實踐原則

  • 規劃策略（Planning Game）
     以業務優先順序和技術估計為基礎，決定下一版本釋出的範圍。

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

     結對程式設計是讓兩個人共同設計和開發程式碼的實踐。結對者是全職合作者，輪流執行鍵入和監視；這提供了持續的設計和程式碼評審。不是兩個人做一個人的事情。 

  • 測試（Testing）
     測試驅動開發，是指在編碼開始之前，首先將測試寫好，而後再進行編碼，直至所有的測試都得以通過。即所謂的先測試，再編碼；程式碼未動，測試先行。 通常包括，Unit Test、Acceptance Test( Functional Test )、Nightly Test、Stress Test等。

  • 重構（Refactoring）
     重構是XP的一個重要組成部分。所謂重構是指在不改變程式碼外在行為的前提下對程式碼做出的修改，以改進程式碼的內部結構。重構是一種有紀律的、經過訓練的、有條不紊的程式碼整理方法，可以將整理過程中不小心引入錯誤的可能性降到最低。改進軟體的設計，Refactoring幫助重新組織程式碼，重新清晰地體現結構和進一步改進設計。

  • 簡單設計（Simple Design）
     系統應設計得儘可能簡單。

  • 程式碼集體所有權（Collective Code Ownership）
     程式碼集體所有權強調的是整個團隊，而非個人，即“我們”的程式碼，而不是“我”的程式碼。 團隊中的任何人都可以改動任何一段程式碼，但改動後的程式碼必須通過所有相關的測試。

  • 持續整合（Continuous Integration）
     持續整合的思想是任何時候只有一項任務完成，就整合新程式碼，構造系統並測試。持續整合是每日構建\每晚構建的一種極限形式，是XP的重要基礎。

     測試先行是持續整合的一個重要前提。持續整合指不斷地把完成的功能模組整合在一起。目的在於不斷獲得客戶反饋以及儘早發現BUG。隨時整合，越頻繁越好；整合及測試過程的自動化程度越高越好。每次只有一個PAIR在整合，而且必須執行功能測試。

     需注意，持續整合需要良好的軟體配置變更管理工具的有效支援。 
 

  • 現場客戶（On-site Customer）
     客戶是Team成員，在開發現場和開發人員一起工作。傳統的客戶任務一般是講解需求，執行驗收測試，接收發布的系統。

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

  • 每週40小時工作制（40-Hour Work）
    “不加班，不熬夜”。XP要求專案團隊人員每週工作時間不能超過40小時，加班不得連續超過兩週，否則反而會影響生產率。

  • 編碼規範（Code Standards）
     XP 強調通過指定嚴格的程式碼規範來進行溝通，儘可能減少不必要的文件。型別包括：格式、程式碼結構、命名約定、錯誤處理、註釋等。 

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

開發過程


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

適用範圍


XP適合規模小、進度緊、需求變化大、質量要求嚴的專案。它希望以最高的效率和質量來解決使用者目前的問題，以最大的靈活性和最小的 代價來滿足使用者未來的需求，XP在平衡短期和長期利益之間做了巧妙的選擇。

結束語


XP用自己的實踐，在一定範圍內成功地打破了軟體工程“必須重量”才能成功的傳統觀念。XP的思想啟發我們如何學習和對待快速變化、多樣的開發技術。

相關文章