經常聽見敏捷開發這個詞，還有Scrum和XP，它們究竟都是什么意思，直接來聊一聊這幾個關于軟件流程和項目管理有關的常見話題。
話說軟件最開始出現的時候，開發規模很小，以小作坊開發的模式為主。后來，硬件發展起來，需要更大規模更復雜的軟件才能滿足需求，作坊式的生產軟件效率低，已經不能滿足這種規模的軟件項目開發，所以20世紀80年代出現了瀑布模型。
瀑布模型提出了一個軟件聲明周期的概念，其實就是強調按照：可行性研究-需求分析-設計-編碼-測試-運行維護，這樣的固定順序開始工作，就是相當于需求一旦確定，進入開發階段，需求就不能再改了。變更需求就只能在下個周期進行。這對頻繁變化的需求完成的效率非常低，所以又出現了敏捷開發。
什么是敏捷開發
敏捷開發是以用戶的需求進化為核心，采用迭代、循序漸進的方法進行軟件開發。
這個概念讀起來貌似有一點生硬，直接通過幾個典型的特性來說明。
1、快速迭代
2、開發和測試人員參與需求過程
3、合作溝通
就是在客戶還沒有明確要什么的時候，保持溝通合作持續改進，以用戶故事描述軟件需求。內部團隊保持簡潔高效的溝通，用站會等方式直接反饋工作進度，通過團隊的協作和優化反饋方式應對快速變化的需求，相應地縮短交付周期，最終通過不斷的澄清用戶需求，最終交付符合用戶價值的產品。
總結下來，其實敏捷是一種思想，敏捷開發就是敏捷思想的一個實際應用，一旦思想指導到實際應用，就具化成一些行之有效的手段和原則，比如極限編程（Extreme Programming即XP）、Scrum等這些都算是敏捷開發的一種應用框架。
什么是極限編程
為什么叫做極限？原因是XP強調把整個工作流程都做到極限，做到最好，包括極限工作環境、極限的需求、極限的設計、極限的編程、極限的設計，比如它要求交付用戶的版本一定時能夠使用的，重復冗余的代碼一定要被重構。而其它XP所不提倡的，則一概忽略（如開發前期的整體設計等）。
再來簡單介紹一個概念：用戶故事
用戶故事就是描述對用戶有價值的功能，簡單點說就是敏捷開發里強調的管理需求的方式。
極限編程的角色
產品經理：負責編寫用戶故事，排列故事優先級以及驗證用戶故事
項目經理：負責管理項目進度和流程
程序員：負責開發任務，并對代碼進行單元測試
極限編程的工作方式
1、產品經理從客戶處獲取需求，編寫用戶故事，并確定需求優先級；
2、開發和產品共同對需求清單進行評估，確定迭代周期，并按照優先級確定在該迭代周期內完成的需求；
3、進入開發階段，開發團隊每日更新進度，產品經理可以調整合理的需求，開發團隊做到快速響應；
4、迭代周期結束，產品經理驗收迭代結果，團隊總結進度預期經驗，并發布版本。
極限編程的價值
重視溝通，溝通方式不拘泥于形式，可以是談話、會議或者直接畫圖
簡單，以最簡單的方式解決需求
重視反饋，無論是用戶反饋還是團隊內部人員對產品的反饋
勇氣，有勇氣不斷優化產品功能
什么是Scrum
Scrum與極限編程類似，也是一種迭代遞增的開發過程。
Scrum角色
與極限編程類似，但是各類人員之間并沒有嚴格的區分，比如上線前夕，產品經理也可以兼職測試。
Scrum的工作方式
1、產品經理列出需求清單（產品Backlog），并選擇優先級高的需求作為本次迭代的需求；
2、項目經理給團隊成員分配開發任務，并進入開發，開發階段不允許變更本次迭代的需求；
3、開發階段每天進行簡會（Daily Scrum），審查進度，反饋問題；
4、迭代周期結束，產品經理驗收迭代結果，團隊總結進度預期經驗，并發布版本。
二者的區別
Scrum團隊典型地工作在一個從2周到4周為長度的迭代周期中（也被稱為Sprints）。而XP團隊典型地工作在從1周到2周為長度的迭代周期中。
Scrum團隊在Sprints迭代周期中不允許發生變更。XP團隊經常在他們的迭代周期中進行變更。只要XP團隊還沒有開始開發一個特定的功能，在XP團隊的迭代中可以使用與之前功能規模等價的新的功能來替換還沒有開始開發的功能。
XP團隊的開發工作嚴格遵守優先級順序。相比之下，Scrum團隊產品負責人排列的優先級排序，開發團隊并不完全按照這個順序開發，會有一些調整。
總結
在Scrum和XP雖然存在區別，但是主要思想依舊是敏捷開發，在進行項目管理時還是要根據團隊情況，選擇合適的應用框架。敏捷開發模式可以讓產品在市場上快速試錯，根據數據的反饋進行及時的戰略調整，讓產品在市場立于不敗之地，而在這個過程中，產品經理無疑是最重要的一個角色。
作者：一枚電商產品妹子，愛產品，愛生活。（微信公眾號：產品愛磨嘰）
