5000字干貨原創(chuàng) | APP版本迭代如何避免踩坑？

??

這是我之前好友總結整理的APP版本迭代流程與規(guī)范，主要涉及到版本迭代過程中的規(guī)范流程以及涉及到版本各個角色的職責分工等內容。

為了避免和團隊成員撕逼扯皮，可以按照如下規(guī)范流程和團隊成員宣導，落實每個環(huán)節(jié)各個角色的職責和內容，保證每個環(huán)節(jié)都能高效協(xié)作，避免踩到坑里，相關干貨流程分享給大家。

本文目錄如下：

一、引言

二、需求匯總階段流程

三、需求評審階段流程

四、需求開發(fā)&測試階段流程

五、內測階段流程

六、APP版本號命名規(guī)則

1、引言

1.1、目的

基于現(xiàn)在的開發(fā)流程中缺少的環(huán)節(jié)進行補足，使得開發(fā)流程更加的流暢和正規(guī)化，以便以后的查閱與歸檔使用。面對互聯(lián)網行業(yè)中激烈的競爭，讓我們的開發(fā)流程更完整、更有效率，產品才能脫穎而出。

1.2、范圍

本文檔適用于App產品的迭代研發(fā)，主要流程包括：需求匯總、需求評審、技術&用例評審、開發(fā)&測試排期、開發(fā)&測試、內測體驗等環(huán)節(jié)。以后的產品開發(fā)流程也可以參考此文檔的環(huán)節(jié)進行開發(fā)。

1.3 、讀者對象

本文檔的目標讀者對象主要包括：

產品經理：輸出&收集匯總每個版本迭代的需求，同時對App迭代進行體驗驗收，需求匯總階段、需求評審階段、內測體驗階段的主要負責人。

交互設計師：根據(jù)相關需求文檔，進行交互優(yōu)化，輸出優(yōu)化原型圖，提升產品整體用戶體驗。

視覺設計師：根據(jù)需求文檔&交互原型圖作為視覺設計的步驟和資源產出的依據(jù)。

項目經理：組織發(fā)起需求評審，并跟進評審結果及輸出開發(fā)測試排期，需求評審階段、發(fā)布上線階段的主要負責人。

開發(fā)：主導發(fā)起部分復雜需求的技術評審，根據(jù)需求文檔編寫代碼，開發(fā)測試過程由版本經理主導推進，為迭代上線負責。

測試：根據(jù)需求文檔設計相關測試用例，并主導發(fā)起用例評審，跟進測試階段的Bug解決。

1.4、App迭代階段流程圖

（點擊查看大圖）

2、需求匯總階段

（點擊查看大圖）

階段推進方：主要由產品主導推進與收尾

產品部門&版本主要產品經理：

• – 負責發(fā)起版本迭代

• – 輸出相關App迭代需求

• – 收集其他需求方的App迭代需求

• – 匯總并進行需求的初步分類與優(yōu)先級評定

• – 決策相關需求方案是否需要技術介入進行前期初評

• – 決策相關需求方案是否需要進行交互優(yōu)化&視覺設計

• – 郵件發(fā)送需求匯總清單至相關責任人

• – 確認需求匯總完畢后發(fā)起需求評審

• – 匯總、整理、輸出本階段相關交付結果

階段參與方&職責：

交互設計師

• – 根據(jù)需求文檔及需求原型圖，進行交互層面優(yōu)化，提升產品的用戶體驗

• – 自發(fā)發(fā)起用戶體驗提升相關的需求，并提交給產品經理匯總入版本迭代需求中

• – 輸出交互優(yōu)化稿后與產品經理進行評審確認

視覺設計師

• – 根據(jù)需求文檔及需求原型圖或交互原型圖，進行視覺設計

• – 輸出效果稿進行視覺設計評審確認

• – 輸出標注稿供客戶端開發(fā)工程師對照開發(fā)

• – 輸出相關測試用效果切圖，供開發(fā)&測試過程直觀查看效果用

項目經理

• – 根據(jù)開發(fā)對需求提出的疑問點進行分類匯總

• – 組織安排評審會議

開發(fā)

• – 適時參與產品發(fā)起的需求方案初評

• – 查閱產品擬定的本版本迭代需求匯總，并初步提出相關疑問點

測試

• – 查閱產品擬定的本版本迭代需求匯總，并初步提出相關疑問點

階段工作描述

