谈谈我所理解的敏捷开发

Author Avatar
WoodyXiong 12月 16, 2018
  • 在其它设备中阅读本文章

概念定义

背景

  1. 应对需求永远是变化的
  2. 项目周期过长,需要细化成小单元
  3. 发挥项目组的最大效率
  4. 确定每个人的职责

工具

  • 进度统计工具 禅道、JIRA
  • wiki confluence、gitbook、为知笔记
  • 邮件系统 各大企业邮箱

三大阶段

产品设计阶段(2-3周)
研发阶段(2-3周)
测试阶段(1周)

角色

产品经理(pm)
小组leader
ui工程师
前端工程师
后端工程师
安卓工程师
ios工程师
测试人员

时间线

产品设计阶段

需求内部评审会议

产品经理准备的事项:

  1. ppt 需求的来龙去脉,解决的问题是什么,当前行业内解决的问题是什么,这些解决方案的优劣,具体该怎么做,做成什么样的程度
  2. story 讲故事,帮助理解项目到底要做什么,当前的用户角色是什么、要提供什么样的服务、带来什么样的价值
  3. 原型 ui/ue部门来做 axshore

人员:产品经理们、产品经理leader、研发总监(普通工程师不需要参加)

产出:需求多久可以完成、需要哪些团队人员、确定下次的需求讲解会议时间

需求讲解会议

人员:产品经理、所有参与项目的成员

产品经理:讲清楚产品的背景、需要做成什么样

所有参与项目组成员:弄清楚需求是否理解透彻,判断需求能否实现,有没有需求设计不合理的地方,一定要将需求弄清楚

方案评审会议

人员:小组leader、架构工程师、研发人员

所有的项目参与人员都可以主动设计方案,最后交给架构师和小组leader进行方案评审

  1. 工程师是否都理解了需求,设计方案是否周全
  2. 架构师的能力发挥到最大化
  3. 包含db表结构设计,sql语句、预估部署机器数量,核心算法,开发环境是什么,测试和线上的环境,老旧数据迁移怎么完成,数据初始化方案

开发阶段

拆解task

根据story确定task,一个task不能超过4个小时,需要很精准。预估之前要将所有不清楚的技术摸清楚来才能拆解task。

定义接口文档

人员:前端、安卓、ios和后端

尽量接口也页面没有太大的关联,增加接口的可复用率,接口同时出来

产出接口文档

后端提供假数据

按照持续集成的理念,当天做的东西当天出结果,然后第二天晨会演示,所以需要前端马上进行数据书写

明确职责

每个人都是项目owner,不然项目owner会是最累的,每个人都有责任推动项目

每天开晨会

  • 每个人都要讲昨天做了什么
  • 今天准备做什么
  • 今天会遇到哪些问题,有没有风险(有没有解决方案),当前项目有没有延期
  • 展示mini demo,现场展示
  • 晨报结论发研发人员全员邮件

具体是某个story未开始、进行中、已完成。(不超过15分钟,站会)

燃尽图,当发现与预估时间不一致时,及时更改

小组leader控制延期风险,如果有风险一定要尽早出手

code review

  1. 判断代码是否符合规范
  2. 发现代码有没有风险,有没有没有考虑到的
  3. 实现方案是否是跟预期一致

有问题的话尽量现场写,关乎是否可以进入demo环节

性能测试

复杂的不超过200ms,简单的不超过50ms

后端人员需要了解每个地方大概要多少ms

接口按照响应时间排序,大概能支持多少并发请求

工具:JMeter

demo环节

项目基本上做完了,需要进行验收,结论是通过还是不通过,通过弄出上线时间,不通过则说明原因

验收人员:产品经理、小组leader、技术总监、测试人员

测试阶段

进行部署

运维需要将代码打tag部署到测试环境,并且明确运行环境不能有变动

测试环节

测试人员(qa)将测试跑一遍,包括边界测试、压力测试,找出bug的优先级,负责追踪bug解决的进度

bug修复流程

  1. 将bug分类,1下个版本修复(Major),2修复并且测试通过后上(Critical),3线上直接改(Blocker)
  2. 测试人员在wiki上进行将bug重现步骤写清楚
  3. 测试告诉研发leader
  4. 开发人员进行修复,并且重新打tag打包到测试环境

打包tag

发布日志

  • 发布版本
  • 回滚版本
  • 发布功能描述
  • 发布步骤
  • 负责人
  • 测试负责人
  • 发布状态
  • 发布验证人

发布上线

一般安排在周二或周四发布

所有角色到场

运维正式发布