敏捷開發是很多互聯網公司的運行模式，但不同公司有著不同的運作方式。這篇文章，作者分享了自己在大廠做敏捷開發的流程，可以和大家所在公司的流程相互印證，查漏補缺。

互聯網產研團隊一般都是按照敏捷開發的流程進行協作的，我在互聯網大廠的敏捷開發是怎么進行的呢。

一、迭代周期

我們團隊的迭代周期一般是2周，如果研發評估時間過長的話也會將周期延長至一個月，但是大多數我們是2周的迭代周期。

這里說的2周是研發開始coding、提測、測試、上線，也就是說2周以后要上線相應的能力。并不包括產品需求設計與評審的時間。

2周的時間一般coding的時間為6到7天，本次迭代功能測試3天，整體功能回歸測試2天。一般會分步提測（某些能力在第三天的時候開發完成就能提測），不然整體時間會超出兩周（10工作日）。

二、團隊規模與職責

我們團隊當時負責的是一個新產品，產品形態包括app，web，pc客戶端，整個團隊成員包括產品1人，研發6人，測試1人。UED有通用的部門支持。產品經理負責產品設計與項目管理，橫向與縱向的信息同步溝通并對結果負責，研發會選出一人兼職來當技術負責人，主要負責制定技術方案與研發排期的工作，對最終的研發落地負責。

三、需求準備階段

作為產品經理我一般都是在迭代開始前2周或提前一個月來準備需求，不然會導致研發資源空置同時也會影響下一個階段的排期計劃。

需求準備時要想好本次迭代要解決用戶的哪些問題或為用戶創造的價值，也可以稱為本次迭代的主題，是否是在整體roadmap的路線上。確認本次的迭代方向后及時與團隊成員進行溝通與信息的同步，如有問題需要及時調整迭代方向。

需求來源主要包含之前制定的roadmap能力以及用戶高頻反饋的問題，所有需求統一管理在需求池中，通過我們內部的項目管理工具進行統一管理。

需求準備階段要提前協調各方資源與信息的同步，看看各方對需求的看法與問題，不要把問題遺留到需求評審階段，提前做好相關準備。

該階段主要產出產品文檔與UI設計稿(產品經理協同UI產出設計稿)并通過產品內部的初步評審。每個需求需要保證完整的閉環，而且要控制整體的需求研發時間，防止無法按時交付的問題。在需求準備階段可能會出現需求不符，需要重新設計的情況，需要產品經理能頂住壓力重新設計新的方案。一般情況，需求文檔需要改進2到3次才能通過內部的初審。UI設計稿也需要多次調整直至符合產品需求為止。

需求準備階段是敏捷開發開始階段也是最最重要的階段，準備的需求需要與上級，各干系人，核心用戶都同步且沒有大方向問題后再進入下一個階段。

四、需求評審階段

一般會在上個迭代的整體功能回歸測試時，大概有2到3天的時間進行本次迭代的需求評審，產品經理負責同步本次的需求文檔和UI設計稿（產品主講，UI輔助）。

在這個階段是需要產品，研發 ，測試，UI深度參與的階段，研發和測試會提出很多問題，可能是邏輯問題，交互細節問題，甚至有些問題會推翻整個需求設計進行重構。這期間需要產品經理記錄并解決研發提出的所有的問題，有些問題能立刻解決，但是有些問題會耗時長一些。

需要鼓勵大家提出問題（最好是站在用戶角度提問題），這樣避免在后續的階段造成成本浪費。大家提出問題非?？简灝a品經理的處理方式，產品經理需要站在用戶角度去分析解決問題，提升大家在此階段的參與度。同時產品經理要能接受不同的聲音，如果是真的問題需要敢于否定自己，并抓緊準備新的需求。

需求評審完成后產品經理將相關的產品資料同步至迭代看板中（內部的項目管理工具），供技術負責人進行整體排期。

五、研發評估排期階段

該階段技術負責人會與研發同步技術方案，各端研發會按照實際情況評估所需時間。會存在評估時間與迭代時間沖突的情況，產品經理需要協調團隊內部解決，無法解決的需要上升解決。協調資源或者趕進度等方式。減少需求的情況也會發生，但屬于比較差的解決方案。

研發評估排期后需要與測試、產品經理確認提測時間與上線時間。測試會依據研發時間評估測試所需時間，出現整體排期問題時，產品經理需要協調各方資源與時間保證本次迭代的落地。

一經確認排期時間需要各方準確保證，因為涉及多方協作，需要避免出現延期問題。保證準確交付。評估排期需要每個人都對自己的排期負責，需要保證排期的準確性。

排期確認后需求就進入了研發階段，每個需求在研發階段都會確認一個研發負責人，該負責人負責跟進需求的進度，解決需求開發過程中遇到的技術問題，保證需求能順利提測并上線?；旧厦總€研發都會負責一個需求，該措施能確保每個需求都有負責人進行跟進，保證需求在開發過程中能直接找到對應負責人，同時也鍛煉了負責人的橫向能力。

