摘要: 版本管理是項目管理知識條線繞不過去的挑戰。這裏根據實際需要，整理一些筆記，請大家指正。理論指導實踐，實踐不一定要拘泥於理論。你不照着做，SVN也工作正常，只是照着做後實踐出真知，更有體現工作的意義。
從版本管理看項目管理入手
[TOC]
概要
版本管理是項目管理知識條線繞不過去的挑戰。這裏根據實際需要，整理一些筆記，請大家指正。理論指導實踐，實踐不一定要拘泥於理論。你不照着做，SVN也工作正常，只是照着做後實踐出真知，更有體現工作的意義。
成熟的管理方案
-
SVN 版本管理規範
-
Git Flow
版本管理相關知識科普
名詞不計其數，先認識下，看看能不能混個臉熟，下次碰到就不會陌生了：
項目計劃、檢查點、里程碑、基線、路線圖、藍圖、版本、需求分析、原型、數據庫設計、評審、項目章程、組織結構、崗位職責說明書、干係人
如果沒時間，看這個圖就足夠了
路線圖-RoadMap :藍圖：發展方向、目標、概要、階段、步驟 |__檢查點-Checkpoint :周例會是檢查點的表現形式 |__里程碑-Milestone :重要的檢查點是里程碑 |__基線-Baseline :重要的需要客戶確認的里程碑，就是基線;高層的階段彙報會是基線的表現形式; |__版本-Version :在軟件開發中，路線圖就表現爲一個個的版本迭代；每個版本描繪好feature； |__開發庫-Trunk :最穩定的前提下，保持最新。主幹庫； |__受控庫-Branches :可以是以組爲單位建分支；也可以是針對某個投產版本修復bug；測試通過後合併到主分支； |__產品庫-Tags :正式投產的版本，不可更改。
RoadMap爲啥重要
一個項目拿到手中，首先要解決的是RoadMap，翻譯成路線圖或者藍圖。主要是對項目的生命週期做一個規劃，比如8個月工期的項目，採用迭代的方式開發，迭代多少版本合適，每個版本實現什麼功能，新功能增加，舊功能迭代等。
簡潔地說，RoadMap就是項目整體的規劃圖，產品的每一代都有什麼功能都可以從中縱覽全局。見着明瞭。有共同的目標纔有努力的方向。
檢查點(CheckPoint)
檢查點是定期的抽檢，一般以周爲單位，體現在周例會和週報中。
包括但不限於：需求評審、原型評審、數據庫設計評審、開發計劃評審、
開發跟進、CodeReview、單元測試、集成測試、UAT測試、發佈打版等
里程碑(Milestone)
階段性產生重要交付物，需要組長確認的檢查點兒，就可以是里程碑；不同的項目粒度劃分不一樣。
完成階段性工作的標誌，不同類型的項目里程碑不同。里程碑在項目管理中具有重要意義，我們用一個例子說明：
情況一：你讓一個程序員一週內編寫一個模塊，前 3 天你們可能都挺悠閒，可後 2 天就得拼命加班編程序了，而到週末時 又發現系統有錯誤和遺漏，必須修改和返工，於是週末又得加班了。
情況二：實際上你有另一種選擇，即週一與程序員一起列出所有需求，並請業務人員評審，這時就可能發現遺漏並即 時修改;週二要求程序員完成模塊設計並由你確認，如果沒有大問題，週三、週四就可讓程序員編程。同時自己準備 測試案例，週五完成測試;一般經過需求、設計確認，如果程序員合格則不會有太大問題，週末可以休息了。 第二種方式增加了 “ 需求 ” 和 “ 設計 ” 兩個里程碑，這看似增加了額外工作，但其實有很大意義：首先，對一些複雜的項 目，需要逐步逼近目標，里程碑產出的中間 “ 交付物 ” 是每一步逼近的結果，也是控制的對象。如果沒有里程碑，中間 想知道 “ 他們做的怎麼樣了 ” 是很困難的。其次，可以降低項目風險。通過早期評審可以提前發現需求和設計中的問 題，降低後期修改和返工的可能性。另外，還可根據每個階段產出結果分期確認收入，避免血本無歸。第三，一般人 在工作時都有 “ 前鬆後緊 ” 的習慣，而里程碑強制規定在某段時間做什麼，從而合理分配工作，細化管理 “ 粒度 ” 。
版本
落地到軟件開發中來說，RoadMap由一個一個版本迭代而成。
基線
通過評審的需求、原型、設計、測試案例最終形成一個release版本，就可以是一個基線。
重要的里程碑，需要客戶正式評審確認的就可以是基線。
主幹(trunk)、標籤(tags)與分支(branches)
目的：多個版本中並行開發，提高開發效率；保證各個版本和各個環境（開發、測試、主幹）的獨立，避免相互影響；通過分支與主幹的合併，這樣主幹永遠是最新、最高版本，並且都在後面的測試中，保證了質量；用分支進行bug修改，而主幹上進行新功能的開發。分支上的bug修改完合併到主幹上；分支是給源項目創建副本，讓每個工作組在各自的副本上進行開發，最後再將各個工作組的副本合併到源項目中。在此，各個副本被稱作分支（branches），源項目被稱爲主幹（trunk）；branches測試完成後，修復完bug，通過branches生成tags。
開發庫(Trunk)是開發人員修改代碼的地方。（開發人員可以隨意修改）
受控庫(Branch)是測試版本代碼存放的地方。（需要開發組長提交測試申請修改）
產品庫(Tags)是測試通過版本存放的地方。（需要測試報告來驅動修改）
SVN通過對三個文件的操作，主要目的還在於對歷史版本的備份，三個版本相互獨立，trunk負責保存當前穩定版本；branches 負責保持你開發分支版本，進行新需求開發；tags則保存最終發佈上線版本，所以不可再修改。各司其職，各盡其責，使得開發過程中版本控制有條不紊，幾十個人的合作開發也不成問題。
案例
比如：開發進行到1.0版本測試完成，要進行對外軟件發佈了，同時項目組後續會拆分成兩個小組，一個小組負責1.0版本的BUG維護，另一個小組開始在1.0基礎上進行2.0版本的開發。此時，就可以把當前版本從trunk拉到tags下一份，標記爲release1_0，然後對外發布時就從這個文件夾獲取；然後再把當前版本拉到branches下一份，標記爲bugfix1_0，負責1.0版維護的小組以後就在這個文件夾下進行修復工作，負責2.0版開發的小組繼續在trunk下工作；
Tags的定義規則
project name + 版本號，版本號定義爲三段數字編號
***.***.*** | | |______ 修正bug | | _________ 新功能版 | _____________ 革命性的產品升級版
分支定義規則：
project name + 日期時間 + 版本號，比如：project_20150202_v1.0.3,在創建每一個分支時，必須增加標註。
結論
重要的檢查點是里程碑，重要的需要客戶確認的里程碑，就是基線。在我們實際的項目中，周例會是檢查點的表現形式，高層的階段彙報會是基線的表現形式。
崗位職責說明書
其實也是干係人管理的基礎。
如何解決開發質量？
各司其職，各負其責。靠自覺，上工具，靠自主，靠自助往往是有問題的。人是沒有下限的，尤其是新人，沒見過好的，就不知道什麼是標杆。每個人除了“寫代碼”，還有什麼必須要做的符合職業道德的素質體現的“本職內”事情麼？這個問題誰來明確？這個時候依賴什麼？依賴檢查。誰來檢查？崗位職責說明書的作用就體現出來了。
| 角色 | 職責 | 檢查清單 |
|---|---|---|
| PM | 制定推廣流程、檢查改進工作、組織協調、風險識別、彙報工作 | CodeReview |
| 大拿 | 需求、設計、原型、DB、彙報工作 | CodeReview |
| 組長 | 詳細設計、任務拆分、計劃跟進、代碼審查、上線評審、彙報工作 | CodeReview |
| 骨幹 | 攻堅克難、掃清障礙、帶出副手、彙報工作 | CodeReview |
| 成員 | 打擊敵人、保存自己：集中優勢兵力橫掃戰場。帶新人；、彙報工作 | CodeReview |
| 新人 | 服從安排、聽從指揮：努力開發、集中求教。學習職場、開發基礎常識。寫筆記、彙報工作 | CodeReview |
PM工具：引入Redmine管理
新建項目“XX項目建設-管理平臺”
在Redmine中管理需求
新建子Project“需求分析”，需求組長負責，管理需求跟蹤矩陣。每一個需求除非孵化成熟，否則不能進入下一個環節：概要設計。
需求需要拆分到每一個feature。每一個孵化成熟的需求都對應一個正式的需求編號。
在Redmine中管理概設詳設
新建子Project“概設詳設”，開發組長負責，需求、大拿支持。
要求關聯對應需求子任務feature；
概設和詳設完畢，拆分任務單到開發任務；
在Redmine中管理開發任務
新建子Project“開發管理”，以項目原型一級菜單爲基礎，建立問題類別。以二級菜單爲問題類別下的功能包，三級菜單作爲feature。若預估人月大於2天，建議拆分到0.5天或更小的子任務；
在Redmine中管理測試和缺陷
新建子Project“測試和缺陷管理”，由測試組長負責；
最好是搭配testlink集成到redmine統一管理測試：有待驗證；
測試和缺陷一般都是不分家的。如何協調好測試任務和缺陷任務的關係，是一個不小的挑戰。甚至還會追溯到需求任務管理。有熟悉的大神，希望能指教一二。
新需求管理
"變更治理"或許更合適。
新建子Project“新增需求管理”，或者合併到“需求分析”project中。以問題類別來區分。
涉及到版本迭代和新功能增加和舊功能迭代，這個是要平衡的藝術。
新增需求，或者從缺陷中反饋的需求，需要整理集中起來，定期或不定期開評審會議：接受或拒絕；
接受則走需求新一輪流程；
拒絕則明確發文給出反饋；
最煩混沌狀態：熱情隆重又啥也沒說，不接受不配合也不拒絕；
遇到這種項目，如果不能通過努力影響之、改變之，還是儘快撤退換地方吧。
PM技能：開會
會議是溝通的橋樑。牢記會議的目的。會議的主要形式及產出物有：晨會、周例會、週報、里程碑彙報、項目啓動會、結項會議。主要涉及干係人和溝通計劃。
| 編號 | 類別 | 作用 |
|---|---|---|
| 1 | 項目啓動會 | “名正言順” |
| 2 | 晨會 | 站立會議，短平快。 |
| 3 | 周例會 | 跟進計劃，通報和表揚。 |
| 4 | 週報 | 任務跟進、風險識別 |
| 5 | 里程碑彙報 | 評審，基線 |
| 6 | 結項會議 | “職責交接清晰，不留後遺症” |