死亡是一座永恒的灯塔

0%

敏捷开发流程

发表于 更新于 分类于
本文字数： 2.1k 阅读时长 ≈ 2 分钟

敏捷软件开发，又称敏捷开发，是一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力。它们的具体名称、理念、过程、术语都不尽相同，相对于“非敏捷”，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重软件开发过程中人的作用。

一、story讲解

  1. 制作竞品分析PPT，UE全组参与。（用时：根据产品复杂度，0.5-2小时之内）
  2. 制作产品原型，交由客户看，客户没有异议之后禅道录入story
  3. 产品在禅道拆分好story，并且定义出优先级，关联需求，后续开发根据优先级进行开发
  4. 由产品讲解story，前端和后端都参与。（用时：根据产品的复杂度，1-3小时之内）

二、人员划分

  1. 新建wiki项目主页，把PPT和产品原型（HTML文件）上传到wiki
  2. 根据产品原型，按照模块划分相关负责人，前端和后端都是，并放到wiki。（由项目负责人新建）

三、定义接口文档（2-3天）

  1. 前端后端相关人员一起，对照原型，根据模块及页面大概定义出接口
    • 一个页面中有几个接口，每个接口入参与出参是什么
  2. 后端每个模块的负责人，根据开会讨论的结果，在wiki上生成标准的接口文档
  3. 将后端做好的接口文档发给前端模块负责人过目，有问题继续修改；没问题开始后续的步骤 。

四、方案设计（1小时-1天左右，根据模块大小定义时间）

  1. 后端开发人员，根据原型以及定义的接口，做好方案设计
  2. 对有难度或者有疑点的接口，做出方案，尽量给出多个合理方案
  3. 每个方案写清楚优点缺点

五、方案评审（2-3小时）

  1. 对做出的方案设计，做方案评审，建议全体人员参与（无论做不做该项目）

六、禅道拆分（1-2小时）

  1. 相关负责人按照优先级顺序，在禅道拆分自己的任务，单个任务最多不要超过4小时，即拆分要详细

    • 拆分一个task时，以具体写的代码为一个task，并在任务名称中写出该类/方法的名称在任务描述中写出该task的代码块具体有的功能
    • 当拆完task后，这几个task所完成功能的代码已经过了一遍
    • 如果有不了解的功能，在方案评审前先写出一个demo，以方便拆分task的估时
    • 一个task用时应在0.5-2之间，最大最大4个小时

  2. 以文件上传功能为例，分成3个task

    • task1.任务名称：公共模块-文件上传-上传文件controller的方法fileUpload
      任务描述：通过网页获取文件，文件判空，判断文件的归属类型（用户/教材/课时/步骤/咨询）
      工时：1
    • task2.任务名称：公共模块-文件上传-添加文件FileUtil 和FileUtilOssImpl
      任务描述：util处理上传的文件，判断文件类型，大小，设置文件上传的路径，返回的url
      工时：1.5
    • task3.任务名称：公共模块-文件上传-文件接口spring-fileOss.xml 配置文件
      任务描述：oss的文件上传， 调用的spring.xml配置文件（密匙，ID,bucket等）
      工时：1.5

七、开发

  1. 搭建开发服务器
  2. 开发人员根据禅道上的任务，按时完成自己的开发工作，具体体现到日报上
  3. 每天上午开10分钟左右进度会议，如果有延迟现象出现，拿出解决方案，保证项目按照禅道上的时间点完成
  4. 数据库索引(两种索引):
    1. 经常查询的，数据散列度比较高的，做一般索引，不需要建联合索引。
    2. 数据必须保持唯一的，建唯一索引。(要有文档，文档表明哪些字段要建索引。发邮件。)

八、阶段测试

  1. 每天至少发布一次代码到开发环境，并且保证发布完之后程序没问题(与开发并行)

九、性能测试和coderevivew（1天）

  1. 对每个接口做好性能测试
    • 每个接口的响应时间不超过200ms，如果有超过的，做优化，尽量缩小到200ms内
  2. 完成codereview，根据codereview结论完成修改

十、压力测试

  1. 做好压测报告

十一、 Demo

demo

  1. 发demo申请邮件，收件人包括产品、测试同学、前后端相关开发人员
    1. 主题：XX项目demo通知
    2. 内容：时间 地点 参会人员
  2. 开demo会议：主讲人：某个开发人员
    • 会议途中产品和测试提出问题
  3. 发demo结果通知邮件(由产品同学发)
    1. demo结果
    2. 如果不通过，有哪些问题

  4. 如果不通过，召集第二次Demo会议，知道通过为止。第二次会议只需演示之前不通过的部分

    测试

  5. demo通过之后
    1. 开发人员对代码打tag（参考文档： 如何打tag 。）
    2. 开发人员部署测试环境，部署完成之后发邮件，写明域名；
    3. 交给测试人员进行测试，测试人员发送全体测试周期邮件
  6. 测试期间，如果有测试发现bug，会在禅道上面提出bug，禅道会发送邮件到各自开发人员的邮箱，开发人员要关注BUG邮件 ，及时确认BUG，及时修改
  7. 修改BUG之后，开发环境前端代码由前端同学自己部署，后端代码由后端同学自己部署
  8. 测试完成之后，测试或产品发送上线通知
    具体参看： 测试Bug划分及处理流程 。
    测试和线上环境发布流程： 测试及线上环境发布流程 。

十二、 发布测试环境、集成测试（2-3天）

  1. 禅道上建立bug，测试出bug，指派给相关人员修改

十三、发布线上环境，同时停止开发环境和测试环境

十四、线上监控

  1. 错误报告
坚持技术分享，您的支持将鼓励我继续创作！