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

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

一、迭代周期

我們團(tuán)隊(duì)的迭代周期一般是2周，如果研發(fā)評(píng)估時(shí)間過(guò)長(zhǎng)的話也會(huì)將周期延長(zhǎng)至一個(gè)月，但是大多數(shù)我們是2周的迭代周期。

這里說(shuō)的2周是研發(fā)開(kāi)始coding、提測(cè)、測(cè)試、上線，也就是說(shuō)2周以后要上線相應(yīng)的能力。并不包括產(chǎn)品需求設(shè)計(jì)與評(píng)審的時(shí)間。

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

二、團(tuán)隊(duì)規(guī)模與職責(zé)

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

三、需求準(zhǔn)備階段

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

需求準(zhǔn)備時(shí)要想好本次迭代要解決用戶的哪些問(wèn)題或?yàn)橛脩魟?chuàng)造的價(jià)值，也可以稱為本次迭代的主題，是否是在整體roadmap的路線上。確認(rèn)本次的迭代方向后及時(shí)與團(tuán)隊(duì)成員進(jìn)行溝通與信息的同步，如有問(wèn)題需要及時(shí)調(diào)整迭代方向。

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

需求準(zhǔn)備階段要提前協(xié)調(diào)各方資源與信息的同步，看看各方對(duì)需求的看法與問(wèn)題，不要把問(wèn)題遺留到需求評(píng)審階段，提前做好相關(guān)準(zhǔn)備。

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

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

四、需求評(píng)審階段

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

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

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

需求評(píng)審?fù)瓿珊螽a(chǎn)品經(jīng)理將相關(guān)的產(chǎn)品資料同步至迭代看板中（內(nèi)部的項(xiàng)目管理工具），供技術(shù)負(fù)責(zé)人進(jìn)行整體排期。

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

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

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

一經(jīng)確認(rèn)排期時(shí)間需要各方準(zhǔn)確保證，因?yàn)樯婕岸喾絽f(xié)作，需要避免出現(xiàn)延期問(wèn)題。保證準(zhǔn)確交付。評(píng)估排期需要每個(gè)人都對(duì)自己的排期負(fù)責(zé)，需要保證排期的準(zhǔn)確性。

排期確認(rèn)后需求就進(jìn)入了研發(fā)階段，每個(gè)需求在研發(fā)階段都會(huì)確認(rèn)一個(gè)研發(fā)負(fù)責(zé)人，該負(fù)責(zé)人負(fù)責(zé)跟進(jìn)需求的進(jìn)度，解決需求開(kāi)發(fā)過(guò)程中遇到的技術(shù)問(wèn)題，保證需求能順利提測(cè)并上線。基本上每個(gè)研發(fā)都會(huì)負(fù)責(zé)一個(gè)需求，該措施能確保每個(gè)需求都有負(fù)責(zé)人進(jìn)行跟進(jìn)，保證需求在開(kāi)發(fā)過(guò)程中能直接找到對(duì)應(yīng)負(fù)責(zé)人，同時(shí)也鍛煉了負(fù)責(zé)人的橫向能力。

六、研發(fā)階段

研發(fā)階段團(tuán)隊(duì)成員每天通過(guò)早站會(huì)的方式同步每個(gè)需求的進(jìn)度，在會(huì)議之前需求的研發(fā)負(fù)責(zé)人都會(huì)在需求看板中更新當(dāng)前的研發(fā)進(jìn)度，問(wèn)題與風(fēng)險(xiǎn)，當(dāng)天的問(wèn)題原則上需要當(dāng)天解決，會(huì)議中大家也會(huì)對(duì)著需求看板同步進(jìn)展。

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

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

在此階段測(cè)試人員會(huì)準(zhǔn)備好測(cè)試用例，并在研發(fā)開(kāi)發(fā)完成前完成測(cè)試用例評(píng)審，研發(fā)自測(cè)也會(huì)依據(jù)測(cè)試用例完成自測(cè)走查

七、測(cè)試階段

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

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

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

此階段是產(chǎn)品上線前的最后階段，對(duì)測(cè)試人員的要求很高，需要進(jìn)行功能，視覺(jué)，交互等測(cè)試，也需要提出自己在測(cè)試中遇到的需求問(wèn)題。總之需要對(duì)測(cè)試結(jié)果與線上問(wèn)題負(fù)責(zé)。同時(shí)產(chǎn)品經(jīng)理在此階段也需要提前介入測(cè)試，如遇到問(wèn)題提前調(diào)整，避免遺留問(wèn)題。

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

八、上線與用戶反饋跟進(jìn)

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

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

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

九、小結(jié)

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

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

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

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

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