需求匯總階段也是版本迭代的準備階段，該階段主要為需求的匯總及UED方面的設計輸出，同時也為需求評審準備相應的材料與文檔。

階段交付成果

• 版本迭代需求匯總

• 產品需求文檔

• UE交互優(yōu)化稿

• UI視覺設計稿&標注稿

• 需求初期疑問點匯總

3、需求評審階段

3.1、需求評審

（點擊查看大圖）

階段推進方：主要由產品主導推進與收尾

• – 負責發(fā)起版本迭代需求評審

• – 配合項目經理組織需求評審會議

• – 在需求評審會議中進行需求宣講講解

• – 針對匯總后的需求疑問點進行答疑與溝通

• – 需求的責任人需進行需求討論記錄并在會議的最后進行需求討論記錄的確認

階段參與方&職責如下

項目經理

• – 組織安排評審會議，召集相關人員

• – 匯總并與相關方確認最終的需求范圍

開發(fā)

• – 會前確認主流程、主方向、主內容的認可

• – 非常細節(jié)的內容，不涉及主流程環(huán)節(jié)可會后單獨與產品經理討論確認

• – 參與需求評審，并根據(jù)需求講解情況，提出疑問點，進行討論確認

• – 確認最終的需求范圍及需求內容

測試

• – 會前確認主流程、主方向、主內容的認可

• – 非常細節(jié)的內容，不涉及主流程環(huán)節(jié)可會后單獨與產品經理討論確認

• – 參與需求評審，并根據(jù)需求講解情況，提出疑問點，進行討論確認

• – 確認最終的需求范圍及需求內容

階段工作描述

需求評審階段是版本迭代的關鍵節(jié)點，該階段主要需要對需求進行嚴格的審閱與傳達，需要需求方與實現(xiàn)方進行完整全面的溝通。同時也是后續(xù)技術設計評審、測試用例評審的根基，力求將問題放在初期解決確認。

階段交付成果

• 各個需求的需求討論點記錄

• 需求評審總結與會議紀要

• 需求范圍確認后的版本迭代需求匯總清單

3.2、技術/測試用例評審&排期

（點擊查看大圖）

階段推進方：主要由項目經理主導推進與收尾

• – 負責在確認需求范圍后，發(fā)起開展技術設計評審、測試用例評審

• – 負責確認版本經理、測試負責人

• – 負責收集各個需求的開發(fā)/測試工作量評估

• – 負責輸出版本迭代排期，并與各方最終確認排期情況

階段參與方&職責如下：

產品經理

• – 參與技術設計/測試用例的評審，并提出疑問并溝通確認

• – 確認技術設計/測試用例是否符合需求

• – 確認開發(fā)/測試的排期情況

開發(fā)

• – 確認版本經理

• – 由版本經理評估相關需求是否需要進行技術設計評審并發(fā)起推進

• – 根據(jù)確認的技術設計方案or需求，進行開發(fā)工作量評估

• – 參與測試用例評審并確認一級用例范圍

• – 確認轉測條件

測試

• – 確認測試負責人

• – 輸出相關測試用例并分級，發(fā)起測試用例評審并推進

• – 參與技術設計方案評審

• – 根據(jù)確認的測試用例，進行測試工作量評估

• – 確認轉測條件

階段工作描述

技術設計方案評審&測試用例評審及排期是版本迭代的重要節(jié)點，此階段延續(xù)需求評審后對需求的理解，從開發(fā)/測試的角度出發(fā)，制定相關方案，為后續(xù)開發(fā)/測試工作提供指導與依據(jù)。

階段交付成果

• 技術設計概要

• 技術設計概要評審會議紀要

• 測試用例

• 測試用例評審會議紀要 

• 版本迭代開發(fā)&測試排期表

4、開發(fā)&測試階段

（點擊查看大圖）

階段推進方：主要由版本經理主導推進與收尾

• – 對整體開發(fā)&測試過程主導推進并負責

• – 及時同步進度并進行風險預警

• – 推進開發(fā)并同時跟進開發(fā)進度

• – 推進轉測并同時跟進測試進度

階段參與方&職責如下：

產品經理

• – 參與進度同步，及時根據(jù)風險預警進行調整

• – 參與代碼開發(fā)階段的討論，確認細節(jié)點

• – 參與測試階段的討論，確認細節(jié)點

• – 決策是否需要在開發(fā)過程中進行需求變更

視覺設計

