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

圖片

1.需求評審階段：

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

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

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

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

1.1需求初評：

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

1.2正式評審：

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

1.3交互評審：

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

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

項目評審階段結束時應確保以下兩件事都已完成：

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

2.1確定排期

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

2.2設計評審

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

2.3用例評審

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

3.項目測試階段：

3.1冒煙預演

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

3.2項目驗收

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

4.項目上線階段：

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

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

4.2項目迭代Reivew

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

最后

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