|
每个实施GJB5000A的人都知道，项目监控过程域中最重要的就是里程碑评审这个专用实践。实际上，里程碑也是项目管理中的重要一环。然而，虽然大家都知道里程碑很重要，对它也很重视，但是里程碑评审如何进行，满足什么条件里程碑可以结束，却没有一个统一的认识。下面给出一些里程碑退出标准，可以作为参考。 通常的里程碑退出标准不需要太复杂，一般需要包含下列项目： 一个项目组要定义自己的里程碑退出标准，最重要的就是要尽早完成，保持简单，并在进展评审以及决策中使用。里程碑退出标准应该是应用项目的远景和目标来解决问题的。 常见里程碑退出标准包括： 完成设计说明书/设计/设计工作项目列表。这点只对完成设计里程碑有用。对于设计里程碑，无论用什么工具或流程进行设计工作，都应该有相应的标准来判断设计里程碑是否完成：也许是设计说明书的90%部分都被评审/审查过，或者是满足功能需求的设计原型已经完成。 实际完成的工作项目。这里的工作项目指的是早期或者项目策划阶段所定义的该里程碑的工作项目列表。当该里程碑的工作项目列表上的工作都已经完成后，这个里程碑就结束了。 特定水平的Bug数量。当我们完成某个测试级别的测试之后，对于这个测试里程碑的退出标准可以使用测试发现的Bug数量是否满足项目组事先定义的标准。 通过指定的测试案例。这个也是对完成某个测试级别的测试任务后的里程碑而言的。我们可以把通过指定的测试案例作为退出标准，这样是为了某些紧急交付任务做出的决策，只要求哪些功能的Bug/缺陷必须在里程碑结束前得到修正。 性能或可靠度的数字标准。这个通常用于交付里程碑。不像功能需求，对于软件的性能和可靠性这样的非功能需求，可以放在交付里程碑之前必须得到满足。 时间或金钱。当一段时间结束后，里程碑就结束。或者当预算用完时，里程碑就结束。不过，这点不适用于军软项目。
项目组事先制定这样的里程碑退出标准，那么在里程碑评审的时候就很容易达成一致意见，而不会进行无意义的争论。 最后，以一个小型的网站项目举例说明某个里程碑的退出标准如下： 按规每个规格说明书要求，完成1~10个工作项目。 针对优先级1的范围，满足80%的可用性目标。 通过优先级1的所有自动化和手动操作测试。 通过优先级2的80%自动化测试。 对所有现有的Bug进行分类。 修正优先级1和2的所有Bug。 获得营销团队和商业团队的认可。
这正是： 退出标准要建立，Milestone评审有可依 无须争来又争去，数据面前有曲直 参考文献：程序之美系列：团队之美、项目管理之美，Andrew Stellman,Jennifer Greene,Scott Berkun，机械工业出版社
|
