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

互聯(lián)網(wǎng)產(chǎn)研團隊一般都是按照敏捷開發(fā)的流程進行協(xié)作的，我在互聯(lián)網(wǎng)大廠的敏捷開發(fā)是怎么進行的呢。

一、迭代周期

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

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

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

二、團隊規(guī)模與職責

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

三、需求準備階段

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

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

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

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

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

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

四、需求評審階段

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

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

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

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

五、研發(fā)評估排期階段

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

研發(fā)評估排期后需要與測試、產(chǎn)品經(jīng)理確認提測時間與上線時間。測試會依據(jù)研發(fā)時間評估測試所需時間，出現(xiàn)整體排期問題時，產(chǎn)品經(jīng)理需要協(xié)調(diào)各方資源與時間保證本次迭代的落地。

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

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

六、研發(fā)階段

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

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

研發(fā)階段開始時產(chǎn)品經(jīng)理就需要開始準備下個迭代的需求，以保證下個迭代能順利開始。

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

七、測試階段

開發(fā)完一個需求后，產(chǎn)品經(jīng)理會進行功能驗證并發(fā)起提測單，產(chǎn)品驗證后提測能保證是按需求開發(fā)的，提高測試人員的效率。

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

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

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

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

八、上線與用戶反饋跟進

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

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

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

九、小結

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

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

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

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

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