3.3 项目执行和监控过程
迭代N的执行
A、迭代N的需求细化
考虑每个迭代需要完成的用户故事;
用户故事需包含几个部分,工作量评估、功能性需求、非功能性需求。具体的可参考《用户故事模板及样例及拆分说明》
用户故事编写完成后需要在团队内部进行需求评审,一方面是为了向团队成员解读该需求,另一方面团队成员也可在评审时给出指导性意见。
B、测试用例评审
测试人员根据用户故事要求编写对应的测试用例,并组织项目团队进行测试用例评审。根据评审意见修改测试用例
C、开发
将用户故事的需求开发的过程。
D、开发自测
在开发过程中,每完成一个功能点,都需要及时的进行开发自测并通知产品策划人员进行验收体验。
E、验收
开发完成后,产品策划需要对开发完成的成果进行验收,验证其是否符合用户故事的要求,验证通过后方可流到测试环节,否则需与开发详细讨论其不符合性,其验收的checklist可以参考《产品验收checklist及模板》
F、测试和回归
提交测试时,必须要有正确的版本。测试人员根据测试用例进行测试,在IT平台中提交测试bug,并根据测试的角度给出产品是否发布的意见,输出《测试报告》
G、bug修改
在IT平台中获取分配给自己的bug进行修改。
H、showCase
阶段性必须有可体验版本进行showCase.需要
确定showCase时间:某个迭代开发、自测完成,准备提交测试前
会议前1-2天发出体验版给到参与人员
会议期间,由项目经理组织大家体验、反馈问题、记录问题。
项目经理根据问题情况,与开发或产品确定问题的解决时间并发出会议纪要。
I、灰度发布
迭代一定版本后,由项目经理与团队共同决定是否需要进行灰度发布。
监控方式
每日站立会
主持人轮流担任,负责控制节奏,记录问题,以备会后跟踪。
每人讲自己昨天做了什么,有什么问题,今天的计划是什么;
其他人了解别人的工作情况,并发现指出可能存在的问题。
对于发现的问题,鼓励认领,其余由项目经理指定责任人。
时间通常控制在15分钟内。
会议期间,更新任务墙,任务墙样式如下:
周报
反馈项目计划的执行情况,强调本周工作要达成的目标
暴露出项目的问题,特别是需要领导或其他团队需要协助的问题。
周报可在IT平台中输出。
月报
反馈项目当月的执行情况,包括进度、人力及质量。
反映项目存在的问题和风险。
迭代回顾
每人讲述本次迭代做的好的地方和不好的地方
回顾上个迭代不好的地方,看看改进情况。
让每个人发言。
每次迭代回顾会议完成后,可更新燃尽图
3.4 结项阶段
项目经理指导产品策划收集总结项目的产品运营数据,同时指导团队成员从自身角色进行总结,包括测试、开发、UI等。
项目经理与项目团队成员给出项目总结报告,内容可参考《项目经验教训总结-项目团队》,《项目经验教训总结-项目经理》
召开结项会议,各成员进行结项汇报。
PM小组将过程文档和经验教训总结进行归档。