软件开发项目管理

软件开发项目管理的案例解说系列

软件开发项目的需求和范围管理- 系列(一)

引言

在今年第一期的程序员杂志中，我对软件开发项目管理的重要性和进行管理的十大工作内容作了一个介绍。你应该已经很清楚地知道今天绝大多数的软件开发已经不是简单地编写一些程序而已，而是一个综合了对多人合作的运作进行必要管理的流程。只要你经历过任何由多人参加的软件开发工作，你一定对整个开发过程是否具有良好的管理对团队的士气以及对开发结果所造成的影响深有体会。一个软件公司或开发团队对软件项目进行管理的素质和水平，是影响到项目是否能够成功完成、开发出来的软件是否能够真正满足市场或客户要求的关键因素。懂得软件开发的项目管理知识不仅仅是项目经理的责任，也是所有开发人员应该掌握的本领之一。

从这一期开始，我将在这里用理论与案例解析相结合的一个系列的介绍文章，来阐述软件开发项目管理的更多指南和实践方法。这一期我们从如何进行软件开发需求和范围管理开始，接下来在以后的几期中再分别讨论软件开发项目的计划制定、质量控制、以及项目的执行与驱动的管理指南、等等。

常有的项目需求和范围管理的挑战

在软件开发项目进行的早期阶段，项目经理以及开发团队的领导们在制定项

目计划时所经常碰到的一个令人头疼的问题是：如何有效地设定一个开发项目的范围，也就是如何确定所需要开发的软件的功能范围、质量的要求范围等各种所必须满足的条件以及相应的工作范围。很多项目管理人员和开发团队的领队往往被这个问题所困惑、无法有效地从大量的、貌似互不相连的各种技术、市场、用户的要求中得出明确的需求总结，从而妨碍了制定完善的项目计划。

其实这个问题并不是软件开发所独特具有的。任何大型和复杂的项目、包括各种高科技和工程开发项目，都会面临这个典型的问题。是否能够妥善处理这个挑战、并制定出相应的合理的开发项目的计划，是衡量一个开发团队的管理水准的衡量之一。

五年前我在从事微软的新一代嵌入式操作系统(Windows XP Embedded) 产品开发的项目管理时也碰到同样的问题和挑战：在众多的各种需求中，怎样确定哪些工作是我这个开发项目必须要包含的？怎样保证最主要的需求分析不被漏掉？怎样在开发之前建立整个团队对软件的质量期望的共识、事先确定软件必须达到的质量要求？

有效的需求和范围管理的运作流程

我们所采用的开发管理方法就是类似于我在《软件开发项目管理》一书中所总结的方法和运作流程来对付这个挑战：

1) 从需求分析总结确定大方向：

首先，对照任何一个软件开发项目所应该考虑到的九个需求范围的因素，逐步分析和判断这九个因素中对我这个项目影响最大的几个因素是什么、以及每个

因素对我这个项目的具体要求，由此确定和总结出所开发的软件产品的功能范围，同时并确定哪些功能是不在这个项目的范围之内。下图是对这九个需求分析的因素的总结：

图1：软件开发项目需求管理应该考虑的各种因素

根据这个管理指南和原则，我的项目计划的第一步就是首先对所有这些因素进行一个全面的总结，然后把它写在一份“软件需求规范书”(Software Requirement Analysis Specification) 里。这份项目计划的早期文件然后经过整个开发团队坐在一起像开“诸葛亮会议”一样进行审核，对所有的需求总结进行合理性与可行性的逐条分析和评判讨论，并为每条需求进行重要性与优先权的设定。有的无法可以立即确定的，还得通过开发团队进行必要的技术验证、或向我们的市场营销部门或直接向客户进行调查询问来进一步确证。通过几次这样的审核会议，整个项目团队能够很快对项目的具体目标以及主要的工作任务达到共识。

为了方便于该规范书让全体团队成员阅读、并便于在团队审核会议上的逐条讨论，我将这个总结用一个表格将所有的需求分析根据以上需求因素的范围给列出来，作为产品设计规范书的早期内容。这个总结做出来之后，大家就可以逐条审阅和讨论。

