在軟件開發中，我們經常會遇到類似這樣的問題
我們所理解的東西無法和用戶想要的達成一致，所以用戶提出的要求，經過項目經理、分析師，最後到程序員的就已經被篡改的面目全非，所以，經過程序員們日以繼日的努力，終於做出來完全不是用戶需要的程序了，於是我們不得不繼續夜以繼日的修改，終於在放棄了代碼的質量、放棄了休息、加班加點的工作後，用戶勉勉強強的接受了我們隨時都可能奔潰的系統。
或者我們還會 遇到另一個問題：
第一次看到這個圖的時候真是心酸，可是我們不是常常處於這種境況嗎，只是我們寫的是代碼，而不是在挖坑，當銷售部以犧牲各種簽下了喪權辱國的條例之後，當產品經理大概瞭解了需要項目經理制定出看似爭取的需求之後，就是程序員一個人在勞動的時候了，然後還要繼續忍受感覺計劃不合理向上反應的石沉大海，和測試部分的各種矛盾，和銷售部門的各種嫌棄，就連每天加班讓保安隊長都建議頗多，但是幹活的還是隻有是自己。
但是，程序員都是高智商的，既然就問題，就肯定有解決的方法，下面我就介紹一種解決辦法——敏捷開發（agile development）。
敏捷開發簡介
敏捷開發（agiledevelopment）
是一種以人爲核心、迭代、循序漸進的開發方法。在敏捷開發中，軟件項目的構建被切分成多個子項目，各個子項目的成果都經過測試，具備集成和可運行的特徵。簡言之，就是把一個大項目分爲多個相互聯繫，但也可獨立運行的小項目，並分別完成，在此過程中軟件一直處於可使用狀態。
敏捷的組成
它們包括：極限編程（XP），Scrum，精益開發（Lean Development），動態系統開發方法（DSDM），特徵驅動開發（Feature Driver Development），水晶開發（Cristal Clear）等等
和其他開發對比
我們知道軟件開發模型有很多，比如：
瀑布式
它首先是由Royce提出，該模式由於酷似瀑布聞名。在該模式中首先確定需求，然後擬定規格說明，在通過驗證後方可進入計劃階段。因此，瀑布模式中至關重要的一點是隻有當一個階段的文檔獲得認可纔可以進入下一個階段。瀑布模式通過強制性規約來確保每個階段都能很好的完成任務，但是實際上卻往往難以辦到。因爲整個瀑布模式幾乎都是以文檔驅動的，這對於非專業的用戶來說是難以閱讀和理解的。雖然瀑布模式有很多很好的思想可以借鑑，但是在過程能力上有天生的缺陷。
演化模式
它主要是針對事先不能完整定義需求的軟件開發。它的方法是用戶先給出待開發系統的核心需求，並且在覈心需求實現後，再提出反饋以支持系統的最終設計和實現。也就是說：開發人員首先會根據用戶的需求開發核心系統，然後提供給用戶試用；用戶試用後再提出增強系統能力的需求；最後開發人員再根據用戶的反饋，實施迭代開發。實際上，這個模式可看作是重複執行的多個瀑布模式。演化模式要求開發人員把項目的產品需求分解爲不同組，以便分批循環開發。但這種分組並不是隨意性的，而是要根據功能的重要性及對總體設計的基礎結構的影響而作出判斷。
螺旋模式：
它是瀑布模式與演化模式相結合，並加入兩者所忽略的風險分析所建立的一種軟件開發模式。螺旋模式基本的做法是在瀑布模式的每一個開發階段之前，引入非常嚴格的風險識別、風險分析和風險控制。直到採取了消除風險的措施之後，纔開始計劃下一階段的開發工作。否則，項目就很可能被暫停。另外，如果有充足的把握判斷遺留的風險已降低到一定的程度，項目管理人員還可作出決定讓餘下的開發工作採用另外的生命週期模式，如演化模式，瀑布模式或自定的混合模式。
過程開發模式：
它又叫混合模式或元模式，是指把幾種不同模式組合成一種混合模式，它允許一個項目能沿着最有效的路徑發展。因爲上述的模式中都有自己獨特的思想，現在的軟件開發團隊中很少說標準的採用那一種模式的，因爲模式和實際應用還是有很大的區別的。實際上，許多軟件開發團隊都是在使用幾種不同的開發方法組成他們自己的混合模式。
最後，我們來總結一下。螺旋模式是典型的迭代式生命週期模式，而RUP則是近代迭代式生命週期的代表。與螺旋模式相比，RUP將風險管理放在更重要的地位。最新的迭代式生命週期模式的代表是模式驅動架構（MDA）和敏捷（Agile）軟件開發。MDA模式是基於可執行規格說明的思想，是現代轉換模式的代表，其核心技術是組件技術。而敏捷開發生命週期的典型代表是XP編程，是把傳統的系統設計和實現由敏捷軟件開發過程中的驗收測試、重構和測試驅動所取代；把傳統的集成和部署由敏捷軟件開發中的持續集成和短週期所取代。
具體介紹敏捷開發的過程
敏捷開發主要包括三個角色，四個儀式，和三個物件，下面一一介紹
三個角色
產品負責人
產品負責人（Product Owner）：它是開發團隊和客戶或最終用戶之間的聯絡點。
- 代表產品線的利益,與Scrum Master和Scrum Team合作
- 負責管理和確定產品記錄的優先次序,角色負責產品的遠景規劃
- 側重於投資回報ReturnOf Investment
Scrum Master
Scrum專家（ScrumMaster）：Scrum專家負責指導開發團隊進行Scrum開發與實踐,它也是開發團隊與產品擁有者之間交流的聯絡點。
- 爲Scrum Team服務,確保每一個成員都認同Scrum價值觀和遵守其遊戲規則
- 組織每天的DailyScrum會議
- 負責保證Scrum Team的持續進展
- 決策和免除障礙
- 幫助Scrum Team規劃Sprint計劃
團隊
團隊成員（Team Member）：即項目開發人員。
- 自我管理,自我組織,多功能,通常由6 – 10人組成
- 負責將ProductBacklog轉化成Sprint中的工作項目
- 所有團隊成員協調,合作和完成Sprint中每一個規定的工作
- 所有團隊成員和ScrumMaster負責每一個Sprint的成功
四個儀式
Sprint計劃會議
每日站會
- 開發團隊成員召開，一般爲15分鐘。
- 所有成員必須參加，每個人給全體成員彙報工作進展。
- 更新燃盡圖。
- 每個開發成員需要向ScrumMaster彙報三個項目：
遇到了障礙無法繼續下去？
明天要做什麼？
- 通過該會議，團隊成員可以相互瞭解項目進度。
Sprint評審會議
Sprint評審會用來演示在這個Sprint中開發的產品功能給Product Owner. Produc Owner會組織
- 這階段的會議並且邀請相關的干係人蔘加。
- 團隊展示Sprint中完成的功能
- 一般是通過現場演示的方式展現功能和架構
- 不要太正式
- 不需要PPT
- 一般控制在2個小時
- 團隊成員都要參加
- 可以邀請所有人蔘加
Sprint回顧會議
- 團隊的定期自我檢視，發現什麼是好的，什麼是不好的。
- 一般控制在15-30分鐘
- 每個Sprint都要做
- 全體參加
- Scrum Master
- 產品負責人
- 團隊
- 可能的客戶或其它干係人
Sprint回顧會議上，全體成員討論有哪些好的做法可以啓動，哪些不好的做法不能再繼續下去了，哪些好的做法要繼續發揚。
三個物件
產品Backlog
一個需求的列表：
- 一般情況使用用戶故事來表示backlog條目
- 理想情況每個需求項都對產品的客戶或用戶有價值
- Backlog條目按照商業價值排列優先級
- 優先級由產品負責人來排列
- 在每個Sprint結束的時候要更新優先級的排列
Sprint Backlog
將整個產品的backlog分解成Sprint Backlog，這個Sprint Backlog是按照目前的人力物力條件可以完成的。
團隊成員自己挑選任務，而不是指派任務。
每個團隊成員都可以修改Sprintbacklog，增加、刪除或者修改任務。
燃盡圖
燃盡圖直觀的反映了Sprint過程中，剩餘的工作量情況，Y軸表示剩餘的工作，X軸表示Sprint的時間。隨着時間的消耗工作量逐漸減少，在開始的時候，由於估算上的誤差或者遺漏工作量有可能呈上升態勢。
當然，知道了敏捷開發的組成部分，更要知道敏捷開發的流程，下面用一幅圖來說明：
敏捷開發的先決條件
很多人會問，既然敏捷開發這麼好，可以解決這麼多的問題，爲什麼不是所有人所有項目都在使用敏捷開發呢，這就涉及到了實行敏捷開發的先決條件：
一、團隊有三名或以上的研發工程師；
二、團隊內有一名合適的Scrum Master。
當團隊內無法找到合適的Scrum Master時，不要輕易推行敏捷。如果你的團隊是由新人組成，或者即使有資深員工但是他並不瞭解或認同敏捷開發的話，那麼你需要等待合適的Scrum Master出現。
