项目里程碑的定义和作用，软件项目中有哪些里程碑

网友观点一：里程碑的定义、作用、以及项目里程碑是什么？

定义：里程碑指设于道路旁边，用以指示公路里程的标志。
作用：多用来比喻在历史发展过程中可以作为标志的大事。
项目的里程碑：在制定项目进度计划时，在进度时间表上设立一些重要的时间检查点，这样一来，就可以在项目执行过程中利用这些重要的时间检查点来对项目的进程进行检查和控制。这些重要的时间检查点被称作项目的里程碑（Milestone）。
项目的里程碑原理
一、这种方法在管理层中用的最多主要是列出项目的关键节点以及这些节点完成或开始的日期。
二、编制进度以前，根据项目特点编制里程碑计划，并以该里程碑计划作为编制项目进行计划的依据。
三、编制进度计划后，根据项目特点及进度计划编制里程碑计划，并以此作为项目进度计划的主要依据。
四、里程碑一般是项目中完成阶段性工作的标志，标志着上一个阶段结束、下一个阶段开始，将一个过程性的任务用一个结论性的标志来描述，明确任务的起止点。一系列的起止点就构成了引导整个项目进展的里程碑。里程碑定义了当前阶段完成的标准（Exit Criteria）和下一新阶段启动的条件和前提（Entry Criteria），并具有下列特征。
1.里程碑的层次性，在一个父里程碑的下一层次中定义子里程碑。
2.不同类型的项目，里程碑可能不同。
3.不同规模项目的里程碑数量不一样，里程碑可以合并或分解。
时间界定
一、里程碑可用于工厂“问题解决”中的工作计划，也就是说对负责人的时间节点的界定。提醒团队中的成员遵守原则，注意自己工作计划中的节点。
二、里程碑在项目管理过程中的定义为一个状态点，代表在此时间点能够达到此状态，并非一个时间段。在项目计划的历时（duration）中通常标识为0天（days）。