下面，我用这个项目的历史作为一个案例来举例说明如何制定这些内容(为了不透露公司的实际产品的开发战略，案例对具体内容作了改动、并用中文说明以便于读者阅读)。以下是这个表格的使用举例：

Item

条款Product Requirement Areas:

产品需求的范围Comments or Issues

(注解及问题): Priority

(优先顺序)

1 Business Requirements (商业需求):

A Windows XP Embedded (XPE) Studio tools Target Designer (TD) and Component Designer (CD) shall be the application development tool suite to enable embedded device developers to design special purpose devices that are based on the X86 platform, and be able to develop embedded applications on desktop and easily deploy to devices and boot immediately…

视窗嵌入式操作系统的一整套应用开发工具要能够为嵌入式设备开发商们提供一个能够在英特尔X86平台上运行的开发环境，使得他们能够在桌面计算机上使用目前已有的通用型软件开发工具方便地进行嵌入式应用软件的开发，然后很容易地将应用软件安装部署在嵌入式设备、并能够立即启动运行…对这个商业需求所应该达到的要求，需要与市场部门进行协商和确证P1

B 视窗嵌入式操作系统在开发早期需要能够同时支持来自世界范围的早期应用开发者的样板产品的开发，特别是对６种主要语言的应用软件开发的支持…对是否需在最初版本的发行时要支持世界范围的各主要语言，需要向营销部门确证。P2

C 视窗嵌入式操作系统的核心必须是与Windows XP Pro在运行上完全兼容的，任何开发商所开发的应用软件应该都能在XPE的嵌入设备上运行…P2

D 视窗嵌入式操作系统的开发工具必须满足各小型开发商使用现有开发工具的市场要求，使得他们能够不仅在Windows XP Pro上进行开发，也能够在Windows 2000 上进行开发…

E 视窗嵌入式操作系统产品的发行必须通过Windows 2000 Logo鉴定验证的各种要求，包括产品的初始安装、升级安装、消除等各种要求…

: …

2 Non-Requirements –Standards (非功能需求- 标准):

A 视窗嵌入式操作系统必须满足微软本身在世界范围内产品发行的本地化标准、包括不同文化、政治、地域等因素带来的各种要求，各软件组件本地化翻译必须通过公司的本地化名称检测…P1

B 开发工具所生成的各种设备接口的驱动组件必须包括支持相关的嵌入式设备在业界的标准，诸如销售记帐器专有的标准、多媒体机顶盒的标准，等等: …

2 User Requirements (使用者需求):

A XPE 产品的开发工具的客户和使用者是那些目前已经在X86平台上进行应用软件开发的开发商。他们对使用开发工具如Visual Studio应该很熟悉，但不见得了解操作系统的所有组件结构，对嵌入式操作系统的要求可能更不熟悉。需要与客户教育部门协商决定对用户的培训的要求以及使用说明书的要求P1

B …

3 Functional Requirements (功能需求):

A XPE 产品的开发工具为客户解决的第一个最主要的开发问题是：为客户提供一个能够快速、简易地生产基于Windows XP Pro基础上的嵌入式设备所需要的、经过客户个体化了的轻型操作系统。整个生产个体化的轻型操作系统的功能必须要经过对使用方案的确证。见使用方案总结的一章。P1

B XPE 产品的开发工具为客户解决的第二个最主要的开发问题是：客户要能够方便地加入他们所开发的嵌入式应用软件，然后将整个操作系统的映像部署到嵌入式设备上。加入客户应用软件的功能必须要经过对使用方案的确证。见使用方案总结的一章。P1

C XPE 产品的开发工具为客户解决的第三个最主要的开发问题是：客户要能够将他们自己的嵌入式应用软件进行模块化的组件生成，使得他们能够有效地控制操作系统映像的大小，满足小型嵌入式设备的生产需要。P1

D XP

