直接进入正文～

整个流程如下：

我们是通过邮件＋禅道来配合我们这个计划的执行，一次迭代计划从开始到结束都在这一个邮件中进行回复，迭代计划中的需求和BUG在禅道上记录和跟踪。

第一步：整理BUG

[产品经理]主导，［测试工程师］辅导，从禅道BUG池里面整理出下次迭代计划需要处理的线上BUG清单。
输出：BUG清单。

第二步：需求同步

［产品经理］整理完下周迭代计划需要处理的需求和［测试工程师］给出的BUG清单，发送邮件给所有相关的工程师（发送邮件的时间为周二下班前），并确定进行需求评审的时间（需求评审时间为周三下午） 。
输出：需求内容和BUG清单、需求评审时间。

第三步：需求评审

全体人员进行需求评审。
输出：产品和研发确定可以完成的需求和BUG，并录入到禅道。

第四步：执行计划

［产品经理］编写需求prd文档及视觉稿设计，［测试工程师］编写测试用例，［项目经理］确定开发计划。
输出1：［产品经理］邮件发送需求prd文档及视觉UI稿、［项目经理］回邮件确定研发计划（交付验收起止时间和发布验收时间，已和产品经理达成一致）和测试用例（已和产品经理达成一致）
输出2：［产品经理］把确定的需求录入到禅道，［测试工程师］把对应的测试用例录入到禅道。

一次研发计划示例如下图：

当然，这个研发计划可以不是一周的总时长。

第五步：进入研发

研发劳作中。
［项目经理］为了风险更加可控，在研发过程中需要建立一个个阶段性验收的时间点，这个是介于项目开始和交付验收开始之间的研发内部流程，当然为了方便［产品经理］跟踪进度，可以同步给［产品经理］。

一个阶段性验收计划示例：

阶段性验收需要提前和研发明确需要验哪些功能，以及验收的时间点，同时验收完之后［测试工程师］需要出一个《阶段性验收报告》，这份报告需要有一个状态明确记录是否合格。
目前制定的是通过率达到85%以上为合格，如果出现不合格时，有问题的功能需要在下次阶段性验收时处理掉，并且计入下次阶段性验收的通过率统计中。
研发需要在禅道上及时打卡，方便产品和测试及时跟踪，同时为了解决研发打卡难的问题，我们的所有任务都拆分成8小时之内，一个任务不得超过8小时。

第六步：交付验收

［测试工程师］在测试环境和预发布环境对本次迭代做完完整性测试之后需要交付给［产品经理］做交付验收。
每一个遗留问题研发需要出一个研发的处理方案，产品需要对遗留问题进行回复。
产品需要在迭代内容清单后面确定验收的结果。
输出：交付验收的《测试报告》。

测试报告示例如下：

第七步：发布验收

产品经理负责人、运营负责人、项目负责人在《产品发布确认单》中进行签字。

产品发布确认单如下：

第八步：正式发布

研发拿到《产品发布确认单》才会进行发布，发布之后［产品经理］、［测试工程师］、［研发工程师］需要在线上做回归验收，对照冒烟测试用例和发布验收报告进行抽查。

以上流程，我们实行了差不多一年，整个流程上走的很顺利，但也有一些需要优化的地方，主要是项目管理者在执行过程中需要注意的事项，姑且叫做《迭代计划优化方案》，强烈建议项目管理者阅读。

迭代计划优化方案：

1、在需求评审之前（至少提前一天），项目经理须把本次迭代的需求按照各功能进行拆

分，确定各功能点的优先级，并和产品经理提前沟通迭代需求上的疑问（测试有时间可以一起沟通）。

注：目前新的迭代都是在周一开启，那么本项在上周五时需要完成。

2、研发在完成上一个迭代的上线，及下一个迭代的需求阅读之后，项目经理和研发拉起一个会议，复盘上一次迭代中的问题（会议之前研发需发给项目经理），解答下一次迭代需求中研发的疑问（会议之前研发需发给项目经理），并汇总尚未解答的疑问到需求评审时使用（会议后汇总）。

注：会议可以安排在周一的部门周会。

3、需求评审时，产品经理按照拆分好的各个功能点进行讲解，并给出该功能点的页面数量，研发根据“功能逻辑”+“页面数量”当场评估这个功能点的开发时间（需要提前认真阅读需求稿）。一个功能点讲完才能讲下一个功能点。

测试工程师记录好产品经理给出的页面数量，在编写测试用户和完成迭代后的实际发时的页面数据进行对比。

注：需求评审时间安排在周一下午。

4、需求评审之后，项目经理根据每个功能点的优先级和研发时长制定整个迭代的研发计划，并邮件同步。

5、奖惩制度，统计到月度绩效分中

1）对产品经理

测试工程师在编写测试用例时发现逻辑有问题。

2）对设计师

评审时的页面数量和实际开发时有出入，UI稿出现错误。

3）对研发工程师

功能点交付出现延期，功能点交付质量不过关。

4）对测试工程师和项目经理

交付验收出现延期，发布验收出现延期，产品质量不过关。

5）其他

遇到重大事件没有及时同步导致本次迭代的出现问题的涉案全体人员。

注：

1、以上表格的事项和时间点都只是一个示例，实际情况以具体迭代为准。

2、需求评审不是做需求说明，而是针对解决方案进行讨论，形成最优解，所以对于有疑问的地方一定要提前提出自己的解决方案，以便在会上进行更有效的讨论。

最后一个说明：很多规范都是通过一次次“不破不立”不断总结经验才制定出来的。并且没有最好，也没有更好，只有因地制宜、因时制宜的更合适。

持续关注，请扫码下方二维码。