项目管理的三个重要概念：检查点、里程碑、基线(转)

项目生命周期中有三个与时间相关的重要概念，我发现很多人对这三个概念理解不准确，更不知道如何进行控制。因此把这三个概念论述得比较准确的一段文字贴出来，帮助大家理解。

　　这三个概念分别是： 检查点( CheckPoint )、里程碑( Mile Stone )和基线( Base Line )，他们一起描述了在什么时候( When )对项目进行什么样控制。

　　检查点

　　指在规定的时间间隔内对项目进行检查，比较实际与计划之间的差异，并根据差异进行调整。可将检查点看作是一个 固定 “ 采样 ” 时点，而时间间隔根据项目周期长短不同而不同，频度过小会失去意义，频度过大会增加管理成本。常见 的间隔是每周一次，项目经理需要召开例会并上交周报。

　　里程碑

　　完成阶段性工作的标志，不同类型的项目里程碑不同。里程碑在项目管理中具有重要意义，我们用一个例子说明：

　　情况一：你让一个程序员一周内编写一个模块，前 3 天你们可能都挺悠闲，可后 2 天就得拼命加班编程序了，而到周末时 又发现系统有错误和遗漏，必须修改和返工，于是周末又得加班了。

　　情况二：实际上你有另一种选择，即周一与程序员一起列出所有需求，并请业务人员评审，这时就可能发现遗漏并即 时修改;周二要求程序员完成模块设计并由你确认，如果没有大问题，周三、周四就可让程序员编程。同时自己准备 测试案例，周五完成测试;一般经过需求、设计确认，如果程序员合格则不会有太大问题，周末可以休息了。 第二种方式增加了 “ 需求 ” 和 “ 设计 ” 两个里程碑，这看似增加了额外工作，但其实有很大意义：首先，对一些复杂的项 目，需要逐步逼近目标，里程碑产出的中间 “ 交付物 ” 是每一步逼近的结果，也是控制的对象。如果没有里程碑，中间 想知道 “ 他们做的怎么样了 ” 是很困难的。其次，可以降低项目风险。通过早期评审可以提前发现需求和设计中的问 题，降低后期修改和返工的可能性。另外，还可根据每个阶段产出结果分期确认收入，避免血本无归。第三，一般人 在工作时都有 “ 前松后紧 ” 的习惯，而里程碑强制规定在某段时间做什么，从而合理分配工作，细化管理 “ 粒度 ” 。

　　基线

　　指一个(或一组)配置项在项目生命周期的不同时间点上通过正式评审而进入正式受控的一种状态。基线其实是一些 重要的里程碑，但相关交付物要通过正式评审并作为后续工作的基准和出发点。基线一旦建立后变化需要受控制。

　　重要的检查点是里程碑，重要的需要客户确认的里程碑，就是基线。在我们实际的项目中，周例会是检查点的表现形式，高层的阶段汇报会是基线的表现形式。

 

svn里的branch、trunk、tag的用处

trunk主分支，tags里程碑发布，branches分支开发

这只是个说明，你不按说明来办事也不会怎么样，svn照样工作得很好。

branches：分枝

当多个人合作（Sally和John）时，可能有这样的情况出现：John突然有个想法，跟原先的设计不太一致，可能是功能的添加或者日志格式的改进等等，总而言之，这个想法可能需要花一段时间来完成，而这个过程中，John的一些操作可能会影响Sally的工作，John从现有的状态单独出一个project的话，又不能及时得到Sally对已有代码做的修正，而且独立出来的话，John的尝试成功时，跟原来的合并也存在困难。这时最好的实践方法是使用branches。John建立一个自己的branch，然后在里面实验，必要的时候从Sally的trunk里取得更新，或者将自己的阶段成果汇集到trunk中。（svn copy SourceURL/trunk DestinationURL/branchName -m "Creating a private branch of xxxx/trunk." ）

trunk：主干

主干，一般来说就是开发的主要呆的地方，

tag:

在经过了一段时间的开发后，项目到达了一个里程碑阶段，你可能想记录这一阶段的代码的状态，那么你就需要给代码打上标签。(svn cp file:///svnroot/mojavescripts/trunk file:///svnroot/mojavescripts/tags/mirrorutils_rel_0_0_1

-m "taged mirrorutils_rel_0_0_1")

另有一说，无所谓谁对谁错。

trunk：表示开发时版本存放的目录，即在开发阶段的代码都提交到该目录上。

branches：表示发布的版本存放的目录，即项目上线时发布的稳定版本存放在该目录中。

tags：表示标签存放的目录。

在这需要说明下分三个目录的原因，如果项目分为一期、二期、三期等，那么一期上线时的稳定版本就应该在一期完成时将代码copy到branches上，这样二期开发的代码就对一期的代码没有影响，如新增的模块就不会部署到生产环境上。而branches上的稳定的版本就是发布到生产环境上的代码，如果用户使用的过程中发现有bug，则只要在branches上修改该bug，修改完bug后再编译branches上最新的代码发布到生产环境即可。tags的作用是将在branches上修改的bug的代码合并到trank上时创建个版本标识，以后branches上修改的bug代码再合并到trunk上时就从tags的version到branches最新的version合并到trunk，以保证前期修改的bug代码不会在合并