E 产品的开发工具应该将开发商进行开发的设计过程用专门的文档储存下来，使得开发商能够很快地一个设计重新载入开发工具，在为不同的设备进行开发时能够很方便地使用已有的类似的设计。P1

E …

4 Performance Requirements (性能需求):

A XPE 产品的开发工具在使用者变换显示界面时不能有超过分之一秒的延迟。P1

B XPE 产品的开发工具在下载操作系统的组件的数据库信息时，显示列表的刷新的延迟不能超过1秒。P1

C XPE 产品的开发工具在生成新操作系统时的总体时间不应超出5分钟，而且必须要有生成进度显示(Progress Bar)。P2

E …

5 Quality Requirements (质量需求):

A XPE 产品的开发工具在开发阶段必须经过代表软件质量的12个质量属性的测试验证。具体测试要求见测试计划文件。P1

B 开发工具在发行前必须通过发行的里程碑终点衡量质量标准。具体要求见里程碑终点衡量文件(Exit Criteria)。P1

C 开发工具所碰到的任何使用错误必须显示于此相关的准确错误信息(Error Message)。所有错误信息必须包括3个部分：出现的具体错误，造成错误的原因，以及如何采取纠正的步骤以消除或避免错误。参见本规范书中对错误信息设计要求的部分。P2

D …

等等

因为篇幅关系，上面这个表格只是一个经过彻底简化了的内容，九个方面的需求分析中的每个方面我只列了几个因素，而实际的文件每个方面的因素至少有几十个之多。但从这个哪怕是十分简单的例子中你也可以看得出来，在开发项目进行计划的第一步，作为项目经理或团队的管理人员，对所有影响到一个项目的各种因素进行思考和验证的重要性。参照以上图1 中的需求管理的考虑因素，从九个方面对开发的要求进行分析和总结，可以帮助你很好地照顾到和把握住应该考虑的各种因素、而不至于遗漏掉重要的东西，从而达到对项目的工作范围起到良好的控制和管理的目的。将这些因素用列表的方法总结出来，可以有效地引导项目参加者和团队成员一起来帮助审核各个需求分析，它同时对整个开发团队在

项目的早期建立开发目的和任务的共识也极有帮助。

2) 从使用方案进一步确定功能需求：

光有一个高层次的需求总结对确定开发项目的范围还是不够的。要建立完整的开发计划，项目经理或开发团队的领导人员还必须对每个具体的软件功能进行确定。那么怎样从一个高层次的需求总结得出具体的功能设计呢？

答案是，最有效的方法根据高层次的需求总结，设计出完整的使用方案，我们把它叫做User Scenarios。所谓的使用方案设计就是，将用户会怎样使用你的软件为解决某个具体问题的整个过程给想象和设计出来，而且应该是一个完整的、从头到尾的使用过程。有了这个过程的总结，再从它的基础上进一步确定每个功能的具体需求。这些具体的功能需求也是需要用文字总结之后，经过整个团队的审核和确证才确定下来。这样的审核与确证可能要来来回回好几次才能最后确定。但是一旦确定之后，它就是一个较为成熟的总结了，它应该包含了整个开发团队对开发的目的的共同认识和意见的回馈，它同时也是对整个开发项目的范围的一个较为完整的确定。

采取我在软件开发项目管理一书中所阐述的从使用方案到功能设计的“三步法”，有了完整的功能需求总结之后，才进行最后的功能设计。这样你就可以保证，所设计和开发的每个功能都有于此相对应的功能需求、有于此相对应的使用方案，而不是毫无目标的、仅仅是因为看起来很“酷”而开发的功能。请参见《软件开发项目管理》有关这方面的论述。

3) 从软件的质量属性来帮助确定范围：

对软件开发项目的范围进行管理的另一个步骤和有效方法是，针对软件质量的12个属性进行对照，由此向客户、市场部门、或领导确定哪些是重要的、我这个项目是必须达到的要求；哪些是次要的、我这个开发可以疏忽的。这个管理方法的指南原则是，代表了一个软件质量的所有属性有的是有冲突的–见下图：

