最近兄弟部門部門做了比較大的調整。需要重新去定義產品，並做好產品的版本規划。從質量管理部OKR來分析，支持產品部門做好產品規划也是個優先任務。
（實際是以前沒有明確，達成約定的版本規划和版本號定義…）
一個好的產品規划，除了對自己的產品有充分清晰地思考之外，還要兼顧外界的技術趨勢、業界的動態、公司資源的考量。一定不能盲目地去加各種各樣的需求，或者毫無目的地去做版本迭代。每個版本的需求一定都是基於產品目前的現狀，市場的情況，最后基於產品發展的目的而去做的。
這是我總結的產品規划流程圖：
因為對具體的產品業務不清楚，所以在職能擅長的范疇內，我會在產品版本命名規則，環境分層兩方面給與產品部門具體的支持和建議。
軟件版本號的命名規范與原則
為了在軟件產品生命周期中更好的溝通和標記，很多公司對版本命名都有自己的一套規范，例如：
-
<名稱>_<主版本號>.<子版本號>_<SVN最后提交數>
-
<名稱>_<主版本號>.<子版本號>.<階段版本號>_<日期版本號加希臘字母版本號>
-
<名稱>_<主版本號>.<子版本號>_<日期版本號加希臘字母版本號>
我們應該對軟件的版本號命名的規范和原則有一定的了解。
1、APP、軟件的版本階段
Alpha版：也叫α版，此版本主要是以實現軟件功能為主，通常只在軟件開發者內部交流，一般而言，該版本軟件的Bug較多，需要繼續修改。
Beta版：此版本相對於α版已經有了很大的改進，消除了嚴重的錯誤，但還是存在着一些缺陷，需要經過多次測試來進一步消除，此版本主要的修改對像是軟件的UI。
RC版：此版本已經相當成熟了，基本上不存在導致錯誤的BUG，與即將發行的正式版相差無幾，測試人員基本通過的版本。
Release版：此版本意味着"最終版本"、"上線版本"，，在前面版本的一系列測試版之后，終歸會有一個正式版本，是最終交付用戶使用的一個版本。該版本有時也稱為標准版。一般情況下，Release不會以單詞形式出現在軟件封面上，取而代之的是符號(R)。
2、版本號的命名規范與原則
軟件版本號有四部分組成：<主版本號.><子版本號>.<階段版本號>.<日期版本號加希臘字母版本號>。希臘字母版本號共有5種：base、alpha、beta、RC、Release。 例如：1.0.0.180313_base
通常，完全的版本號定義，分三項： <主版本號.><子版本號>.<階段版本號>, 1.1.0
3、版本號修改規則
主版本號(1.x.x)：當功能模塊有較大的變動，比如增加多個模塊或者整體架構發生變化。此版本號由項目決定是否修改。
子版本號(x.1.x)：當功能有一定的增加或變化，比如增加了對權限控制、增加自定義視圖等功能。此版本號由項目決定是否修改。
階段版本號(x.x.1)：一般是 Bug 修復或是一些小的變動，要經常發布更新版，時間間隔不限，修復一個嚴重的bug即可發布一個修訂版。此版本號由項目經理決定是否修改。
日期版本號(x.x.x.180313)：用於記錄修改項目的當前日期，每天對項目的修改都需要更改日期版本號。此版本號由開發人員決定是否修改。
希臘字母版本號(x.x.x.x_beta):：此版本號用於標注當前版本的軟件處於哪個開發階段，當軟件進入到另一個階段時需要修改此版本號。此版本號由項目經理決定是否修改。
4、版本號的階段標識
按照軟件的研發過程，可以再將版本號進行相應的標注管理，但管理會變得過於復雜，視具體情況而定！
5、關於APP的版本管理
以Android為例， Android中有 versionCode 和 versionName，他們分別所代表的意思如下：
verisonCode:內部版本號，必須是整型。用來區分版本的新舊，版本號越大，代表距當前越近的發布版本。給開發者內部使用的。
versionName:向用戶展示的版本號，必須是字符串，這個版本號就是我們可以用來遵循規范的位置，可以作為版本比較的，判斷是否需要提示更新、是否需要強制更新的依據。
使用SCM進行代碼管理
公司使用的SCM系統是SVN， 以下結合SVN介紹怎樣進行代碼版本管理。
Subversion有一個很標准的目錄結構，是這樣的。比如項目是proj，svn地址為svn://proj/，那么標准的svn布局是
svn://proj/
|
+-trunk
+-branches
+-tags
SVN有兩種普遍的管理模式：
以Trunk做開發：
所有的開發都是基於trunk進行開發
時間區間(1)
-
(1)的起始時間是1.0.0開發的開始。
-
在(1)期間，沒有任何用戶使用1.0.0（還沒有發布），開發人員直接在Trunk1.0.0上開發。
-
(1)的結束時間是3.0開發的結束時間。結束時發布1.0.0產品，在SVN上創建1.0.0 Tag。這時Trunk1.0.0自動變成Trunk 1.0.1。
時間區間(2)
-
(2)的起始時間是1.0.1開發的開始。
-
如果在(2)期間，用戶報告1.0.0的Bug或者一些很急迫的功能要求，並且需要馬上修復實現。那么：
-
在Tag：1.0.0_release基礎上建立branches:1.0.0_bugfix，並且發布補丁包。
-
選擇性的把 dev_1.0.0_bugfix這個分支merge回trunk（什么時候進行這步操作，要根據具體情況）
-
-
(2)的結束時間是Turnk1.0.1開發的結束時間。結束時發布1.0.1產品。此時做以下事情：
-
將branches:1.0.0_bugfix的代碼合並到Trunk1.0.1上。並且發布鎖定Tag：1.0.1_release代碼避免任何進一步的修改。
-
這時Trunk1.0.1自動變成Trunk 1.0.2。
-
以分支做開發：
時間區間(1)
-
(1)的起始時間是1.0.0開發的開始。
-
在(1)期間，沒有任何用戶使用1.0.0（還沒有發布），開發人員直接在Trunk1.0.0上開發。
-
(1)的結束時間是3.0開發的結束時間。結束時發布1.0.0產品，在SVN上創建1.0.0 Tag，同時創建1.0.1 Branch。這時Trunk1.0.0自動變成Trunk 1.0.1。
時間區間(2)
-
(2)的起始時間是1.0.1開發的開始。
-
在(2)期間，因為有用戶使用1.0.0，所以1.0.1所有的開發工作在Branch1.0.1上進行。
-
如果在(2)期間，用戶報告1.0.0的Bug，並且需要馬上修復。那么：
-
在1.0.1 Trunk上對問題進行修復，並且發布補丁包。
-
將此改動合並到Branch1.0.1上。
-
-
(2)的結束時間是Branch1.0.1開發的結束時間。結束時發布1.0.1產品。此時做以下事情：
-
合並代碼之前，在1.0.1 Trunk上建立Tag，如：1.0.0_20180313。用來表示將1.0.1合並進來之前的代碼。
-
將Branch1.0.1的代碼合並到Trunk1.0.1上。並且鎖定Trunk1.0.1代碼避免任何進一步的修改。
-
從Trunk1.0.1上創建Branch 1.0.2，用於進行Branch 1.0.2的開發。
-
一些注意事項：
如果修復Bug，可以在Trunk或者Branch上做，但是一定要使用SubVersion的合並功能，而不是在Trunk和Branch上分別改兩遍。如果改兩遍，造成的結果是在要將Branch合並到Trunk上出現沖突。
如果有些核心數據結構的變動，將它放在小版本升級后的第一個迭代進行。避免對用戶造成升級困難，或者用戶需要重新裝載所有數據。
合並代碼的時候需要非常小心，保證Branch上的代碼和合並以后Trunk的代碼一樣非常關鍵。如果不一樣會造成這種情況：第一個從Branch上發布的產品沒有問題；后來為了修復一個Bug，從Trunk上發布一個新版本后，出現了第一個發布沒有出現的問題。
環境版本如何扭轉
項目因具體情況可能會出現多個測試環境進行維護的情況，這里以三套環境，N日為周期為例，該類情況可參考以下流程進行版本發布！
角色：開發，測試，開發負責人、版本負責人
環境：開發環境、測試環境、准生產環境
時間線 |
事務 |
T日 |
9點版本負責人創建版本 |
9-16點，開發人員開發功能，修改BUG（BUG解決關聯禪道版本） |
|
16-18點，開發負責人確認版本信息（開發功能，測試注意事項，SVN模塊最后version），提交版本負責人 |
|
版本負責統計項目各產品版本信息（開發功能，測試注意事項，SVN模塊最后version），驅動測試 |
|
T+N日 |
T+1日9點，測試人員更新測試環境 |
T+1日至T+N日15點，測試-測試版本（依據ＢＵＧ，功能，測試注意事項進行測試），提交ＢＵＧ（ＢＵＧ關聯禪道版本） |
|
T+N日15..30-17點，確認測試環境版本信息，提供項目經理（郵件描述版本更新內容及測試結果） |
|
項目經理確認版本測試結果，驅動准生產環境進行更新 |
|
T+N日17點-18點。冒煙准生產 |
|
T+N+1日 |
測試准生產 |
開發版本：
測試版本：
產品研發過程管理的方法和工具
使用Redmine進行研發管理，Redmine不僅可以用來做軟件研發過程管理，而且可以用來管理非軟件研發的項目。它給整個團隊一個總覽圖，同時記錄所有的細節。
