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

圖片

1.需求評審階段：

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

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

區分阻塞型Action以及非阻塞型Action的原因如下：

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

1.1需求初評：

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

1.2正式評審：

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

1.3交互評審：

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

2.項目開發階段：

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

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

2.1確定排期

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

2.2設計評審

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

2.3用例評審

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

3.項目測試階段：

3.1冒煙預演

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

3.2項目驗收

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

4.項目上線階段：

4.1數據觀察

在項目上線后開發人員應及時根據項目當中的相關數據埋點對項目功能的使用情況進行統計分析，該數據將對后續該產品迭代的相關決策提供幫助。

4.2項目迭代Reivew

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

最后

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