国外亚洲成av人片在线观看,热99re久久精品这里都是精品,天堂网在线最新版www,国产成人av区一区二区三,51久久成人国产精品麻豆

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

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

一、迭代周期

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

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

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

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

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

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

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

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

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

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

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

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

四、需求評審階段

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

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

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

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

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

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

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

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

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

六、研發(fā)階段

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

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

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

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

七、測試階段

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

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

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

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

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

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

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

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

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

九、小結(jié)

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

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

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

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

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