敏捷開發(XP,SCRUM)

關於Scrum和XP(Extreme Programming)

前面說了敏捷它是一種指導思想或開發方式，但是它沒有明確告訴我們到底採用什麼樣的流程進行開發，而Scrum和XP就是敏捷開發的具體方式了，你可以採用Scrum方式也可以採用XP方式；Scrum和XP的區別是，Scrum偏重於過程，XP則偏重於實踐，但是實際中，兩者是結合一起應用的.

XP的12條實踐規則

XP是偏重於實踐的，這些實踐中有些已大量運用於現代軟體開發中。無論你的開發過程是SCRUM還是CMMI，CMMI？是的，這些優秀的軟體工程實踐並不是敏捷的專享，即使你的開發過程是CMMI，也不影響你使用這些實踐。例如TDD，CI(Continues Integration)，Agile 和 CMMI 並不是水火不容的對立關係，而是在某種程度上可以有機的結合。

• 1. 結對程式設計（Pair Programming)，即任何程式碼都有兩個人合作完成，一個人coding，一個人review code然後提供反饋。現實中一般不會採用此實踐，一種替代方式是定期開code
  review meeting。
• 2. 規劃工作（Planning Game），每個迭代週期開一次計劃會議，對此工作週期進行回顧和總結，以及對下個迭代（通常2星期）的開發和釋出進行規劃。
• 3.測試驅動（Test Driver Development)，程式設計師在實現功能前應該寫好單元測試程式碼，因為功能程式碼還沒有實現，執行測試的結果可想而知，肯定會失敗，程式設計師的工作就是恰當的程式碼能使此測試用例通過。這個功能實現的過程也是循序漸進、迭代的，每次實現功能的一小部分，然後執行測試，這樣在出現問題時，我們可以很快的定位到問題所在，並很快的解決問題。因為如果你和我一樣不是足夠聰明的人，我們大腦通常只能記住剛剛發生此的事情。概念同樣適用於CI裡，對每次Checkin的Regression
  Test，因為如果你的Checkin造成了對現有功能的破壞，因為問題時你剛剛修改程式碼造成的，你也能比較容易的定位問題，修復它。
• 4.完整團隊（Whole Team），有時也叫客戶現場，即客戶並不是需求分析後，就萬事大吉了，應該駐紮在開發現場，這樣開發團隊可以獲取最新，最準確的客服反饋，確保開發沒有偏離客戶需求。

• 5.可持續整合（Continues Integration），專案應該有一套自動編譯，自動化測試，自動部署的工具（hudson），程式設計師應該在最新的程式碼版本上工作，對於多人並行開發，應該及時的checkin你對程式碼修改，並保證編譯、測試通過。若有問題可以儘早的被暴露，修復。對於減少bug，降低軟體風險都有積極作用。
• 6.程式碼重構（Refactoring),軟體隨著需求的變化和技術的革新是不斷演化的，容易產生程式碼堆砌，程式碼冗餘等程式碼中的“壞味道”，用程式碼重構技術的程式碼進行及時的清理、調整、重組。有助於提高軟體質量和可維護性。
• 7.小版本釋出（Small Release），怎樣吃掉大象？將一個大的問題域分解成小的，可操作的問題，是解決複雜問題的自然之道。將軟體需求分解成小的功能模組，在每個迭代週期中完成預定的部分模組，並形成一個可釋出的版本，在Demo此版本時，可以快速都獲得來自stakeholders的反饋，而不用將風險延遲到專案的最後。
• 8. 40小時工作制（Sustainable Pace)，可持續發展，不要加班，該打籃球打球。

• 9.程式碼規範（Coding Standard），統一的程式碼風格和格式
• 10.集體所有制(Collective Code Ownership), 每個人對所有程式碼負責
• 11.簡單設計（Simple Design），簡單是王道，不要over-design
• 12.系統隱喻（System metaphor）,系統隱喻是每個人（客戶，程式設計師，經理）都能理解系統是如何工作的，涉及到如何對Class/Method進行命名，使得團隊成員僅從名稱上就能想到起功能，例如一個產品過期，那麼在Catalog（Class）上有makeOverdue的Method。