合理的項(xiàng)目迭代流程是軟件高質(zhì)量可持續(xù)生產(chǎn)的保障，只有擁有一套完整合理的項(xiàng)目迭代流程才能確保即使是不同團(tuán)隊(duì)開發(fā)不同項(xiàng)目，也能最大限度的保障項(xiàng)目開發(fā)質(zhì)量。
匯總流程圖如下，后面是各階段的詳細(xì)介紹：

圖片

1.需求評(píng)審階段：

需求評(píng)審是從理論上對(duì)項(xiàng)目可行性進(jìn)行評(píng)審，著重于需求的合理性、價(jià)值點(diǎn)、投入產(chǎn)出比分析，同時(shí)確保PD和開發(fā)方對(duì)于項(xiàng)目的相關(guān)信息認(rèn)知一致，以免產(chǎn)生不必要的資源損耗。
項(xiàng)目需求一般由產(chǎn)品經(jīng)理進(jìn)行提出，以PRD(需求文檔)的形式進(jìn)行呈現(xiàn)，需求文檔以清晰完整的描述整個(gè)項(xiàng)目需求為準(zhǔn)，具有一定的規(guī)范，通常應(yīng)包括需求背景、需求目標(biāo)、原型圖、動(dòng)線圖、需求概括、功能點(diǎn)、數(shù)據(jù)分析等內(nèi)容。
為提高需求評(píng)審質(zhì)量以及效率，評(píng)審會(huì)議建議按照以下流程進(jìn)行：

• 在評(píng)審會(huì)議開始前1天將相關(guān)會(huì)議文檔發(fā)送到各參會(huì)者，進(jìn)行提前閱讀留評(píng)
• 會(huì)議開始時(shí)首先快速的過一遍整體會(huì)議內(nèi)容，然后再針對(duì)留評(píng)內(nèi)容進(jìn)行重點(diǎn)討論
• 在評(píng)審過程中參會(huì)人提出的針對(duì)需求內(nèi)容無法在評(píng)審時(shí)解決的問題，或者待確認(rèn)的點(diǎn)需要記錄會(huì)議Action，會(huì)議Action一般情況下又可分為非阻塞型Action以及阻塞型Action，非阻塞型Action一般為參會(huì)人對(duì)于需求的建議、或者疑問，產(chǎn)品可選擇性聽取，阻塞型Action為參會(huì)人針對(duì)需求提出的產(chǎn)品在會(huì)后必須要確認(rèn)解決的問題，評(píng)審會(huì)議的通過最終以所有阻塞型Action都已解決為準(zhǔn)。

區(qū)分阻塞型Action以及非阻塞型Action的原因如下：

根據(jù)以往需求評(píng)審的會(huì)議經(jīng)驗(yàn)，在會(huì)議時(shí)參會(huì)者往往會(huì)提出很多關(guān)于需求方面的建議、疑問，產(chǎn)品往往在會(huì)后會(huì)優(yōu)先確認(rèn)解決那些自己認(rèn)為比較重要的問題，這樣就在參會(huì)者以及產(chǎn)品經(jīng)理之間出現(xiàn)了信息差，導(dǎo)致會(huì)后對(duì)于需求而言重要的問題沒有解決就進(jìn)入開發(fā)階段或者是將大量的精力用在不重要的問題上造成資源浪費(fèi)。

1.1需求初評(píng)：

產(chǎn)品經(jīng)理產(chǎn)出需求文檔后，產(chǎn)品團(tuán)隊(duì)內(nèi)部成員對(duì)需求進(jìn)行的評(píng)審稱之為需求初評(píng)，需求初評(píng)可以很大程度上提前識(shí)別那些價(jià)值不夠高的需求，以免進(jìn)入后續(xù)的流程，提高迭代效率，主要著重于評(píng)審需求的價(jià)值點(diǎn)以及合理性，評(píng)審會(huì)議應(yīng)按照規(guī)定根據(jù)上面的評(píng)審會(huì)議流程進(jìn)行，當(dāng)所有阻塞型Action解決后方可進(jìn)入下一流程。

1.2正式評(píng)審：