质量标志之间相互融合或对立的关系

图2：质量标志之间相互融合或对立的关系

图中所示的“+”号表示两个不同的质量标志属性相互融合、不矛盾。如果加强某一行的一个质量的属性，那么这个努力会使得所相对的带“+”号的纵栏里的另一个质量的属性也得到加强；“－”表示两个不同的质量标志属性互相对立，要满足其中一个就无法同时再满足相对的另一个。如果加强某一行的一个质量的属性，那么这个努力会使得所相对应的带“－”号的纵栏里的另一个质量的属性受到负面的影响。

例如，如果一个软件的开发和设计做了大量提高其重复使用性的功能，那么这些工作对提高这一软件的灵活性、兼容性、多用转换性等也有巨大的帮助。但是，为提高其重复使用性所必须做的设计上的一些改动，对这个软件本身的效率性的提高则很可能造成负面效果，像额外的程序码必然造成的对运行速度的影响，同时，额外的程序编码也会使“害虫”增多，影响到软件整体的稳定性能。

在有限的开发资源和有限的项目时间情况之下，你往往无法满足代表高质量象征的所有属性。所以你要向客户确证，到底哪些质量属性对他们来说是最重要的。在向客户了解开发质量的要求或分析赢得市场竞争的条件时，制定出满足这些质量需求的侧重点和所要照顾到的优先顺序，并知道避免相互矛盾的质量要求的开发需求。你由此将开发的计划根据客户的要求来安排，将软件的开发和测试的重点围绕着满足客户对质量的期望来做。这样做也就避免了花费时间和精力去做不必要的浪费性劳动，将你的开发项目的工作范围制定得更为紧凑、更讲究效益。一旦确定了满足不同质量要求的优先顺序，你就可以对各个工作注明优先代号，如P1 到P3，如上面表格中的例子。你的开发计划也能够根据这个优先顺序来制定了- 但然是先完成最重要的P1的工作。

总结

使用项目管理的本领在项目的计划阶段能有效的帮助你控制和确定一个软件开发的范围，从而能帮助你的开发团队集中力量开发对客户或赢得市场最重要的东西、并且避免无效开发的浪费。做好一个开发项目管理中的范围管理，也是帮助你建立合理的项目计划和时间表的基础。做好这个工作的技巧在于，按照本文所阐述的三个方法和步骤，先从需求分析的因素考虑出发，从高层次先确定开发项目的各个任务，然后根据功能设计的“三步法”从使用方案来确定具体的功能；最后将所要开发的软件根据质量属性的重要性向客户或领导确证它们的优先权和重要性，由此得出工作重点和范围。这样的开发项目管理方法能够有效地帮

助你管理你的开发的范围。

在下一期的文章里，我再来讨论如何在做完范围管理的基础上，制定合理的开发计划和时间表。

软件开发项目的计划制定- 系列(二)

引言

上一期(今年三月份)的《程序员》杂志所开始的软件开发项目管理的系列文章，以一个软件开发项目的需求和范围管理作了开始。我阐述了对任何一个给定的软件开发任务，我们如何利用需求管理的各个因素的考虑以及客户对代表产品质量的12个质量属性的要求来帮助我们确定整个开发项目的范围。这个项目管理的早期工作的目的，是为了帮助我们能够制定出合理的开发项目计划，也就是项目管理的下一步工作。

在这一期的连续文章里，我来论述你在具备了一个开发项目范围总结的基础之上，应该如何制定一个全面的开发项目的计划，以保证你的开发项目能够取得成功，并以我所管理过的开发项目作为案例来说明具体的管理手段和方法…

正确的计划制定过程以及合理的项目时间表的重要性

如果你是一个进行软件开发项目管理的项目经理或开发团队的领导，是否具备一个完善与合理的项目计划是影响到你所管理的项目成败的关键前提。就像缺少一个完善与符合科学规则的蓝图无法去建造一个大楼一样，没有一个完善的、符合软件开发原则和特性的项目计划，任何一个稍具规模和复杂程度、需要多人配合的软件开发项目也无法做到开发的成功。如果你是一个开发团队的开发技术

