敏捷-敏捷方法實現

經常使用的敏捷實踐包含：精益、看板、Scrum、XP極限編程、水晶、DSDM動態系統開發、FDD功能驅動開發、AUP敏捷統一過程、OpenUP。

《敏捷實踐指南》將敏捷方法和看板方法是爲精益方法的子集。由於他們都符合精益思想的具體實例，都反映了「關注價值」、「小批量」、「消除浪費」。

---

極限編程

極限編程 (XP)是一種基於頻繁交付週期的軟件開發方法。該名稱基於這樣一個理念：將特定最佳實踐提煉到最純粹和最簡單的形式，而後在整個項目週期內持續運用該實踐。

核心思想：鼓勵從最簡單的解決方式入手再經過不斷重構達到更好的結果，主張「不對未來可能的需求上投入精力」，這麼作的好處，設計與代碼上的簡化能夠提升交流的質量。

價值：溝通、簡單、反饋、勇氣、尊重

溝通：追求有效的溝通而非無心義的會議。強調項目組成員、客戶之間有效地、及時溝通，打破信息孤島，確保信息的暢通。
簡單/簡潔：實現最賤的可行方案。應該儘快保持代碼的簡單，只要能知足工做須要便可，有利於代碼的重構和優化，確保頻發的發佈功能。
反饋：經過對當前系統狀態進行不斷的反饋，達到迅速溝通、編碼、測試、發佈的目的。
勇氣：敢於放棄和重構，這點太難了。
尊重：尊重每一位成員，從人性的角度爲項目組成員考慮，確保項目的質量和交期。
敏捷編程的開發過程核心活動：「需求→測試→編碼→設計過程當中，所以對工做環境、需求分析、設計、編程、測試、發佈等提出了新的思路、要求和挑戰。

---

看板方法

---

水晶方法
水晶是一種方法論家族。水晶方法論旨在根據項目規模（項目中涉及的人員數量）以及項目的關鍵性來量化並提供方法嚴格程度選擇。

---

FDD（特徵驅動開發）

特徵驅動開發（FDD-Feature Driven Development）方法是敏捷軟件開發過程當中的一種，是由Jeff de Luca 、Eric Lefebvre、Peter Coad共同開發的。它強調特性驅動，快速迭代，即能保證快速開發，又能保證適當文檔和質量，很是適合中小型團隊開發管理。

它提出的每一個功能開發時間不超過兩週，爲每一個用例user case限定了粒度，具備良好可執行性，也能夠對項目的開發進程進行精確及時地監控。它抓住了軟件開發的核心問題領域，即正確和及時地構造軟件。FDD還打破了傳統的將領域和業務專家/分析師與設計者和實現者隔離開來的壁壘。分析師被從抽象的工做中解脫出來，直接參與到開發人員和用戶所從事的系統構造工做中。

角色：項目經理、開發經理、首席編程人員、類負責人、領域專家，由團隊成員分別擔任。

FDD最佳實踐

　　　　• 持續集成Continuous Integration.

　　　　• 對領域（業務）對象建模Domain Object Modeling.

　　　　• 按特性開發Developing By Feature.

　　　　• 類的全部者Individual Class ownership.

　　　　• 按特性組織團隊Feature Teams.

　　　　• 源代碼控制Source Control.

　　　　• 彙報/結果可見性Reporting/Visibility of results

---

DSDM動態系統開發方法

一種敏捷項目交付框架，強調製約因素驅動交付而著稱。DSDM的基本觀點是：任何事情都不可能一次性圓滿完成，應該用20%的時間完成80%的有用功能，以適合商業目的爲準。

DSDM的基本原則：

　　1.活動用戶必須參與。

　　2.必須受權DSDM團隊進行決策。

　　3.注重頻繁交付產品。

　　4.判斷產品是否可接受的一個基本標準是符合業務目的。

　　5.對準確的業務解決方案須要採用循環和增量開發。

　　6.開發期間的全部更改都是可逆的。

　　7.基本要求是高層次的並區分優先級（以在低優先級的項目上得到必定的靈活性）。

　　8.在整個生命週期集成測試。

　　9.在全部參與者之間採用協做和合做方法。

---

AUP敏捷統一過程

捷統一過程 (AgileUP)是軟件項目中統一過程 (UP)的分支。與緊前統一過程相比，該過程具備加速週期和輕量級的過程。其目的在於在七個主要因素之間執行更多迭代的週期，並在正式交付以前歸入相關反饋。

該方法應用了敏捷技術，包括 測試驅動開發（TDD）， 敏捷模型驅動開發（AMDD）， 敏捷變動管理和 數據庫重構，以提升生產率。

AUP的哲學
　　敏捷UP基於如下原則：
　　　　1.員工知道他們在作什麼。人們不會閱讀詳細的過程文檔，但會不時須要一些高級指導和/或培訓。
　　　　2.簡單性。使用不多的頁面（而不是數千個頁面）來簡潔地描述全部內容。
　　　　3.敏捷性。敏捷UP遵循敏捷聯盟的價值觀和原則 。
　　　　4.專一於高價值的活動。重點是實際計數的活動，而不是項目上可能發生的全部可能事情。
　　　　5.工具獨立性。

OpenUP
四項核心原則:

平衡，在競爭優先級以及最大化干係人利益之間，創建平衡 。
協做，協做以協調利益，以及保證理解一致。
關注，從開始起，就將注意力放在軟件架構上，以減輕風險，並組織軟件開發。
演化，持續演進而且不斷得到反饋。
生命週期：OpenUP的迭代開發流程分佈而且貫穿在幾個階段中：啓始（Inception）、精化（Elaboration）、構建（Construction）和移交（Transition）階段。

啓始階段: 確保項目目標和範圍已經明確。
精化階段：開發總體架構框架，確保架構已經穩定。
構建階段：從摸索到可部署產品的開發，轉向功能模塊的開發。
移交階段：確保軟件被最終用戶接受。