• – 在測試階段介入進行視覺還原

• – 跟進視覺還原的修復進度

• – 確認開發(fā)過程中的部分對視覺的問題點

開發(fā)

• – Coding

• – 參與轉測演示，并對轉測演示結果負責

• – 在測試階段及時清理相關Bug與問題

• – 與產品積極溝通相關細節(jié)點

測試

• – 根據(jù)轉測演示結果，決策是否轉測成功

• – 發(fā)起測試階段，并根據(jù)測試用例進行數(shù)輪測試

• – 跟進提出的Bug的解決進度

• – 與產品積極溝通相關細節(jié)點

階段工作描述

開發(fā)&測試階段是版本迭代的實現(xiàn)階段，本過程持續(xù)時間長，且過程需要大量持續(xù)的溝通與工作，需要各方進行緊密的配合。

階段交付成果

• 相關接口協(xié)議文檔

• 測試版本App 

• 版本迭代節(jié)點通知 

• 日常進度信息

• 測試驗收報告

5、內測體驗階段

（點擊查看大圖）

階段推進方：主要由產品主導推進與收尾

• – 推動App迭代內測正常進行，組建內測群，拉內測員

• – 整理版本主要更新點并發(fā)布內測邀請

• – 收集匯總內測員的問題反饋并記錄相關反饋人

• – 反饋問題的定性與分類，確認是需求orBug，同時進行后續(xù)分配與確認

• – 判定需求是否采納，采納則納入需求池，酌情安排迭代，不采納則將原因描述反饋歸檔

• – 歸檔全部的問題及問題認定后，進行問題反饋分級

• – 根據(jù)問題反饋分級，對反饋內測員發(fā)送對應獎勵

階段參與方&職責如下：

測試

• – 確認預發(fā)布驗證通過，準備內測包并發(fā)起內測流程

• – 配合產品一起完成對反饋的問題的定性分類分級

• – 對分類為Bug的問題反饋，進行確認與復現(xiàn)，同時確認Bug的優(yōu)先級

• – 高優(yōu)先級Bug，當前版本需解決，錄入系統(tǒng)跟進本版本內解決

• – 低優(yōu)先級Bug，可延后解決，錄入系統(tǒng)Bug池延后版本解決

開發(fā)

• – 確認需發(fā)布內容的Checklist

• – 對后臺進行逐一發(fā)布

• – 內測包的打包與準備

內測員

• – 內測員一般由內部員工或灰度員工參與

• – 下載并安裝內測包，進行體驗

• – 重點體驗本版本的更新點相關流程

• – 輕度體驗App的常規(guī)常用流程

• – 發(fā)現(xiàn)問題并在內測群內反饋問題，配合產品完成問題的確定與歸集

項目經理

• – 跟進版本迭代的生產環(huán)境發(fā)布

• – 推動最終對外上線發(fā)布

階段工作描述

內測階段是上線前最后一個階段，在這個階段需要從常規(guī)用戶的角度來最終體驗，以防存在有未覆蓋的點存在問題。

階段交付成果

• 生產環(huán)境App

• 內測體驗報告

六、APP版本號命名規(guī)則

作為移動端產品經理，經常會做APP版本迭代規(guī)劃，所以不可避免的需要給APP版本確定版號的工作，大多數(shù)情況下可能都是拍腦袋確定的版本號。有些公司可能會有專門的項目經理負責版本管理和版本號的命名，但是絕大多數(shù)小公司可能都是產品經理來做這項工作。

6.1、為什么要規(guī)范APP版本號的命名？

首先需要說明的是哪些人員需要用到APP版本號，第一是產品經理，第二是開發(fā)人員，第三是項目經理，第四是用戶。

對于產品經理，APP版本迭代基本都是由產品經理發(fā)起的，因此很多情況下都是產品經理在進行需求管理和版本規(guī)劃的時候就大體上劃分了版本號，版本號對于產品經理來說可以更好更清晰的篩選和確定每個版本的需求；

對于開發(fā)人員，版本號是直接和代碼相關的，很多時候不同版本交叉開發(fā)，同一時間可能在開發(fā)不同版本，為了保障代碼的規(guī)范和清晰，避免不同版本出現(xiàn)交叉混亂，版本號是極其重要的一環(huán)；

對于項目經理來說，版本號是需求管理中唯一標識符，需要根據(jù)版本號去管理和分配下發(fā)工作，同時也為了在軟件產品生命周期中更好的溝通和標記；

