摘自《輕鬆scrum之旅》
1、極限程式設計（extreme programming，xp）
極限程式設計的思想源自 kent beck 和 ward cunningham 在軟體專案中的合作經歷。在這裡，「extreme」的意思是希望將軟體開發過程中一些好的方法發揮到極致。xp 注重的核心在於「溝通、簡明、反饋和勇氣」，用一句話來概括 xp 的這 4 個核心價值觀就是：通過充分的交流和溝通，使產品的設計盡可能簡單明瞭；同時通過客戶經常性的反饋，生產出符合客戶要求的軟體產品，並且有勇氣迎接需求的改變。
另外，極限程式設計者還總結出一系列經典的實踐，形成了 xp 的 12 個主要實踐方法，這些方法對極限程式設計具有指導性的意義，分別是：客戶計畫的制定、小版本發布、隱喻、結對程式設計、測試驅動開發、重構、穩定的進度、**共享、編碼規範、簡單的設計、持續整合、現場客戶。
2、rup（rational unify process，ratioanl 統一過程）
rup 試圖總結現代軟體開發過程中所有好的實踐經驗，形成一種有很強適應性的軟體開發過程。它包括了軟體開發中的 6 大經驗，分別是：迭代式開發、管理需求、視覺化建模、使用基於元件的軟體體系結構、驗證軟體質量、控制軟體變更。
rup 將軟體開發周期按時間和 rup 的核心工作流劃分為乙個二維空間，如下圖
所示。
從圖中的橫軸來看，rup 把軟體開發的生命週期劃分為多個迴圈迭代，每個迭代生成產品的乙個新版本，每個迭代由 4 個連續的階段組成，分別是：初始階段，了解專案的大致需求，建立業務模型，確定系統範圍；細化階段，設計、確定系統的體系結構，制定工作計畫；構造階段，構造產品並繼續演進需求、體系結構、計畫直至產品提交；移交階段，完成產品的最終版本並交付給使用者使用。
從圖縱軸來看，rup 的 9 個核心工作流分別是：業務建模、需求、分析與設計、實現、測試、部署、配置與變更管理、專案管理、環境。
rup 的基本原理是：以滿足客戶需求、為客戶創造價值為最終目標；盡可能早且不斷地化解重大風險；把注意力放在可工作的軟體上；在專案執行過程中盡可能早地適應變化；在專案早期設計、實現並測試乙個可執行的架構；使用元件來構造系統；建立高效、協作的團隊；要始終重視產品質量，否則追悔莫及。
以上 rup 的基本原理構成了 rup 的靈魂，在這些指導原則下，rup 又給出了其他一些最佳實踐，比如：為了化解業務風險，它始終以用例為中心；不是逃避變化，而是直面變化；為了化解時間風險，它採取迭代開發，盡量在早期探知到時間的延遲，以便採取更靈活的策略；為了化解技術風險，它強調架構設計；為了化解質量風險，它強調測試優先。而這些也恰好是 rup 的主要特點。在這些最佳實踐之後，才是具體的過程組織形式：具體由哪幾個階段組成？而每個階段又包括哪些工作流，要產出哪些產品？而且這些形式不是固化的。rup 只是提供乙個模板，可以在開發過程中進行裁減。
3、lean（精益軟體開發方法）
精益生產的概念首先出現在製造業中，由日本的豐田公司提出。大規模製造理論認為，一定程度的浪費、一定程度的廢品是正常的和被允許的。而在軟體開發中，資源浪費、成本居高不下也同樣成為軟體開發的一大障礙。處於變革的十字路口的軟體開發行業，總是能不斷地從其他行業中尋找可借鑑的理論。這種借鑑來的思路就被稱為精益程式設計（lean programming）。
lean 方法的主要思路有：消除浪費，將所有的時間花在能夠增加客戶價值的事情上；延遲決策，在乙個複雜多變的環境中進行軟體開發，需要根據實際情況保持可選方案的開放性，但時間不能過長；盡早交付，軟體交付的週期越快，使用者的需求就會越清晰，軟體應對需求變化的靈活性就越高，讓客戶的需求來推動工作的進展；加強學習，承認變化的存在及其不可預見性，加強反饋和交流，在實踐中發現問題、解決問題，並最終形成解決方案；授權給團隊，正確的決策取決於準確的資訊，讓開發團隊參與決策，讓團隊成員充分發揮自己的潛力。
無數的經驗和教訓都已經證明，軟體開發中乙個巨大的浪費源頭就是不注重質量而導致的返工。人們常常為了追趕工期而降低對質量的要求，殊不知這會帶來更大的損失。
lean 強調消除浪費，這正是為了避免低質量和返工造成的浪費。儘管這樣做一開始看起來似乎有些麻煩，但它所帶來的收益是實實在在的。如果採用 lean 方法，還要注意不要鑽牛角尖。消除浪費並不意味著扔掉所有的文件；盡量推遲決策並不意味著拖延決策，不能晚到錯過了時機、耽誤了工作才作出決策；盡快交付並不意味著匆忙交付和馬虎行事，否則會為日後的系統維護帶來更多的麻煩和浪費，這恰恰是與消除浪費的原則背道而馳的；授權給團隊也並不意味著放棄領導。
4、scrum
scrum是一種靈活的敏捷軟體開發管理過程，這個名詞**於英式橄欖球。scrum 方法由 ken schwaber 和 jeff sutherland 提出，它將軟體開發團隊比作橄欖球隊，全隊有明確的最高目標——發布產品的重要性高於一切，團隊高度自治，成員們熟悉開發過程中涉及到的各種技術，緊密合作，確保每個迭代都朝著最高目標推進，而且每隔 2～4 周，每個團隊成員都能看到能實際工作的軟體，並且據此決定是發
布這個版本還是繼續開發以加強它的功能。
對於那些功能需求可能經常發生變化的專案來說，scrum 是最為理想的選擇之一。
在乙個採用 scrum 的專案中，首先要將所有需要完成的工作列在乙個 product backlog
中，專案開發過程中需求的改變也要寫進去。在每個 sprint 開始之前，要召開乙個 sprint
計畫會議。在這個會上，產品責任人（product owner）為 product backlog 中的各項
功能需求確定優先順序。隨後，scrum 開發團隊按照優先順序，從 product backlog 中挑選
出他們認為能在這個 sprint 中完成的任務，並把這些任務從 product backlog 中挪到
sprint backlog 中去。在 sprint 的進行過程中，scrum 團隊每天都要舉行乙個簡短的每
日 scrum 會議，以便團隊成員了解開發進度。乙個 sprint 結束之後，需要召開 sprint
評審會議和 sprint 回顧會議。開發團隊在 sprint 評審會議上把這個 sprint 的開發成果
展示給大家。而在 sprint 回顧會議上，團隊成員們會回顧剛剛過去的這個 sprint，從中
總結經驗和教訓。
scrum 的總體結構如圖所示
敏捷開發方法
王老師讓撰寫一篇部落格關於敏捷開發方法，讓我們深入理解敏捷開發方法。我看來，在爆發軟體危機以來，我們一直沒有找到乙個完美的方法解決。敏捷開發是在人們探索中由以前的開發方法中探索和總結出來的，雖然不完美，但是正在逐步適應。敏捷開發是針對傳統的瀑布開發模式的弊端而產生的一種新的開發模式，目標是提高開發效...
敏捷開發方法
敏捷方法一覽 各種敏捷方法的要求千差萬別，但是它們都遵循以下12條原則。1 最重要的是通過盡早地 頻繁地交付有價值的軟體來滿足客戶 盡早交付有價值的軟體。2 頻繁地交付可執行的軟體，數週或者數月交付一次 頻繁發布新版本。3 可執行的軟體是衡量進展的主要標準 軟體比文件更重要 4 接受需求變更，即便是...
敏捷開發方法綜述
敏捷開發的出現是由於在2000年左右，許多團隊採用龐大，重型的過程方法的趨勢在逐漸增長，一批自稱敏捷聯盟的業界專家概括出了可以讓軟體團隊具有快速工作，響應變化能力的價值觀和原則。影響至今的就是他們的敏捷聯盟宣言 個體和互動勝過過程和工具 可以工作的軟體勝過面面俱到的文件 客戶合作勝過合同談判 響應變...