项目需求流程

• 需求评审
• UI评审
• 技术评审
• 开发
• 测试用例评审
• 自测
• 提测
• 测试
• 视觉走查
• 合包

需求评审

需求评审一般有pmo（负责资源协配，工期协调，需求排期等）或产品经理发起，需要开发相关需求的产品、后端、测试、ui设计、交互、前端等老师一起参加，参加需求评审最好提前看一下wiki需求文档，这样在评审的时候就可以将自己的疑问提出来，完善需求，有利于后面工期评定。

UI评审

如果需求ui不是太复杂，可能不需要ui评审，在需求评审结束后就需要给出需求开始日期以及工作量、提测日期等。如果涉及到的ui页面过多，太复杂，可以等ui以及交互细节或者动画效果出来之后再评估工期，如果前期已经评定完工期，ui交互出来后发现太复杂评估工期过少，这时候就需要让产品或者pmo决策,看是协调人手还是更改交互或者需求。如果对ui交互某个地方感觉设计不合理或者实现不方便，可以在这个阶段提出，但一定要给出自己的建议或者解决方案。

技术评审

ui交互效果等出现后，可能需要前端和后端一起开技术评审会议，约定接口字段、返回格式等。（确定实现方式后，如果大于5天的技术实现方式，需要些对应的技术wiki文档）

开发

按照产品文档、设计稿、交互稿等进行开发，IOS开发一般会在自己对应的组件根据dev分支重开一个分支（分支命名按照命名规则来即可），一般每个需求都会有自己的群组，需求wiki文档、蓝湖交互文档、接口文档、冒烟用例文档一般会提前发到群里或者放到群公告，如果开发过程中有疑问可以在群里艾特产品或者相应的技术老师。

测试用例评审

在提测前，测试老师会提供测试用例，一般是Xmind文档（如果没有该软件可提前下载），测试用例中会标明冒烟用例（一般标红的或者有标记的是冒烟用例，冒烟用例是提测的时候必须全部通过才能提测，如果不通过提测申请会被打回）。测试用例评审过程中如果感觉有什么细节没有提到或者某些细节需要测试老师着重测试，可以提出。

自测

提测前一天按照测试用例去测一遍自己的需求，确保用例中的冒烟用例全部通过，其他测试用例也得去测一遍。（冒烟用例测试2遍，其他用例自测一遍，如果时间紧最低也得保证冒烟用测试用例自测一遍，防止提测后因冒烟用例不通过而被打回），一般测试老师会提供线上测试用例页面，冒烟用例自测完成后需要在对应的冒烟测试用例后面打上对勾，确认该冒烟用例自测完成。

提测

到了提测日期，一般测试老师会给出提测页面（若没有可在群里艾特对应的测试老师），提交提测申请后，需要在群里提供测试安装包。（打包的时候需要在主工程开辟对应的分支名称，并在git中将需求开发对应组件分支名指到自己开发的分支，然后打主工程包）。最好给测试老师提供一下主工程打包的分支名字，方便测试老师打代码覆盖率包等。

测试

提测后，测试老师会将测试过程中发现的bug填写到jira，对应的开发人员会收到邮件通知，可根据邮件中的描述去定位问题所在，如果对该问题有疑问可知音楼找测试沟通询问，修改完成后，将bug状态改为已解决（最好写上bug原因），最后提交QA验证。

视觉走查

视觉走查需要让ui设计、产品、交互师进行走查，以确保 UI、交互 完整还原，确保ui以及交互实现是他们想要的效果。最好在测试后期快到合包发版的时候，提前询问一下测试老师是否可以进行视觉走查，提前进行视觉走查，给修改ui细节留出一定的时间，防止因为实现效果不同而修改实现方式导致时间不够。

合包

目前App开发是两周一个小版本，第二周周四合包，可以合包的时候各leader会在群组内发消息可以合入dev，这时候如果不确定自己的需求是否可以合包，可以在群里询问一下测试老师，看测试流程是否到了可以合包的阶段，确认可以合包后将自己的分支合并到对应组件的dev分支。一般主工程dev分支会有组长或者对应的人去合入，如果你改了某些东西需要立即合入主工程dev分支，先将自己的改动合并到组件dev分支，并找组长或者有主工程dev分支合并权限的组员帮你合入。