六、研發階段

研發階段團隊成員每天通過早站會的方式同步每個需求的進度，在會議之前需求的研發負責人都會在需求看板中更新當前的研發進度，問題與風險，當天的問題原則上需要當天解決，會議中大家也會對著需求看板同步進展。

雖然研發階段遇到的問題也會很多，但是基本上不會遇到顛覆性的問題(因為前期團隊已經解決了大方向上的問題，在需求準備與排期階段已經有了比較充分的討論)，如果真的遇到顛覆性的問題需要產品經理協調相關成員盡快確認解決方案同時要避免再次出現此類問題。

研發階段開始時產品經理就需要開始準備下個迭代的需求，以保證下個迭代能順利開始。

在此階段測試人員會準備好測試用例，并在研發開發完成前完成測試用例評審，研發自測也會依據測試用例完成自測走查

七、測試階段

開發完一個需求后，產品經理會進行功能驗證并發起提測單，產品驗證后提測能保證是按需求開發的，提高測試人員的效率。

測試人員在此階段會進行3天(一般為3天左右，實際會按照需求進行調整)的功能測試(包括app web pc客戶端)，研發也會在這三天內修改bug。

在此階段產生的bug需要解決并趨向于零，bug的產生有可能是產品需求引起的，可能是歷史原因引起的，整體的原則是不能帶問題上線，需要盡快解決問題，有些bug屬于需求問題的需要盡快給出解決方案。如遇到當前迭代不能解決的問題也需要確認解決方案后安排到最近的排期迭代中。

此階段是產品上線前的最后階段，對測試人員的要求很高，需要進行功能，視覺，交互等測試，也需要提出自己在測試中遇到的需求問題?？傊枰獙y試結果與線上問題負責。同時產品經理在此階段也需要提前介入測試，如遇到問題提前調整，避免遺留問題。

功能測試完成后，研發會將本次迭代功能上線至預發環境將整體的能力進行回歸測試，回歸測試大概有2到3天的時間，產品與研發可以在此階段評審下個迭代的需求。

八、上線與用戶反饋跟進

上線后要及時通知用戶本次的上線內容并收集用戶反饋，對用戶反饋的問題要及時跟進處理，處理完成后要反饋用戶。整體原則是避免線上存在問題對用戶產生影響，線上問題屬于優先級比較高的問題，要第一時間處理。

用戶反饋的問題也可能是需求，需要產品經理判斷好優先級并給出相對準確的回復，比如什么時間上線，或者不做的原因，維護好與用戶之間的關系。

每一個能力都是解決用戶的問題，如果某項能力上線后沒有達到預期，團隊則需要復盤原因，避免下一次出現此類問題，每次都需要保證研發資源都用在了正確的產品路徑上。

九、小結

我們團隊迭代總體來說是非常緊湊的，人效使用是比較高的，每天都會遇到各種各樣的問題，有些問題甚至會影響排期時間，但是基本不會出現最終交付延期的情況，因為前期的計劃會同步上級也會同步到用戶，出現延期的話影響的范圍是非常廣的，而且對用戶也會造成不誠信的問題，所以一旦計劃制定后就不能輕易更改，這也推動了產品經理與研發在前期要進行充分的討論與評估，也會促進成員抗壓能力的提升。同時延期一旦產生也就代表團隊的交付能力出現了問題，要及時進行復盤并進行解決方案的落地。

每個階段在推進的過程中不會很理想，比如會出現需求延期，研發評估不準，成員參與度不高等問題，需要團隊的多次磨合才能達到比較平衡的狀態，最終提升團隊的交付能力。

由于產品經理對結果負責，需要產品經理在每個階段都需要深度參與同時也需要推動引導團隊成員深度參與，解決每個階段遇到的問題，提升自己的領導力，帶領團隊準確交付。由于節奏比較快，隨時會遇到問題，需要產品經理始終站在用戶角度去思考問題，去尋找解決方案。

快速迭代的目的是快速交付，快速接觸用戶，比如對于一個3到5個月的目標，可能需要等幾個月才能上線，上線以后還會存在大量的問題，也可能偏離了用戶需求，但是通過敏捷迭代的方式，2周就能為用戶提供第一個版本，較早的觸達了用戶，后續迭代也都能收集用戶需求，相當于后續三個月的需求都是與用戶互動后產生的。同時這個機制也會倒逼產品研發團隊聚焦MVP能力與需求，不會浪費研發資源。大目標拆解成小目標去實現分階段驗證，大大提高了產品成功幾率。

目前存在一個問題就是整體迭代節奏比較快，持續推進會造成大家有一定的壓力，對組織來說是提高了人效，但是對成員來說一直處于緊湊的環境會降低大家的創新能力，也會產生一定的疲憊感。但是十分適合時間緊任務重的項目(比如為期3個月左右的沖刺項目)，大家在實施時可以根據自己團隊的實際情況進行調整。