- 1、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。。
- 2、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载。
- 3、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
- 4、该文档为VIP文档,如果想要下载,成为VIP会员后,下载免费。
- 5、成为VIP后,下载本文档将扣除1次下载权益。下载后,不支持退款、换文档。如有疑问请联系我们。
- 6、成为VIP后,您将拥有八大权益,权益包括:VIP文档下载权益、阅读免打扰、文档格式转换、高级专利检索、专属身份标志、高级客服、多端互通、版权登记。
- 7、VIP文档为合作方或网友上传,每下载1次, 网站将根据用户上传文档的质量评分、类型等,对文档贡献者给予高额补贴、流量扶持。如果你也想贡献VIP文档。上传文档
查看更多
第13章 结束项目或阶段 作为项目整合管理的一部分,结束项目或阶段是完结所有项目管理过程组的所有活动以正式结束项目或阶段的过程。在结束项目时,项目经理需要审查以前各阶段的收尾信息,确保所有项目工作都已完成,确保项目目标已经实现。由于项目范围是依据项目管理计划来考核的,项目经理就需要审查该文件,确保在项目工作全部完成后才宣布项目结束。如果项目在完工前就提前终止,结束项目或阶段过程还需要制定程序,来调查和记录提前终止的原因。 第13章 结束项目或阶段 本过程涵盖进行项目或阶段行政收尾所需的全部活动。在本过程中,应该逐步实施: 为达到阶段或项目的完工或退出标准所必需的行动和活动; 为向下一个阶段或向生产和/或运营部门移交项目的产品、服务或成果,所必需的行动和活动; 为收集项目或阶段记录、审核项目成败、收集经验教训和存档项目信息(供组织未来使用)所必需的活动。 图13-1显示了本过程的数据流向图。 第13章 结束项目或阶段 管理收尾,包括生成、收集和分发信息来使阶段或项目的完成正规化。为结束项目,项目经理需要完成相关活动,如:项目回顾、发行早期版本、主导beta测试、指导项目走向尾声等。 13.1 过程的输入与输出 本过程的输入包括: 1)验收的可交付成果。已在核实范围过程中通过验收的那些可交付成果。 2)组织过程资产。可能影响本过程的内容包括: 对结束项目或阶段的指南或要求(如项目审计、项目评价和移交准则); 历史信息与经验教训知识库(如项目记录与文件、完整的项目收尾信息与文件、以往项目选择决策与绩效的信息,以及风险管理工作的信息)。 13.1 过程的输入与输出 作为结束项目或阶段过程的结果,需要更新的内容包括: 项目档案。在项目活动中产生的各种文件,例如,项目管理计划、范围计划、成本计划、进度计划、项目日历、风险登记册、变更管理文件、风险应对计划和风险影响评价。 项目或阶段收尾文件。包括表明项目或阶段完工的正式文件,以及用来把完成的项目或阶段可交付成果移交给他人(如运营部门或下一阶段)的正式文件。 13.1 过程的输入与输出 在项目收尾期间,项目经理应该审查以往的阶段文件、范围核实过程所产生的客户验收文件以及合同(如果有的话), 以确保在达到全部项目要求之后才正式结束项目。如果项目在完工前提前终止,则需要在正式的收尾文件中说明项目终止的原因,并规定正式程序,来把该项目的已完成和未完成的可交付成果移交他人。 历史信息。把历史信息和经验教训信息存入经验教训知识库,供未来项目或阶段使用。可包括问题与风险的信息,以及适用于未来项目的有效技术的信息。 13.1 过程的输入与输出 本过程的输出还包括最终产品、服务或成果移交。移交项目所产出的最终产品、服务或成果(在阶段收尾中,则是移交该阶段所产出的中间产品、服务或成果)。 此外,专家判断用于开展行政收尾活动。依靠专家来确保项目或阶段收尾符合适用标准。 13.2 管理发布早期版本的请求 项目经理如果一直在使用敏捷生命周期(而且一直随着项目进展进行测试),就不用担心发布早期版本的请求,因为软件在每个迭代结束时都是可以发布的。如果提供的功能不够,可能客户不愿意付钱,不过产品总是可以发布的。 13.2 管理发布早期版本的请求 要是使用其他生命周期,项目经理就得尽早知道是否需要发布早期版本。回头看看你最近管理的项目,如果在大型组织中,也可以看看其他人最近的项目。这些项目要求发布早期版本了吗?如果答案是肯定的,很可能你也得这么做。 要是开发人员做不到按功能逐个实现,项目经理还是可以让开发人员使用持续集成,让测试人员按功能逐个开始测试。 13.2 管理发布早期版本的请求 如果这些方案都不适用,项目经理就得准备两次结束方案了。第一次是发布早期版本,第二次才是实际的发布版本。这样做的成本很高。要想避免类似情况,项目经理就要跟团队沟通。 13.3 管理bata版本 项目经理要搞清楚关于beta版本的几个问题:希望发布几个版本、对产品完成度的要求、哪些客户将会使用beta版本?当然,这些问题的回答都基于beta版本的持续时间和目的。 可以试着将发布beta版本作为一个子项目。如果使用敏捷生命周期,在版本计划中要预估从哪个迭代开始发布beta版本。有了更多信息之后,项目经理还要及时更新版本计划。 13.3 管理bata版本 一个beta测试模板的内容包括: 1)beta测试目的。简要描述产品版本,为什么要进行beta测试,给公司带来哪些好处等。 2)beta测试客户选择。包括如何选择beta客户、初始客户名单、文书工作负责人等信息。 3)beta测试入口条件。这是一个里程碑条件,表明项目经理知道已经准备好开始beta测试。类似于发布条件,或是系统测试入口/出口条件。 13.3 管理bata版
文档评论(0)