對于用戶來說，盡管版本號對于用戶來說只是一串數(shù)字，但是版本號給用戶的感知是不斷更新的數(shù)字，可以通過版本號來判斷自己的APP是不是最新的。

6.2、APP版本號的組成與規(guī)范

目前很多情況下，版本號可能只遵循了兩個原則和規(guī)范，即版本號是唯一的，且是一串數(shù)字這個基本原則。在介紹APP版本號的命名規(guī)范和原則之前，我們首先需要了解一些APP版本號的組成是怎樣的。

軟件版本號有四部分組成：

<主版本號.><子版本號>.<階段版本號>.<日期版本號加希臘字母版本號>。希臘字母版本號共有5種：base、alpha、beta、RC、Release。例如：2.1.0.181209_Release。下面對希臘字母版號進行簡述：

Alpha版：也叫α版（開發(fā)環(huán)境），此版本主要是以實現(xiàn)軟件功能為主，通常只在軟件開發(fā)者內部交流

Beta版：此版本相對于α版已經有了很大的改進，消除了嚴重的錯誤，但還是存在著一些缺陷，需要經過多次測試來進一步消除，此版本主要的修改對像是軟件的UI。

RC版：此版本已經相當成熟了，基本上不存在導致錯誤的BUG，與即將發(fā)行的正式版相差無幾，測試人員基本通過的版本。

Release版：此版本意味著“最終版本”、“上線版本”，，在前面版本的一系列測試版之后，終歸會有一個正式版本，是最終交付用戶使用的一個版本。該版本有時也稱為標準版。一般情況下，Release不會以單詞形式出現(xiàn)在軟件封面上，取而代之的是符號(R)。

而對于絕大多數(shù)APP來說，一般采用的基本都是GNU風格的版本號管理策略，APP完全版本號的組成包括三組數(shù)字<主版本號.><子版本號>.<階段版本號>，也即X.Y.Z，其中X、Y、Z都為正整數(shù)。

6.3、APP版本號的命名修改規(guī)則

1、主版本號

• 當App的多個主要模塊有較大的變動，一般情況下比方說APP新增一個TAB，整個產品結構都改變了，或者新增了新的功能或業(yè)務。比方說微信上線錢包，抖音上線直播

• 主版本號起始值為0或者1，具體需要由產品經理來決定是否需要修改主版本號（PS：大多數(shù)可能需要老板拍板）

2、子版本號

• 子版本號初始值為0

• 當APP的較少主要模塊發(fā)生較大的變動或新增模塊（涉及主邏輯變更的）、較多個分支模塊發(fā)生較大的變動或新增，相對于主版本號而言僅是局部的變動，比方說某個功能上的UI重構，某個頁面的優(yōu)化等，其中較少模塊和較多模塊需要去定義，一般我們認為較少為小于3個，較多認為是超過3個；

• 子版本號的最大值需要確定，不同的公司可能有最大的值，比方說最大為9，如果超過9，則需要主版本號進1，也有些公司可能不存在最大值，只會在主版本號+1的情況下才會將子版本號歸0。這里沒有確定的原則和規(guī)范，可以由產品經理自己定規(guī)則

3、階段版本號

• 階段版本號初始值為0

• 什么時候修改階段版本號，一般是Bug修復、較少個分支模塊的變動，比方說視覺、樣式、交互、文案等修改的情況。

• 一般情況下，如果只是修復bug，則階段版本號+1即可；如果既涉及到bug修復，又涉及到較少分支模塊的修改，則階段版號+2；如果超過3個分支模塊的修改，則建議直接子版本號+1。

盡管說版本號只是一串數(shù)字，但是對于產品經理、開發(fā)人員以及用戶來說，都是有意義的一串數(shù)字，既能規(guī)范版本的生命周期，也能方便內部人員的溝通和工作，拍腦袋的去命名版本號是一個不嚴謹和規(guī)范的，而產品經理是需要去追求完美的，希望以上的APP版本的命名規(guī)范能夠給大家一些參考。

以上，就是APP版本迭代涉及到的各階段流程整理，以及各個階級涉及到的各角色的職責以及每個階段需要輸出什么交付物，每個公司每個產品涉及到的流程可能都會不一樣，但是大體上來說應該有會包含上述環(huán)節(jié)，大家可以根據(jù)自己的實際情況進行調整。

?

?