里程碑（来源：tita.com）
情况一：你让一个程序员一周内编写一个模块，前3天你们可能都挺悠闲，可后2天就得拼命加班编程序了，而到周末时 又发现系统有错误和遗漏，必须修改和返工，于是周末又得加班了。
情况二：实际上你有另一种选择，即周一与程序员一起列出所有需求，并请业务人员评审，这时就可能发现遗漏并即 时修改;周二要求程序员完成模块设计并由你确认，如果没有大问题，周三、周四就可让程序员编程。同时自己准备 测试案例，周五完成测试;一般经过需求、设计确认，如果程序员合格则不会有太大问题，周末可以休息了。
第二种方式增加了“ 需求 ”和“ 设计 ”两个里程碑，这看似增加了额外工作，但其实有很大意义：
首先，对一些复杂的项目，需要逐步逼近目标，里程碑产出的中间“ 交付物 ”是每一步逼近的结果，也是控制的对象。如果没有里程碑，中间想知道“他们做的怎么样了”是很困难的。
其次，可以降低项目风险。通过早期评审可以提前发现需求和设计中的问 题，降低后期修改和返工的可能性。另外，还可根据每个阶段产出结果分期确认收入，避免血本无归。
第三，一般人在工作时都有“ 前松后紧 ”的习惯，而里程碑强制规定在某段时间做什么，从而合理分配工作，细化管理“ 粒度 ”。
基线基线是软件文档或源码(或其它产出物)的一个稳定版本,它是进一步开发的基础.所以,当基线形成后,项目负责SCM的人需要通知相关人员基线已经形成,并且哪儿可以找到这基线的版本.这个过程可被认为内部的发布.至于对外的正式发布,更是应当从基线了的版本中发布.
基线是项目储存库中每个工件版本在特定时期的一个“快照”。它提供一个正式标准，随后的工作基于此标准，并且只有经过授权后才能变更这个标准。建立一个初始基线后，以后每次对其进行的变更都将记录为一个差值，直到建成下一个基线。
参与项目的开发人员将基线所代表的各版本的目录和文件填入他们的工作区。随着工作的进展，基线将合并自从上次建立基线以来开发人员已经交付的工作。变更一旦并入基线，开发人员就采用新的基线，以与项目中的变更保持同步。调整基线将把集成工作区中的文件并入开发工作区。
三者的关系： 通过定义，我们不难看出，检查点比较细、里程碑比较粗、基线最粗。重要的检查点一般就是里程碑、重要的里程碑一般就是基线。但检查点一般依据时间的先后顺序设定、里程碑一般依据关键成果的产出设定、基线依据一组关键成果的产出设定。
项目管理（来源：tita.com）
