我在之前写了一篇管理|产品迭代开发上线流程及产品发布确认单的文章,正如评论区有一位朋友回复说“感觉不实用”,确实。我们在后面实践过程中也发现了一些问题,最近和公司同事又沟通出一个版本,分享如下: 一次迭代计划
我们是通过邮件+禅道来配合我们这个计划的执行,一次迭代计划从开始到结束都在这一个邮件中进行回复,迭代计划中的需求和BUG在禅道上记录和跟踪。 第一步:整理BUG产品经理主导,[测试工程师]辅导,从BUG池里面整理出下周迭代计划需要处理的线上BUG清单。 第二步:需求同步[产品经理]整理完下周迭代计划需要处理的需求和[测试工程师]给出的BUG清单,发送邮件给相关的人(发送邮件的时间为周二下班前),并确定进行需求评审的时间(需求评审时间为周三下午) 。 第三步:需求评审完成需求评审。 第四步:执行计划[产品经理]编写需求prd文档及视觉稿设计,[测试工程师]编写测试用例,[项目经理]讨论开发计划。 一次研发计划示例
当然,这个研发计划可以不是一周的总时长。 第五步:进入研发研发劳作中。 阶段性验收计划
阶段性验收需要提前和研发明确需要验哪些功能,以及验收的时间点,同时验收完之后[测试工程师]需要出一个《阶段性验收报告》,这份报告需要有一个状态明确记录是否合格。 第六步:交付验收[测试工程师]在测试环境和预发布环境对本次迭代做完完整性测试之后需要交付给[产品经理]做交付验收。 测试报告
第七步:发布验收产品经理负责人、运营负责人、项目负责人在《产品发布确认单》中进行签字。 产品发布确认单
第八步:正式发布研发拿到《产品发布确认单》才会进行发布,发布之后[产品经理]、[测试工程师]、[研发工程师]需要在线上做回归验收,对照冒烟测试用例和发布验收报告进行抽查。 最后要说的就是:很多规范都是通过一次次“不破不立”不断总结经验才制定出来的。并且没有最好,也没有更好,只有因地制宜、因时制宜的更合适。 欢迎大家一起交流。 |
|