网友观点二：别不拿里程碑当石头

     如果说做项目不需要计划，恐怕没人会认同。是否每个项目计划都起到了作用呢？却不尽然。知道要做计划，但不知道为什么做计划，如何做计划的还是大有人在。所以很多计划沦为依样画葫芦，成了摆设。
     IT项目计划的用意其实非常明确。因为我们无法事先知道系统最终会长什么样，和用户想象当中的是否一致，和用户的需求是否匹配，我们就需要通过一个计划，从需求，到设计，到测试最后做出来。每前进一步，都要保证不再返工回前一个阶段。如果一个计划不能起到应有的作用，项目都会在原地逗圈子。而这点绝不是靠某个天才的系统就能解决的。因为一个IT系统在完成之前，没人知道它到底长什么样，大家就不得不借助一些想象。即便有一些原型或者样板，也只是窥一斑而想象全貌。而群众的想象力是无限的。
     其实乔布斯给人们的苹果，并不是人们想象中想要的东西，也不是超出你想象的东西。他给的是一个载体，一个窗口。通过它找到各自想象的东西。从而满足了人们的多样性需求。IT系统里也存在这样的系统，即工具层面的东西，随便你怎么用，但不要提要求。对于面向特定需求的系统，我们所做的就是先找到一个大体适用的方向，然后一起奔着这个方向走，且要不逗圈子或少逗圈子。 

     曾经遇到一个项目，每次项目回顾会上，都有一堆问题。很多问题都说不清楚需要花多少时间解决。还有一些问题，有了解决方案，也有了实施计划。但是，每每问起对整个项目进展有何影响时，项目经理都信心满满地说“没影响”。一次两次也就算了，后来明明某个任务推迟的不像话了，怎么还说不影响项目上线呢？让项目经理把里程碑计划展示一下，这才发现，这些有问题的任务都不和里程碑节点相关（所谓不在关键路径上），以至于都推迟到后一阶段，后后阶段了，还是不用调整里程碑计划。
    ---那确实需要推到上线时间点以后的问题呢？有这种事情吗？
    ---有！
    ---那如何不影响项目上线？
    ---放到上线后完善阶段了
    做了十多年IT项目的我，一时间没听懂，上线后完善是个什么玩意。 只见过上线后支持，哪里又出来个上线后完善呢？　
    后来才明白，这个项目计划，除了里程碑时间节点不变，其他都在变。凡是不能按时间完成的任务，都推迟、推迟，等推倒上线节点也兜不住了，就上线后再去完善了。
    听懂之后，真有种想骂人的冲动。这是做项目吗？这不就是脚踩西瓜皮吗？ 整个一个不拿里程碑（milestone) 当石头。当它不存在，透明的，一概穿越。 最后完全是以任务节点构成的网络结构图在管项目进度，而没有了项目阶段的概念。
    也许是为了心里安慰，因为有任务被推迟，项目经理又把能早安排的事情就提前安排了做。问题是，很多事情如果不是在里程碑节点上有个清楚的交代，那些提早做的事情完全有可能返工重做。比如开发还没结束，就安排一部分用户做试运行（pilot）。　如果开发完成后，有些地方又调整过，那么pilot小股部队就被牺牲掉了，成pioneer先驱了。　
    至于那些所谓上线后完善的事情更是后患无穷。等到项目都剪彩、放鞭炮庆祝成功上线了，谁还会管完善不完善的事情呢。比这更糟的结果是，这“完善”最后成了没完没了的终生事业。那也就不叫项目了。
    其实，项目里程碑节点就意味着质量门。在某些情况下确实会让步放行。但让步的时间和内容都是有底线。这个底线就是，让步放行的东西我是可以不要的。到总体验收的时候，确定无法完善了，也就认了。没有这个共识，就不可以让步放行。
    IT项目其实就是从粗到细的设计，从细到粗执行。制定计划时，先做里程碑计划，明确大阶段目标。而明细计划只要做到当前阶段，所谓的“渐进明细”。不要急着把最后一天做什么都想好。但一定要从第一天就知道最后一个阶段的目标。
    等到计划执行起来则从细到粗。在最细节操作层面的事情，需要反馈到最上层的里程碑计划中，以确定里程碑是否需要调整。在上文的案例中，常常是某件具体的事情都有计划了，比如项目上线时的数据迁移（通常是指未完成的业务操作，例如未关闭的采购订单等）计划。但这是一个个孤立的任务计划，和里程碑计划的关系完全忽略。而作为一个项目，因为其独特性，非常有必要把网络化的任务关系分派到各个大阶段上，然后在里程碑节点上进行“前进还是后退”的评估。里程碑是项目进程中真正的基石，打下桩，就可以继续向前，不再回头看。

网友观点三：软件开发项目流程中的里程碑

摘要: 当我们开车行进在高速公路的时候，经常能够看到路边有牌子或者标记，显示目前的位置离终点或者下一个出口有多远，这就是里程碑，英文名叫做Milestone。随着里程的变化，我们可以保持一直前进的动力，不至于迷失方向 ...
当我们开车行进在高速公路的时候，经常能够看到路边有牌子或者标记，显示目前的位置离终点或者下一个出口有多远，这就是里程碑，英文名叫做Milestone。随着里程的变化，我们可以保持一直前进的动力，不至于迷失方向和信心。

在软件开发项目里程碑也同样存在于项目管理当中。在谭兴才以往的文章中提到了简单划分项目的几个阶段，在其中，项目实施阶段一般来讲都是最长的，对于复杂的大型软件，甚至要跨越好几个年度。为了管理上的方便，同时提高效率，人们往往把大的阶段再划分为几个子阶段，这样实现起来更容易具体，有化整为零，各个击破的意思。这几个子阶段就形成了若干个里程碑，在工作中一般由M1、M2这样的字眼来表示：M表示Milestone的缩写，后面紧跟的数字表示先后顺序。

在一个软件开发项目的进程中，里程碑的表示方法非常重要。虽然里程碑代表了一个子阶段，但在时间上它是一个点。比如，某项目设立了3个里程碑，如下所示。
◇M1：在2012年9月1日前，网站内容部分编码完成。
◇M2：在2012年11月1日前，网站用户部分编码完成。
◇M3：在2013年春节前，网站开始集成与性能测试，完成优化，最终实现上线目标。

在这样的时间表中，各个日期就是各自子阶段的里程碑。里程碑在整个项目中也不宜很多，否则反而容易使得项目参与人感觉项目漫长。在实际的工作中，一般都不超过5个，而且都是选择在项目产品发生明显变化的点上。