15年的時候我所在的團隊開始使用敏捷開發。現在新公司也在逐漸向敏捷開發傾斜。所以寫篇文件記錄下。
首先，先介紹下什麼是敏捷開發
百度來的：是一種從1990年代開始逐漸引起廣泛關注的新型軟件開發方法，是一種能應對快速變化需求的軟件開發能力。它們的具體名稱、理念、過程、術語都不盡相同，相對於“非敏捷”，更強調程序員團隊與業務專家之間的緊密協作、面對面的溝通（認爲比書面的文檔更有效）、頻繁交付新的軟件版本、緊湊而自我組織型的團隊、能夠很好地適應需求變化的代碼編寫和團隊組織方法，也更注重軟件開發過程中人的作用。
我的感知，敏捷開發比較適用於需要快速迭代的項目；
敏捷開發是分小組開發的，每個小組的每個平臺配備2到3名開發人員。比如我們原公司做敏捷的時候，每個小組有三名安卓，三名IOS，三名服務端，三名測試。
敏捷開發週期一般爲兩週，這兩週可以發一個迭代版本，也可以不發。但是開發週期，是以開發提交代碼，測試全部驗證通過爲目標的。
其次，介紹下敏捷開發的流程：
一/澄清會，
時間點是第一週的週五
產品經理那邊會有一個需求池，這裏面裝載了所有的需求。產品經理需要對這些需求列一個優先級，然後在澄清會上按照優先級逐條講需求。開發/測試可以對些需求提出自己的疑惑，甚至可以質疑這條需求做的價值，產品經理必須回答，如果需求不明確或者依賴方沒有完成，則需求會被當場砍掉，挪到下一次。
每次澄清會，開發都會評估出略超工作量的需求。工作量內的作爲承諾是要完成的，非承諾的則是完成順利的情況下可以完成的（比如承諾的需求臨時被砍掉，或者實際工作量要比估點小等等）。完成這些需求，就是一個開發週期的目標。
二/需求調研
時間點是澄清會結束到第二週的週三
開發針對產品列出來的需求，根據優先級去挨個的需求調研，調研要求精確到改哪個類。並規劃好時間，開發需要列出來什麼時間點提測什麼？同樣的話，測試也需要列出來大體的測試用例，冒煙測試case等等。這時候如果發現需求有問題，會主動和產品經理溝通。
需要注意的時，這段時間週期上仍屬於上一個開發週期，這期間開發測試的主要工作仍然是解決上一個週期內發生的bug。開發只是利用空餘時間進行方案調研。
三/計劃會
時間點是第二週的週三
計劃會上，演講的主角變成了開發和測試。這時候，開發需要講方案，產品來聽。如果開發在調研過程中發現需求依賴不滿足等問題，可以在計劃會上將該需求砍掉。同樣，如果優先級發生變化，產品經理也可以在計劃會上調低某個需求的優先級。
計劃會後，正式進入新的一個開發週期，一般是持續兩週。
四/需求開發
開始時間是計劃會後，一直持續到第四周的週三，也就是下一個計劃會。
這期間，開發測試需要完成所承諾的所有的需求的交付，交付的條件是完成開發和測試，並具備上線發佈的所有必要條件。承諾外的需求則是屬於加分項。
另外，開發測試每交付一個需求，產品經理都需要及時過來驗收。
五/回顧會
時間點一般是第四周的週五
這個時候上一個sprint開發週期已完成，新一期的任務纔剛開始，還不着急。大家坐在一起，回顧下上一個週期的問題