以下为工作中总结的一些发版方法论，项目迭代发版流程，适用于业务线移动端 App 开发迭代。
- 产品文档输出
- 需求初审 （根据难易程度决定是否两次评审，假设为两次评审），研发 & 设计 & 数据 & QA 等
- 根据研发可行性、公司层面排期等修改需求，确定二审时间
- 需求二审主要确定本次迭代需求，通知相关人员修改变动内容，确定以下时间点
- 设计评审时间、设计输出时间
- 测试用例评审时间、测试用例输出时间
- 服务器接口输出时间
- 埋点文档输出时间
- 项目开发完毕交付时间
- 设计走查时间
- QA 测试时间
- 版本发布时间
- 各端（客户端、服务器）拆解 需求、任务到个人，预估各个开发人员的各个需求的开发时间，交付时间
- 同步拆解的任务到 Teambition、禅道等办公套件
- 开发完成，通知设计、QA、数据、PM，进行以下流程
- 设计走查，同步到 Teambition 缺陷
- QA 测试，同步到Teambition 缺陷
- PM 检查，同步到Teambition 缺陷
- 数据测试，查看埋点，同步到Teambition 缺陷
- 开发人员进行以上各项 fix，待设计、QA、数据确认缺陷关闭后，合并项目代码
- 产品、运营等发布发版邮件，同步时间、版本、号发版日志至相关人员，抄送公司主管
- 发版日，进行以下流程
- 研发人员提供发布包，提交发版审批
- QA 检查，无误后进行审批
- PM 检查，无误后进行审批
- 数据 检查，无误后进行审批
- 商务广告运营检查，无误后进行审批
- 项目主管检查，无误后审批
- 审批完毕
- 安卓交付市场部，发布包。
- iOS 提交App Store审核。
从小作坊到有一个方法论的比较完善的实践，有不足或者可以完善的地方欢迎指出。