正式評(píng)審是產(chǎn)品、交互、開發(fā)、測試核心針對(duì)需求實(shí)現(xiàn)難度以及性價(jià)比進(jìn)行的評(píng)審，當(dāng)然開發(fā)人員根據(jù)以往上線功能的數(shù)據(jù)，認(rèn)為本次需求價(jià)值、合理性存在問題的地方也可以提出建議或疑問作為阻塞型Action，阻塞需求評(píng)審不予通過。
這里說一點(diǎn)自己的看法，現(xiàn)在軟件開發(fā)推崇的敏捷迭代一個(gè)開發(fā)周期只有2-3周的時(shí)間，特點(diǎn)是迭代周期短需求數(shù)量多，很多沒有進(jìn)行長期規(guī)劃的項(xiàng)目上線后往往會(huì)造成效果不理想或者破壞整個(gè)產(chǎn)品完整性的情況，所以一定要投入更多的精力在需求評(píng)審中，對(duì)于開發(fā)人員而言切記并不是所有評(píng)審的需求都需要投入開發(fā)，要結(jié)合實(shí)際情況進(jìn)行判斷。

1.3交互評(píng)審：

針對(duì)交互稿進(jìn)行評(píng)審，評(píng)審時(shí)核心關(guān)注交互實(shí)現(xiàn)的難易度、完整性、性價(jià)比，To B需求應(yīng)優(yōu)先以現(xiàn)有的組件庫進(jìn)行交互設(shè)計(jì)，提高開發(fā)效率。

2.項(xiàng)目開發(fā)階段：

項(xiàng)目評(píng)審階段結(jié)束時(shí)應(yīng)確保以下兩件事都已完成：

• 項(xiàng)目需求文檔、交互文檔關(guān)于項(xiàng)目所需開發(fā)功能點(diǎn)描述都已清晰完整，邊界情況都有涉及
• 項(xiàng)目所有待開發(fā)功能點(diǎn)相關(guān)信息等產(chǎn)品和開發(fā)都已達(dá)成一致
• 與開發(fā)內(nèi)容所依賴的二方業(yè)務(wù)資源都已就位，不會(huì)在開發(fā)過程中因其他資源問題導(dǎo)致項(xiàng)目延期等問題

2.1確定排期

在項(xiàng)目需求都已清晰完整后接下來就進(jìn)入了排期階段，各端開發(fā)需要根據(jù)需求文檔進(jìn)行人日預(yù)估，確定設(shè)計(jì)時(shí)間、開發(fā)時(shí)間、聯(lián)調(diào)時(shí)間、bugfix時(shí)間、提測時(shí)間，之后項(xiàng)目PM再根據(jù)各端預(yù)估人日和資源排期情況，確定項(xiàng)目用例評(píng)審時(shí)間點(diǎn)、冒煙時(shí)間點(diǎn)、驗(yàn)收時(shí)間點(diǎn)、發(fā)布時(shí)間點(diǎn)、放量節(jié)奏等來完成項(xiàng)目最終的Roadmap，接下來就是各端開發(fā)根據(jù)項(xiàng)目Roadmap進(jìn)行開發(fā)了。

2.2設(shè)計(jì)評(píng)審

對(duì)于耗費(fèi)人日較多的項(xiàng)目一定要遵循設(shè)計(jì)先行原則，先有完整的設(shè)計(jì)文檔然后再投入開發(fā)寫代碼。根據(jù)以往的經(jīng)驗(yàn)開發(fā)前先完成方案設(shè)計(jì)可以很大程度上避免開發(fā)過程中的返工、線上故障、代碼質(zhì)量不高的問題，提高開發(fā)效率，減少資源浪費(fèi)，尤其對(duì)新同學(xué)很有幫助，同時(shí)項(xiàng)目設(shè)計(jì)文檔也可作為公司資源的一部分沉淀下來，為后續(xù)開發(fā)人員接手項(xiàng)目提供幫助。
設(shè)計(jì)評(píng)審一般由服務(wù)端進(jìn)行發(fā)起評(píng)審人員包括各端開發(fā)，核心確認(rèn)項(xiàng)目實(shí)現(xiàn)方案完整合理，以及將各端需要對(duì)接的資源進(jìn)行同步，這其中比較重要的就是項(xiàng)目接口評(píng)審，好的接口設(shè)計(jì)應(yīng)遵循一定的規(guī)范，比如大小寫命名方式、是否具有語義化。
補(bǔ)充一點(diǎn)就是對(duì)于各端開發(fā)來說，如果遇見耗時(shí)較久或者開發(fā)較復(fù)雜的項(xiàng)目建議也最好先提前做好要開發(fā)內(nèi)容的設(shè)計(jì)，這樣對(duì)最終的代碼可維護(hù)性很有幫助。

