求）评估
由于我们项目是有合作方一起参与的，所以在需求评估阶段，分为两种情况：
1）有合作方一起负责的需求，在需求设计方案和详细工作量评估输出的时候，需要合作方的负责人先审核确认，而后才是项目组负责人审核确认；
2）没有合作方一起负责的需求，则在需求设计方案和详细工作量评估输出后，项目负责人审核确认即可。
在详细工作量评估输出之后，会将相对应的时间填入我们的项目管理工具（TAPD），而后项目经理根据详细的工作量评估进行排期。
排期的时候，可以项目经理和FO一起排期。如果FO有这方面的能力也可以FO自己排期。
具体计划输出之后，我们会在特性群（企业微信）输出详细计划安排，包括但不限于：FO是哪位、晨会安排、各模块负责人、关键时间节点、主要问题或风险点、详细计划、需求链接。对于一些大的特性，我们还会邮件更新同步，并且同步到TAPD的指定位置。
3、迭代开发
计划输出之后，就正式进入到开发阶段了。
开发根据自己评估输出的时间，进行编码、自测、联调。在需求开发阶段，有几个特别需要关注的点：
1）对于有涉及到UI方面的需求，在开发联调自测结束后，需要拉起美术UI负责人在PC上先行验收，这样可以优先解决一部分很明显的美术体验问题。这个过程也是开发和美术先行验收美术效果。
2）在需求开发的同时，测试人员也会同步开始进行用例的测试，待测试用例输出后，测试负责人会拉起和开发、策划的用例评审，并且输出开发自测用例。
3）开发自测联调之后，就会开始跑自测用例。跑自测用例的目的是为了在输出产品验收的版本的质量稳定，全流程不出现卡点。也正是因为此，开发跑自测用例是版本交付验收的必要条件，且自测用例跑完并通过的比例是要超过90%。
4、迭代验收
开发自测通过之后，就进入到需求验收阶段。因为我们是分支流水线模式，所以先输出的是分支版本。
在分支版本输出之后，分别会有特性小组和美术人员一起安装APP版本进行验收。
与此同时，开发侧本身需要同步提交代码review（code review：CR）。
版本验收的时候，产品和美术会提相关的体验问题，开发人员则同步修改体验问题，以及CR的问题。
在确认体验问题和CR问题都修改完成之后，则会提交正式的合并请求。
这里需要特别注意：
如果当前特性是一个非常大的特性，对原有功能预判有比较大的影响的时候，在原主干版本合入当前特性分支的时候，还可以安排测试人员接入进来，参与冒烟测试，这样可以更进一步确保合入主干的版本稳定。
5、迭代转测试
在项目启动之初的时候，我们就有过约定，版本的正式转测试，都需要合入主干，统一一个版本，减少分支版本和主干版本的不一致性。
所以，在分支版本体验问题修改完成后，经过特性小组评估确定，验收通过，则会正式进入到转测试的环节。
开发人员在正式转测试的时候，除了要发转测试邮件，还需要写清楚转测试的内容，环境等。
6、迭代完结
我们的迭代完结，是以最后的bug修改，体验问题修改完为基准的。在版本循环的时候，我们有介绍，每个迭代的标准。所以，每个迭代的完成，是严格按照迭代的要求来进行的。迭代标准参考如下：
五、适应变更
VUCA时代下，变化才是唯一不变的。作为项目经理，在项目推进的过程中，需要更好地拥抱变化。
在实际