人员，哪怕你虽然并不做项目管理的工作，但是为了你的项目成功的利益和整个团队与公司的利益，你也应该期望并且要求你的团队领导或项目经理为你提供一个合理的项目管理计划。你也有责任积极地与他们一起进行协调和合作，在项目的开始之前共同制定一个完善的开发计划。

那么，一个完整的软件开发项目的计划应该包括什么呢？整个计划制定工作的具体任务和工作的顺序应该是怎样的呢？

我在《软件开发项目管理》一书中对开发项目的计划制定以及管理的运作流程作了详细的论述。下图是该书里的对如何进行计划制定的运作流程的概括总结：

具体的很多细节你可以从书中读到，这里我就将最重要的管理概念以及对与我所要举的案例相关的一些内容做一些解释。从上图你可以看到以下这些进行计划制定的管理和执行顺序的理念：

1. 确定软件的功能：在确定了项目范围的基础之上，第一步的计划工作任务是决定所要开发的软件的功能。而这个功能的确定过程是需要经过一个从具体的使用方案到功能需求、再由功能需求到具体的功能设计这样一个三步法来进行的。所以进行设计的项目经理们应该对软件如何被用户使用的整个使用方案做详细的分析总结。

2. 确定各个功能的优先顺序：在确定了软件的具体功能设计设计之后，你应该将所有需要开发的功能的重要性进行一个优先顺序的设定和排列，也就是确定哪些最重要、哪些次要、哪些不重要。我们通常使用从P1 到P3这样三个级别的优先顺序对所有的功能进行划分和排列。这样做的目的有两个：第一是根据事先定好的重要性顺序来安排开发计划，即最重要的功能先开发；第二是为了应付以后可能碰到的必须砍掉一部分功能的情况的出现做准备(在软件开发中常常会有因为市场竞争或客户要求、或开发完成的推迟而出现的某些功能无法按时完成的情况出现)。在这样的情况下你就应该根据事先定好的准则来做决定，而不是临时任意决定哪些功能可以被砍掉或推迟开发。

3. 确定工作任务单元和进行工作任务的分解：在软件各个功能的优先顺序被确定了之后，接下来根据所要开发的具体功能，确定具体的开发任务、并对各个开发任务进行工作任务的分解，达到一个项目的工作任务分解结构(WBS)。这个工作的过程中有一些过渡性的提交物需要完成：首先是将经过优先顺序排列的功能，绘制项目工作任务的网络图(Project network diagrams)，然后采用分解方式进行分解，最后达到一个完整的工作任务单元的排列。(请参照我在《软件开发项目管理》一书中对WBS的做法以及绘制网络图的细节的叙述)。

4. 分配开发资源并进行初步时间估算：当具体的开发工作任务的单元被确定之后，接下来进行开发资源的分配，也就是确定到底由谁进行哪些单元或功能组件的开发。当每个开发工作任务都分配布臵了具体的开发人员之后，项目经理应该要求具体执行这些开发工作的人员来进行每个工作单元的时间长度的估算。在这个基础之上，项目经理再将所有的工作任务的时间估算进行汇总，得到一个整个项目的总体时间表。在绝大多数情况下，对有任何并列进行的开发工作的时间

表，项目经理还需要进行所谓的关键性通道(Critical Path)的计算，对整个开发项目的工作任务的网络图进行重新的排列和调整，以缩短总体开发时间，如采取将有太多宽松时间的工作任务给缩短、将处在关键通道上的工作分配给多人来完成等等手段，来进一步优化整个项目的时间。在这个基础上来产生整个开发项目的最终时间表。

