敏捷開發(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。

如何運用Scrum作為開發過程： https://www.cnblogs.com/taven/archive/2010/10/17/1853386.html