本文作者將結合自身經驗，與大家一起來聊聊敏捷流程中每個環(huán)節(jié)的主要任務及內容。enjoy~

說到敏捷開發(fā)，相信大家都多少有了解。目前大部分互聯(lián)網公司的開發(fā)模式肯定不是傳統(tǒng)的瀑布式開發(fā)，更多的應該是偏向于敏捷開發(fā)。最近一段時間參與的項目，項目組采用的是敏捷開發(fā)迭代制度，雖然可能和嚴格意義上的敏捷開發(fā)有所區(qū)別，但是適合的才是最好的。在實踐中，通過項目的反思總結，制定適合自己團隊的敏捷模式是最好的。

首先簡單來介紹一下敏捷開發(fā)：敏捷開發(fā)以用戶的需求進化為核心，采用迭代、循序漸進的方法進行軟件開發(fā)。在敏捷開發(fā)中，軟件項目在構建初期被切分成多個子項目，各個子項目的成果都經過測試，具備可視、可集成和可運行使用的特征。換言之，就是把一個大項目分為多個相互聯(lián)系，但也可獨立運行的小項目，并分別完成，在此過程中軟件一直處于可使用狀態(tài)——來自百度百科。簡單來講，在快速發(fā)展的互聯(lián)網時代，開發(fā)周期不宜太長，采取小步迭代，更能適應當今這個時代。

網上的敏捷開發(fā)的流程圖是這樣的：

我們項目組的流程，實際是這樣的：

雖然和許多標準的敏捷流程不完全一樣，但其實我們的流程保留了核心的幾個環(huán)節(jié)。接下去來聊聊每個環(huán)節(jié)的主要任務及內容。

需求整理階段

時間：此環(huán)節(jié)的時間往往不計入迭代周期，一方面是需求和設計經常會發(fā)生變動，而功能設計確定后，進入開發(fā)階段的變動比較少；另一方面是開發(fā)在進入當前迭代的時候，此時產品就應該進入到下一個迭代的設計周期了。

參與人員：產品人員、技術負責人、項目經理

工作任務：此環(huán)節(jié)任務其實不少，包括了產品人員對迭代的需求進行梳理，對需求完成設計。產品在完成產品方案后，小范圍召集產品經理、技術負責人、進行評審。在交互稿、設計稿都完成后，進行召開迭代會議。

產品關注：此階段產品的主要工作是在需求池中進行篩選，整理出高優(yōu)先級的任務，作為此次迭代的功能列表。因筆者都是在小公司，所以產品文檔、交互稿都是由產品人員通過原型來展現(xiàn)。

踩過的坑：某次該會議叫了過多的人，導致會議時間過長，會議效果也不好（由于此環(huán)節(jié)主要是對總體功能列表進行討論，只需叫上產品小隊、技術負責人就夠了）；還有就是設計的原型在此階段就做的太細，導致部分需求其實并不需要（此環(huán)節(jié)設計以大的框架及流程為主，細節(jié)的交互、規(guī)則等可以在之后再根據需要進行完善）；

迭代會議階段

時間：此環(huán)節(jié)為迭代周期正式開始

參與人員：項目組所有人員

工作任務：此階段為任務講解、計劃。主要為產品經理對此次迭代的主要任務進行講解，包括需求來源、產品設計，技術人員對此次迭代的時間進行排期。

產品關注：該會議就是傳說中的評審會議。產品要多做準備工作，因為會有很多人來懟你，主要還是以業(yè)務流程、規(guī)則、交互等具體實現(xiàn)的東西，因為技術要進行開發(fā)，很多東西需要問清楚。

踩過的坑：這個環(huán)節(jié)坑就是看被懟的慘不慘? 。主要有兩方面的準備吧，一個是人，因為前期有準備過小范圍的評審（需求整理會議），你要拉攏其他的人員認可你的東西，這樣在會議中，這部分人會幫你回答（至少不會提問你）；另一方面還是文檔（原型），在設計的時候要多思考，把各種情況考慮全，這樣在會議中被提問時，就能夠很好的回答他人。

迭代計劃階段

時間：開發(fā)、測試階段

參與人員：項目組所有人員

工作任務：此階段為開發(fā)階段，技術負責人對功能列表進行拆分、排期，開發(fā)人員開始進入編碼階段。測試人員根據需求書寫測試用例，在開發(fā)完成提成后，進行產品測試。

產品關注：本階段產品主要是和開發(fā)人員保持溝通，一些在開發(fā)過程中會發(fā)現(xiàn)的有疑問的地方，需要產品去決策，該如何做。產品提測后，產品人員也要及時去對開發(fā)好的功能進行驗證，看是否符合預期。在這間隙，產品需要開始對下一個迭代的需求進行梳理。

每日例會：此會議初衷是對每天的工作進行回顧，主要是看當天的任務完成情況，是否有難處等，讓大家對項目的進度有一個了解。但是實際應用中，我們的例會效果不是很好。建議通過一些協(xié)作工具，用圖表來展示，這樣更有直觀性。

踩過的坑：迭代過程中最大的坑應該是需求變更了。原則上迭代會結束后，不能在此迭代里新增需求。但是需求變更常常就會有新增，這時候需要去評估。如果是改動大的需求，需要召集小分隊人員進行討論，看是否必要加入此次需求；如果是小的改動，則進行相關文檔的更新，并通知到項目組成員。

發(fā)布演示階段

時間：開發(fā)測試完成后，進行產品的發(fā)布更新

參與人員：項目組所有人員

工作任務：此階段為迭代的尾聲，在測試完成后，根據需要在不同的環(huán)境進行發(fā)布，發(fā)布后，可能需要去演示。

產品關注：到此階段，就正式完成一個迭代的周期了。產品人員應該也梳理好了下一個迭代的需求，在本迭代發(fā)布且通過后，就需要開始新一輪的迭代工作了。

踩過的坑：更新經常到更凌晨。發(fā)布前一定要做好測試、發(fā)布前準備工作，要定好發(fā)布計劃，不然很容易陷入到發(fā)布-測試-發(fā)現(xiàn)bug-修改bug-測試-發(fā)現(xiàn)新的bug….反正每次更新都不省心，經常到凌晨。

本文由 @pauly?原創(chuàng)發(fā)布于人人都是產品經理。未經許可，禁止轉載。

題圖來自 Unsplash，基于 CC0 協(xié)議