剛接觸敏捷一個月左右，看各種設計模式、TDD、scrum、xp，但是當別人問到我什麼是敏捷開發的時候，還是不知道怎麼去回答，所以就想著，是時候理一下這些天學習的關於敏捷的所有，在心裡搭一個框架。

什麼是敏捷開發？

在《高效程式設計師的45個習慣：敏捷開發修煉之道》中這樣寫道：敏捷開發就是在高度協作的環境中，不斷地利用反饋進行自我調整和完善。

紅色的關鍵字也指出了敏捷開發的三個特點：高度協作——以人為核心，不斷自我調整和完善——持續整合，循序漸進，反饋——迭代開發，儘早反饋。

何為高度協作？

由於大學課程軟體工程的限制，還有一些小公司的實習經歷，曾一度讓我以為瀑布式開發就是最正確的，一葉障目。與敏捷不同，瀑布式開發是以文件為核心的，嚴格遵循預先計劃的需求、分析、設計、編碼、測試的順序，各個環節彼此分離，主要依靠記錄的文件進行溝通，要求寫詳細的文件，但是，任何人在做任何事之前，都不可能預測出所有的可能性，一次性設計完美，所以可想而知，這樣的開發方式，會導致整個專案週期又臭又長，問題不斷，返工不斷，效率低下，嚴重打擊團隊成員的積極性，工作乏味。但是敏捷開發呢，強調以人為核心，各個環節的人面對面交流，使用者也參與其中，客戶協作勝過合同談判，只寫必要的文件，人為可工作的軟體勝過面面具到的文件，團隊中所有人一起工作，不論哪個環節，有問題及時提出，溝通調整，響應變化勝過遵循計劃，所以敏捷開發可以及時發現問題，防患於未然。

何為不斷自我調整和完善？

敏捷開發強調開發要持續不斷，只要有人使用這個軟體，開發就沒有真正結束。在《高效程式設計師的45個習慣》中這樣寫道：為什麼要持續開發呢？因為軟體開發是一件複雜的腦力勞動，任何遺留下來的問題，要麼僥倖不會發生意外，要麼使情況變的更糟，慢慢惡化到不可控制。面對這樣的問題，唯一的辦法就是持續地推進和完善專案，把問題扼殺在萌芽狀態。

何為反饋？

敏捷開發將冗長的專案週期劃分為一個一個短暫的小週期，每個週期都有一個可交付的產品，一個週期就是一個迭代，每個迭代的成果都要給客戶演示，及時獲得反饋，定期回顧，持續改進，這樣小步開發，及時獲得反饋，就不會出現像瀑布開發一樣到最後交付出使用者不滿意到產品，然後再大動筋骨地改造，耗費成本。

敏捷開發的好處是什麼？

從敏捷開發的特點不難看出它的好處，提高開發效率，每一次迭代都能及時獲得使用者的反饋，大方向不容易走錯，步步為營，不用返工，效率必然提升；降低開發成本，不用返工，自然成本降低；提高產品質量，敏捷開發要求團隊成員面對面工作，及時溝通，交流程式碼，共同進步，產品的質量自然高，也不容易出現一個人離開團隊，其他人就無法接受他的工作他的程式碼這樣的事。

怎樣敏捷開發？

敏捷開發的具體方式有兩種，scrum和xp（極限程式設計）。xp有五個核心價值觀：交流、簡單、反饋、勇氣、謙遜，xp偏重實踐，成功打破了軟體工程“必須重量”才能成功到觀念。scrum偏重過程，是一個包括了一系列的實踐和預定義的過程骨架（是一種流程、計劃、模式，用於有效地開發軟體）。兩種方法在實際使用中可以結合使用，這裡主要介紹scrum，後期補充xp。

scrum

像上面提到的，scrum是一個過程，這個過程通過一些角色的設定和配合使團隊能高效工作，就像這個詞的漢語意思”爭球“，迅速，激情。

scrum中的角色設定

產品負責人（product owner）：確定產品是否達到標準，確定釋出日期及釋出內容。

scrum主管（scrum master）：負責scrum過程順利進行，使整個過程收益最大化。

開發團隊（scrum team）：負責開發工作，一般5到10人，團隊人員自我管理能力很強，每個人可能負責不同的技術。

scrum的工件

產品訂單（product backlog）：按照優先順序排列的高層需求，有product owner負責。

衝刺訂單（sprint backlog）：要在衝刺中完成的任務清單，一個sprint通常為2～4周，就是一個迭代，衝刺訂單記錄了本次迭代要完成的工作以及具體安排。由scrum team制定，越細越好。

衝刺燃盡圖（burn down chart）：在衝刺長度上顯示所有剩餘工作時間逐日遞減的圖。

scrum的活動

計劃會（sprint planning meeting）：在每個衝刺之初，由產品負責人講解需求，並由開發團隊進行估算的計劃會議。 每日立會（daily standup meeting）：團隊每天進行溝通的內部短會，站立參加，因為站立可以避免在椅子上打盹兒，事實上是比坐著效率高，一般只有15min左右。 評審會（review meeting）：在衝刺結束前給產品負責人演示並接受評審的會議。 回顧會（retrospective meeting）：在衝刺結束後關於自我持續改進到會議。

scrum工作週期圖