2.3用例評(píng)審

在正式投入開發(fā)的2-3天后，測試應(yīng)根據(jù)本次迭代所要開發(fā)內(nèi)容完成用例文檔并向開發(fā)提供，最終項(xiàng)目開發(fā)完成所有交付功能以滿足用例文檔所有用例為準(zhǔn)。

3.項(xiàng)目測試階段：

3.1冒煙預(yù)演

在項(xiàng)目所有功能開發(fā)完成后，開發(fā)應(yīng)根據(jù)用例文檔對(duì)項(xiàng)目所有功能進(jìn)行預(yù)演，當(dāng)所有用例通過后交付給測試進(jìn)行其他內(nèi)容回歸、邊界測試等內(nèi)容，此時(shí)便進(jìn)入提測階段。

3.2項(xiàng)目驗(yàn)收

當(dāng)項(xiàng)目測試完成后便來到了最終的上線驗(yàn)收階段，該過程是最后一次對(duì)項(xiàng)目所有功能點(diǎn)進(jìn)行check，除此之外還需要確認(rèn)清楚各相關(guān)應(yīng)用的發(fā)布順序、發(fā)布流程、回滾方案、灰度節(jié)奏，發(fā)布順序的確認(rèn)可以有效避免因應(yīng)用發(fā)布順序有誤導(dǎo)致項(xiàng)目出現(xiàn)故障。

4.項(xiàng)目上線階段：

4.1數(shù)據(jù)觀察

在項(xiàng)目上線后開發(fā)人員應(yīng)及時(shí)根據(jù)項(xiàng)目當(dāng)中的相關(guān)數(shù)據(jù)埋點(diǎn)對(duì)項(xiàng)目功能的使用情況進(jìn)行統(tǒng)計(jì)分析，該數(shù)據(jù)將對(duì)后續(xù)該產(chǎn)品迭代的相關(guān)決策提供幫助。

4.2項(xiàng)目迭代Reivew

以月為周期，在月底的時(shí)候我們一般會(huì)針對(duì)這一個(gè)月內(nèi)的相關(guān)項(xiàng)目開發(fā)情況進(jìn)行項(xiàng)目迭代Reivew會(huì)議，希望通過Review會(huì)議找出在這一個(gè)月的項(xiàng)目開發(fā)過程中，項(xiàng)目開發(fā)流程本身是否存在改進(jìn)的地方，項(xiàng)目迭代流程是否存在執(zhí)行不到位的情況，從而對(duì)項(xiàng)目迭代流程不斷地進(jìn)行優(yōu)化，提高產(chǎn)研效率，同時(shí)對(duì)在開發(fā)中做的比較好的點(diǎn)進(jìn)行倡導(dǎo)鼓勵(lì)。

最后

剛開始工作時(shí)個(gè)人也對(duì)項(xiàng)目迭代流程產(chǎn)生過困惑，為什么一定要有這么復(fù)雜的流程，是不是有些過于形式主義了？但后來理解從大的方向上講公司任何流程相關(guān)的東西本質(zhì)上都是為了生產(chǎn)可以規(guī)范標(biāo)準(zhǔn)化的進(jìn)行，核心是可持續(xù)生產(chǎn)價(jià)值，從實(shí)際出發(fā)在經(jīng)歷一年多的項(xiàng)目開發(fā)后也深刻的明白了上面所講的每一步都是為了保障項(xiàng)目迭代開發(fā)可以安全、高效的進(jìn)行，每一步都具有存在的意義：比如設(shè)計(jì)評(píng)審就是因?yàn)樵谖覀兊拇a中經(jīng)常出現(xiàn)因沒有提前的設(shè)計(jì)導(dǎo)致代碼的維護(hù)性、健壯性出現(xiàn)問題，從而導(dǎo)致更多的bug，嚴(yán)格進(jìn)行用例評(píng)審的原因是往往會(huì)出現(xiàn)在進(jìn)行提測時(shí)開發(fā)所開發(fā)的功能與最終PD所設(shè)想的內(nèi)容不符，后來就增加了這一環(huán)節(jié)，比如我們也曾因發(fā)布順序未進(jìn)行約定好而導(dǎo)致線上故障，后來就在項(xiàng)目驗(yàn)收時(shí)增加了這一流程。