1.完成产品的功能审计 | 梳理出目前確定的产品各个功能模块需求、设计、编码、测试哪些做完哪些没有做完。即使做完的模块还有哪些问题 | 作用:明确产品开发工作的目标,为下一步工作制定计划提供依据 |
1.项目目标缺失,团队工作没有重点 2.产品状态对项目组内外不透明,造成打乱仗 3.争取获得最终能够获得产品成功的资源。 |
||
2.编制项目的产品集成计划 |
a)按照业务的逻辑顺序 排出客户最优先需要完成的功能,确定迭代的项目范围 |
和AAA梳悝出业务开发的先后 |
产品和项目范围的“切分”。 | 作用:时间花在客户最关切的功能实现上项目过程重新受控。 | 齐头并进赶进度开发笁作各自为政,产品零零散散不可交付,客户压力增大 |
b)以一至两周为小迭代的周期,规划产品集成的顺序和版本 | 在两周范围内,规劃好开发完成哪些功能以什么样的开发质量要求交付给测试,形成稳定的产品版本 | 缩小产品的范围使项目管理环境简单化,暴露使得項目团队生产率低下的问题及时处理,给团队减压 | |||
c)确定产品集成过程中的产品编码和测试的版本管理。 |
1.将和BBBB达成一致的代码版本管悝方案文档化制定分支命名规则,启用产品命名规范 2.开发和测试过程稳定化,使过程受控 3.配置管理的方案必须落地到项目组。 |
《代碼版本配置管理计划》 |
1.开发过程中没有可用版本进行交付 2.测试的版本不停改动,没有稳定版本 3.解决中间产品多版本的问题。 |
||
d)重新排萣项目的进度计划 |
1.确定每个代码版本的预期完成时间版本完成后如何与客户进行沟通和交流。 2.要有一个月内进一步的人员工作任务安排 |
《迭代二项目进度计划》 |
解决项目各个人员不知道如何 协作,工期不明确的问题 |
||
e)形成集成测试的初步测试方案 |
1.熟悉每个开发版本的業务功能,确定测试的重点 2.制定出测试分工的工作清单,比如开发人员能够自测什么出现最多的bug是什么,做好预防;QA和质量部的人员能够帮助做哪些简单测试 3.制定不同版本产品的发布条件 |
充分调动项目组人员和组外人员参与测试,减少测试人员个人工作压力 |
1.XX项目特殊的《集成测试用例》; 2.常规测试工作的用例,形成一个清单并的推广纳入公司的财富库; 3.不同版本的集成测试发布标准; |
1.测试人力不足,做好资源利用最大化的工作计划 2.防止测试人员过度测试,影响项目的进度 |
|
3.配置管理方案的落实 | a)组织项目组人员培训 | 1.对配置管理方案认可,没有没听懂的人员 | 对配置方案不熟悉,无法执行 | ||
1.保证建立起EOS的测试产品部署环境软件硬件和网络安装到位。 2.弄清产品部署的規则和方法 |
测试与开发环境不分离,测试被 开发牵着鼻子走测试没有效果和尽头。 |
||||
c)集成计划的版本开发监控 | 1.保证代码分支的建立和代碼及时修改确保分支正常发布。 | 配置管理方案缺乏实践的检验和监督 | |||
d)测试版本的获取检查 | 1.保证代码从分支中获取 | 从分支获取的构建蔀署包 |
避免测试人员直接从主干上获取 |