这里我想强调很重要的一点是：任何一个开发项目只有按照这样的方法去制定开发时间表，才有可能得出一个比较能够符合实际情况的时间计划，因为这样的计划制定的运作流程充分考虑到了开发人员的具体因素。做具体开发的技术人员的实际经历、素质、和水平、和所要开发的软件的具体要求，直接影响到每一个开发工作任务的具体时间长短，因为同样一个开发任务，两个不同经验的人所要花的时间是不一样的。项目的时间估计当然还可以以其他方式来得到，但是只有在由真正进行开发的人员做时间估算的基础上得到的总体项目时间表，才最接近于实际的情况。这一点对软件开发特别重要。有不少软件开发项目因为时间表的制定不符合实际而造成严重拖延、甚至遭到被砍掉的下场，或者领导要求员工们用加班加点的方式来补救被拖延的时间表，最大的原因之一就是那些项目从一开始起就没有一个切合实际的时间表、或者是管理人员不懂如何去制定合理的时间表。那种脱离实际、人为想象的时间估算往往是导致项目失败的祸种，但却偏偏有太多的项目管理人员或领导不在乎听取具体开发人员对时间估算的反馈意见。所以，进行一个从下而上的，由做实际工作的执行人员先做估算，然后进行综合再订出总体项目时间表的方法，是任何软件开发组织必须追求去掌握的管理素质。

完整的软件开发项目计划的两个方面

完善的软件开发项目管理的工作要求管理人员在进行计划时同时照顾到两个并列的、几乎各自独立的计划工作任务：一个是软件本身的计划，它侧重于软件功能的计划、影响到软件的设计；另一个是项目的展开和执行的计划，它侧重于软件开发工作的具体运行和管理、影响到项目最终是否能够按时按质量完成。这两个工作所侧重的计划问题并不是一回事：一个与开发的结果有关，也就是对所要开发的软件本身的计划；而另一个与开发的运作流程有关，也就是开发中具体的工作任务的执行过程的计划和规章。但是这两个因素却又是紧密联结、互相影响、不可分割的。它们相互之间既有独立性也有依赖性。

要对软件开发项目有一个完善的计划管理，所要制定的计划就必须是同时包括这两个方面的计划。上面图中所总结的整个项目的计划制定过程，就是照顾这两个方面的具体体现：第一，软件本身的设计计划在决定了软件功能的基础上，用软件的设计规范书来体现；第二，整个开发过程的计划也是在确定软件功能的基础上，经过进一步的任务分解和资源的分配、由工作单元安排和优化后得到的项目时间表来体现。

换句话说，这样的计划方法是将软件功能的总结，同时作为计划软件设计和计划开发任务的前提，从而使得这两个工作的计划都建立在同一个基础上，同时又用分开的局部流程使它们能够独立完成，使它们都不被忽视。这是一个将它们相互之间的独立性和依赖性巧妙地结合在一起的计划制定的方法。它将两个方面

计划的依赖性来互相影响它们各自的结果，使得开发工作执行的计划不是建立在空虚的基础上，而是建立在所要开发的软件的实际功能需要的基础之上。

很多开发团队的管理人员或项目经理往往对软件开发项目的计划的范围感到困惑：到底是计划软件本身的内容还是计划开发工作的细节？它们之间的联系以及顺序是什么？通过对上面图中所总结的同时需要完成设计规范书和工作任务清单的分析，你现在应该明白了，完整的项目计划中这两个方面都要包括，而且要用图中所总结的这个计划流程来运作，才能保证开发工作的任务与所要开发的软件是一致的。这是一个非常重要的需要意识到和理解的管理理念。一个完善和成熟的开发团队或组织必须要求它的项目管理人员或懂得并执行这样的计划制定。

所以一个完善的开发计划最后应该包括两个最主要的计划文件：第一是总结软件中的所有功能设计的设计规范书(Design Spec)，第二是一个与开发这些功能完全相应的开发工作任务的时间表(Schedule)。这两份各自独立的计划文件组成了项目总体计划的骨干文件，成为其他计划文件的依据。比如说，开发团队再根据设计规范书所描述的具体功能要求去进一步制定软件的构架设计以及每个功能组件的实行计划的制定；软件测试团队也根据设计规范书所描述的具体功能来制定测试计划和具体的测试方案。同时，进行项目管理的经理们也再根据工作任务分解结构以及时间表来进一步制定项目的开支计划，并同时根据设计规范书去制定其它的项目管理计划，如风险管理计划、进度状态通报计划、外报计划等等。

