摘要: 版本管理是项目管理知识条线绕不过去的挑战。这里根据实际需要，整理一些笔记，请大家指正。理论指导实践，实践不一定要拘泥于理论。你不照着做，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 | 结项会议 | “职责交接清晰，不留后遗症” |