概念定义
背景
- 应对需求永远是变化的
- 项目周期过长，需要细化成小单元
- 发挥项目组的最大效率
- 确定每个人的职责
工具
- 进度统计工具 禅道、JIRA
- wiki confluence、gitbook、为知笔记
- 邮件系统 各大企业邮箱
三大阶段
产品设计阶段（2-3周）
研发阶段（2-3周）
测试阶段（1周）
角色
产品经理(pm)
小组leader
ui工程师
前端工程师
后端工程师
安卓工程师
ios工程师
测试人员
时间线
产品设计阶段
需求内部评审会议
产品经理准备的事项：
- ppt 需求的来龙去脉，解决的问题是什么，当前行业内解决的问题是什么，这些解决方案的优劣，具体该怎么做，做成什么样的程度
- story 讲故事，帮助理解项目到底要做什么，当前的用户角色是什么、要提供什么样的服务、带来什么样的价值
- 原型 ui/ue部门来做 axshore
人员：产品经理们、产品经理leader、研发总监（普通工程师不需要参加）
产出：需求多久可以完成、需要哪些团队人员、确定下次的需求讲解会议时间
需求讲解会议
人员：产品经理、所有参与项目的成员
产品经理：讲清楚产品的背景、需要做成什么样
所有参与项目组成员：弄清楚需求是否理解透彻，判断需求能否实现，有没有需求设计不合理的地方，一定要将需求弄清楚
方案评审会议
人员：小组leader、架构工程师、研发人员
所有的项目参与人员都可以主动设计方案，最后交给架构师和小组leader进行方案评审
- 工程师是否都理解了需求，设计方案是否周全
- 架构师的能力发挥到最大化
- 包含db表结构设计，sql语句、预估部署机器数量，核心算法，开发环境是什么，测试和线上的环境，老旧数据迁移怎么完成，数据初始化方案
开发阶段
拆解task
根据story确定task，一个task不能超过4个小时，需要很精准。预估之前要将所有不清楚的技术摸清楚来才能拆解task。
定义接口文档
人员：前端、安卓、ios和后端
尽量接口也页面没有太大的关联，增加接口的可复用率，接口同时出来
产出接口文档
后端提供假数据
按照持续集成的理念，当天做的东西当天出结果，然后第二天晨会演示，所以需要前端马上进行数据书写
明确职责
每个人都是项目owner，不然项目owner会是最累的，每个人都有责任推动项目
每天开晨会
- 每个人都要讲昨天做了什么
- 今天准备做什么
- 今天会遇到哪些问题，有没有风险（有没有解决方案），当前项目有没有延期
- 展示mini demo，现场展示
- 晨报结论发研发人员全员邮件
具体是某个story未开始、进行中、已完成。（不超过15分钟，站会）
燃尽图，当发现与预估时间不一致时，及时更改
小组leader控制延期风险，如果有风险一定要尽早出手
code review
- 判断代码是否符合规范
- 发现代码有没有风险，有没有没有考虑到的
- 实现方案是否是跟预期一致
有问题的话尽量现场写，关乎是否可以进入demo环节
性能测试
复杂的不超过200ms，简单的不超过50ms
后端人员需要了解每个地方大概要多少ms
接口按照响应时间排序，大概能支持多少并发请求
工具：JMeter
demo环节
项目基本上做完了，需要进行验收，结论是通过还是不通过，通过弄出上线时间，不通过则说明原因
验收人员：产品经理、小组leader、技术总监、测试人员
测试阶段
进行部署
运维需要将代码打tag部署到测试环境，并且明确运行环境不能有变动
测试环节
测试人员（qa）将测试跑一遍，包括边界测试、压力测试，找出bug的优先级，负责追踪bug解决的进度
bug修复流程
- 将bug分类，1下个版本修复(Major)，2修复并且测试通过后上(Critical)，3线上直接改(Blocker)
- 测试人员在
wiki上进行将bug重现步骤写清楚 - 测试告诉研发leader
- 开发人员进行修复，并且重新打tag打包到测试环境
打包tag
发布日志
- 发布版本
- 回滚版本
- 发布功能描述
- 发布步骤
- 负责人
- 测试负责人
- 发布状态
- 发布验证人
发布上线
一般安排在周二或周四发布
所有角色到场
运维正式发布
网友评论