行業內有太多人吐槽敏捷開發，原因各不相同，有覺得 Agile 就是一坨翔的，有覺得 Agile 太低效的，也有覺得團隊小暫時不需要敏捷的，etc。
人的本性都是敏捷的，誰都不想浪費寶貴的時間。抱怨敏捷的人，一是對敏捷理解不夠深刻，生搬硬套，覺得不行，然后就一大堆抱怨；二是老板覺得敏捷不能完全的壓榨勞動力，也就是行業金句——工作不飽和。
美國人埃里克·萊斯提出了《精益創業》的方法論，它強調的是在風險極高、創業資本有限的情況下，需要快速摸索出最小化可行產品（MVP）盡早進行市場驗證，現在精益創業已風行創業領域，但是如何將此方法論具體應用到創業團隊產品開發的實踐之中？很多創業公司/團隊聲稱自己的精益創業，然而卻對團隊管理漠不關心，更別說敏捷開發，開發流程亂七八糟，全是小作坊操作，美其名曰：我們要快速的迭代產品，顧不上這些。
我在敏捷的團隊做過好幾年，敏捷的目的并不是為了讓開發事兒更少，而是讓大家在有限的時間效率更高。在工作量不變的情況下，更少加班；在工作時間不變的情況下，產出更大。
在歐美軟件企業中,有近半數企業已采用敏捷方法進行開發，硅谷FLAG，國內如騰訊、阿里、百度、Fackbook、Yahoo!等等一線互聯網公司內部幾乎所有的開發團隊都在實施敏捷方法。相關統計表明，敏捷開發可以將效率提高3~10倍，項目質量也有更加可靠的保證。
什么是敏捷開發？
- 敏捷開發(Agile Development)是一種以人為核心、迭代、循序漸進的開發方法。
怎么理解呢？首先，我們要理解它不是一門技術，它是一種開發方法，也就是一種軟件開發的流程，它會指導我們用規定的環節去一步一步完成項目的開發；而這種開發方式的主要驅動核心是人；它采用的是迭代式開發；
- 為什么說是以人為核心？
我們大部分人都學過瀑布開發模型，它是以文檔為驅動的，為什么呢？因為在瀑布的整個開發過程中，要寫大量的文檔，把需求文檔寫出來后，開發人員都是根據文檔進行開發的，一切以文檔為依據；而敏捷開發它只寫有必要的文檔，或盡量少寫文檔，敏捷開發注重的是人與人之間，面對面的交流，所以它強調以人為核心。
- 什么是迭代？
迭代是指把一個復雜且開發周期很長的開發任務，分解為很多小周期可完成的任務，這樣的一個周期就是一次迭代的過程；同時每一次迭代都可以生產或開發出一個可以交付的軟件產品。
敏捷的套路 —— 實踐框架
- XP（極限編程）較早出現在中國的原因，得益于當初翻譯的幾本書（2001年），不過有點極端了，很多傳統企業都不能適應。
- Scrum 是精益創業很好的實踐方法，概念清晰，可操作性強，落地快，在中國也出現了日漸普及的態勢；當然罵聲也不少，認為它什么都沒講，太虛了。實際上他們大多數人把自身的問題歸結于 Scrum 了。
- FDD（Feature Driven Development）等還有一些其他的過程，聲音慢慢就越來越少了。
目前流行的敏捷套路就只有 Scrum 而已，另外一些都越來越少有被人提起了。
這里，我們主要以 Scrum 來講解敏捷，但千萬別以為 Scrum 就是敏捷。
- 關于Scrum和XP
前面說了敏捷它是一種指導思想或開發方式，但是它沒有明確告訴我們到底采用什么樣的流程進行開發，而 Scrum 和 XP 就是敏捷開發的具體方式了，你可以采用 Scrum 方式也可以采用 XP 方式；Scrum 和 XP 的區別是，Scrum 偏重于過程，XP 則偏重于實踐，但是實際中，兩者是結合一起應用的，這里主要講 Scrum。
Scrum 關鍵詞匯解釋
product backlog: 可以預知的所有任務， 包括功能性的和非功能性的所有任務。
sprint: 一次跌代開發的時間周期，一般最多以30天為一個周期.在這段時間內，開發團隊需要完成一個制定的backlog,并且最終成果是一個增量的，可以交付的產品。
sprint backlog: 一個 sprint 周期內所需要完成的任務。
Scrum Master: 確保團隊合理的運作 Scrum，并幫助團隊移除實施中的障礙。
PO (Product Owner): 即產品負責人，確定產品的方向和愿景，定義產品發布的內容、優先級及交付時間，為產品負責。
scrum team(開發團隊): 一個跨職能的小團隊，包括開發測試，人數5-9人為佳，團隊擁有交付可用軟件需要的各種技能。
time-box: 一個用于開會時間段。比如每個 daily scrum meeting(每日站立會議) 的time-box為15分鐘。
sprint planning meeting: 在啟動每個sprint前召開。該會議需要制定的任務是：PO 和團隊成員將 backlog 分解成小的功能模塊,決定在即將進行的 sprint 里需要完成多少小功能模塊，確定好這個 Product Backlog 的任務優先級。另外，該會議還需詳細地討論如何能夠按照需求完成這些小功能模塊。制定的這些模塊的工作量以小時計算。
-
Daily Scrum meeting：開發團隊成員召開，一般為15分鐘。每個開發成員需要向 team 匯報三個項目：
- 昨天完成了什么，完成了百分之多少，還剩百分之多少？
- 今天你打算做什么？
- 完成你的目標是否存在什么障礙？
通過該會議，團隊成員可以相互了解項目進度。
Sprint review meeting：在每個 Sprint 結束后，這個Team將這個 Sprint 的工作成果演示給 Product Owner，客戶，老板和其他相關的人員。
Sprint retrospective meeting：對剛結束的Sprint進行總結。會議的參與人員為團隊開發的內部人員。一般該會議為1小時。
什么是scrum?
Scrum的基本假設是：
開發軟件就像開發新產品，無法一開始就能定義軟件產品最終的規程，過程中需要研發、創意、嘗試錯誤，所以沒有一種固定的流程可以保證專案成功。Scrum 將軟件開發團隊比擬成橄欖球隊，有明確的最高目標，熟悉開發流程中所需具備的最佳典范與技術，具有高度自主權，緊密地溝通合作，以高度彈性解決各種挑戰，確保每天、每個階段都朝向目標有明確的推進。
Scrum 開發流程通常以 30 天(或者更短的一段時間)為一個階段，由客戶提供新產品的需求規格開始，開發團隊與客戶于每一個階段開始時挑選該完成的規格部分，開發團隊必須盡力于 30 天后交付成果，團隊每天用 15 分鐘開會檢查每個成員的進度與計劃，了解所遭遇的困難并設法排除。
Scrum 三大角色
Scrum“角色”–無規矩不成方圓
- PO
必須有一個項目持有者，制定規劃并把握項目走向，一般就是產品經理。 - SM
敏捷教練。一般由對技術開發以及當前項目明晰的技術經理擔任。 - TEAM
Scrum 的流程
我們首先需要確定一個 Product Backlog（按優先順序排列的一個產品需求列表），這個是由 Product Owner 負責的；
正式開始一個 sprint 開始之前，產品、研發、測試需要一同開一次 sprint planning meeting，共同討論本次 sprint 的功能點，需求討論或技術討論；成員預估需求所需開發時間；團隊輸出是否滿足需求，排入 sprint backlog；
planning meeting 下來之后每個團隊成員對自己在這個sprint中的工作進行整理，拆分小任務，預估開發完成時間，自己排自己的優先級；
進行 Daily Scrum Meeting，這個環節在 agile 中非常關鍵，是 agile 的日常修煉，控制在15分鐘左右，每個人都必須發言，并且要向所有成員當面匯報你昨天完成了什么，并且向所有成員承諾你今天要完成什么，同時遇到不能解決的問題也可以提出來尋求幫助。完了以后SM負責根據結果更新 burndown chart；
當一個 Sprint 結束時，我們要進行 Sprint Review Meeting，也稱為評審會議，產品負責人和客戶都要參加，每一個Scrum Team的成員都要向他們演示自己完成的軟件產品（這個會議非常重要，一定不能取消）；
最后就是 Sprint Retrospective Meeting，復盤這個 sprint，以輪流發言方式進行，每個人都要發言，總結并討論做得好的地方、需要改進的地方；根據實際情況進行下一個 sprint 的任務安排。
這樣周而復始，按照同樣的步驟進行下一次Sprint.
Scrum 的特性
- 不斷交付軟件以滿足客戶需求，每個迭代版本都是可運行的
- 歡迎需求的變化
- 及時溝通，拒絕過度設計
- 量化了工作項目的進度和團隊的產出
- 流程簡單，溝通順暢
隨便總結一下
敏捷是一種流程、方法、理念，甚至信仰；
敏捷不是一種工具，不是用了敏捷的軟件就是敏捷了；
敏捷是為了團隊成員能夠更加緊密地配合完成工作；
敏捷是需要本土化的，可以根據項目團隊的情況指定自己的敏捷計劃。
