- 需求
- 首次需求讲解，开发根据以下几点提出问题或是给出建议。
- 原型的基础是否切合目前的实际情况
- 原型本身的内容是否自冾
- 原型要求的背后需要哪些技术支持是我们目前没有或不熟悉的
- 原型是否存在不符合生产环境规则，或法律规定
- 原型中特定要求技术能够实现，但具体方法需要探索
- 原型中特定要求无法判断现有技术能否实现
- 原型中特定要求与app已有实现风格不一致
- UI
- 是否需要适配不同尺寸的屏幕
- 交互要求是否与系统功能冲突
- 设计风格是否与之前保持一致
- 交互风格是否与其他部分保持一致
- 需求变更，条件如下
- 测试阶段前
- 对开发已经完成的工作影响不是很大
- 首次需求讲解，开发根据以下几点提出问题或是给出建议。
- 制定开发方案
- 整体功能方案制定文档
- 技术调研产生报告
- 定制接口文档
- 开发文档
- 工期估计（越近越清晰，越远越模糊）
- 原型确定后工期估计
- 开发方案制定后工期估计
- UI设计结束后工期估计
- 接口开发完成后工期估计
- 需求变更后工期估计
- 部分功能完成后工期估计
- 开发
- 远程仓库里面每一个提交版本都可正常编译
- 每一个单独的功能或bug提交一次，不要多个功能或是bug在同一次提交中
- 当遇到大块的功能时或需要版本隔离时拆分独立分支开发，在自己的独立分支中可以中途提交，每个提交都要推送到远程仓库。开发完成后合并到上游分支
- 提交版本前，开启代码版本对比，检查这个版本中修改的内容。建议总行数不超过500行文件数不超过10个
- 及时拉取上游分支合并代码，不要在上游分支做代码合并冲突处理，不要等到最后合并
- 功能开发中如果有疑问，立即与同项目中其他人沟通
- 产品或是UI中没有明确说明的，开发人员根据技术实现特点自主决定
- 代码功能开发完毕后整体功能梳理，回归自测
- 代码review，所有人查看所有提交
- 复杂逻辑或是重要操作，两个人或是三个人一起解决或操作
- 正确使用测试用例，扩展思路
- 保持代码整洁
- 交给UI，测试
- 根据bugtags修改bug
- 遇到短时间难以解决的bug，小组讨论解决
- 小组无法解决的，或是要修改实现方案的，与项目经理沟通
- 每天提交版本，说明修改内容。
- 测试阶段，产品提出的新的需求，或是开发自行做出的优化，默认安排到下一个版本，不得合并到当前测试版
- 定版交付产品
- 简单文案，或图片修改
- 如果需要bug类的修改，回到测试阶段。
- 提交审核
- 市场元数据配置（更新文案，关键词，名称，图片等）
- 关键位置（打包注意事项）检查后提交市场
- 发布
- 发布前，基础功能（发布前基础功能清单）测试。
- 如果测试中出现问题，取消发布版本。bug告知测试，回到测试阶段。
网友评论