在下篇的连载中我会再仔细谈设计规范书的具体撰写内容，以及进行功能设计的“三步法”。这里我先将其它有关项目计划的工作内容作一个介绍…

软件开发管理中所需要的其它计划

除了体现软件的设计规范书和体现项目进度的时间表的制定这两项重要的计划文件之外，在项目的计划阶段，项目经理还必须与开发团队的领队和其它成员一起协作来制定其它几个和开发管理有关的重要计划：

1. 确定每个开发阶段的里程碑(Milestone)：在建立了开发时间表的基础之上，通常我们都将整个软件的开发过程分成几个阶段来来进行。每个阶段先着重开发一部分功能。这样的阶段的终结点就叫这个阶段的里程碑，用M加一个号码来表示，比如从M0开始，到M1，再到M2，…等等。

这样的将开发任务分成几个不同的阶段、每阶段分别注重于先完成一部分开发任务的运作方法，对绝大多数软件开发来讲带有很大的好处。这样的运作流程有助于将所需要完成的整体开发任务，采取逐步开发的方法来渐渐加入和整合新的功能，同时又能够对开发出来的各个组件进行循环式的不断修改和调整、对设计上需要作的改动进行必要的调整、对出现的问题进行及时的修正。这种渐进式的开发方法要求对每个阶段的目标在刚开始就有一个明确的定义。因此，里程碑的制定、以及与此相关的每个阶段相对应的具体日期、以及每个阶段的重点任务等，都应该是项目计划的一部分。

下面我继续拿我所管理过的微软嵌入式操作系统工具的开发项目作为案例来说明这种项目管理的思路，以及里程碑计划的典型内容。以下这个表格就是一种对里程碑进行定义的方法之一：

里程碑里程碑定义里程碑必须完成的功能

M0

6/1/2000 Code complete for Alpha version

初版本功能开发的代码全部完成All key features completed: User shall be able to author a basic SLD file. Help content may not be complete.

所有关键性功能都开发完成。用户将能够使用这个产品进行最基本的嵌入式操作系统设定文件的制作。产品的使用说明书的内容可以还没有全部完成。

M1

7/1/2000 QA completion for Alpha version.

初版本的测试完成Be able to complete all key user scenarios, and including live database support for OS feature selection.

所有关键性的使用方案都能够被完全操作，包括使用实际的操作系统功能组件的分类数据库来选择操作系统的具体功能。

Alpha Release

7/15/2000 初版本的发行

Release to Internal team and JDP partners for dogfooding

初版本向内部发行、让内部用户先“吃狗食”(即开发团队内部先使用还不完善的初版本)，并向开发合作伙伴发行。

M2

8/15/2000 Code complete for Beta version

试用版本功能开发的代码全部完成All major features for beta completed. User shall be able to use all major features: SLD creation and modification, browsing SLD files, browsing DB objects, etc.

试用版本中所有主要功能都开发完成。用户将能够使用所有主要的功能：包括嵌入式操作系统设定文件的设计和修改、浏览设定文件的内容、浏览操作系统功能组件的分类数据库等等。

M3

9/1/2000 QA completion for Beta version

试用版本的测试完成Visual freeze. All help content authored. Usability test completed.

使用界面的设计冻结。所有使用文件的内容都编辑完成。产品的可用性测试完成。

Beta Release

9/20/2000 试用版本的发行Release to both internal team for dog fooding, and to general external users for beta feedback.

初版本向内部发行、让内部用户先“吃狗食”，并向普通的外部客户发行，以获得外部客户的回馈意见。

M4

10/15/2000 Feature Complete

所有功能开发完成All feature completed according to spec. All unit test done. All system tests done. Full regression on all test cases at least once.