这是我参与「第三届青训营 -后端场」笔记创作活动的第6篇笔记

团队之间的配合才是提高效率的重点

为什么要有流程

• 个人开发者是不需要流程的
• 超过一个人的团队就需要协作
• 随着团队规模的上升，会出现全新的问题

复杂项目没有流程会出现什么问题

需求阶段：每个人都有自己的想法，团队决策需要由有一个过程

开发阶段：多人/多端协作开打，每个人都有自己的安排，相互配合需要一个流程

测试阶段：产品怎样交付，测试如何展开，BUG怎么修都需要一个流程

发布阶段：怎么样确保发布过程平稳丝滑，版本和流量如何控制，需要有规范

运维阶段：线上问题如何应急响应，处理用户反馈和线上问题需要有流程

传统的瀑布模型

• 工作流程的直观表达
• 定义了标准的研发过程
• 以流程未本，理想化模型
• 需求
• 开发
• 测试
• 发布
• 运维

敏捷开发

• scrum

• 以小团队快速迭代

• 团队成员之间的合作更加的紧密

• 以人为本，和用户沟通

• 延申成企业的一个管理框架SAFe（多个scrum协作开发）

  • 精益产品开发
  • 敏捷软件开发
  • 系统思考

• 现代的srum

  • 敏捷教练Scrum Master
  • 产品负责人 Product Owner
  • 敏捷团队 Scrum Team
  • 敏捷发布火车Agile Release Train

• 人员名词解释

  • RD:研发
  • PM：产品经理
  • PRD：需求文档
  • UED：用户体验设计
  • QA：测试
  • Scrum：敏捷团队1
  • P0/P1：优先级0/优先级1
  • Backing：规划列表

• 常有会议

  • 待办事项整理会议

    产品负责人描述下个迭代希望实现的用户故事，PM提出需求列表

  • 迭代计划会议

    选择迭代的任务和估算工作量

  • 每日站会

    • 昨天做了什么
    • 今天将要做什么
    • 你有需要帮助的地方

  • 评审会

    小组向产品负责人展示迭代结果

  • 反思会

    在每个迭代后召开简短的反思会，总结哪些事情没有做好，哪些事情做的好

有哪些阶段

• 需求阶段

  • 科学砍需求
  • 站在用户角度提出需求（MVP最小可行产品思想）
  • 收集用户反馈，快速迭代
  • 评估自己事情的紧要程度，分层（重要，紧急程度，先看重要性）

• 开发阶段

  • 对业界有一定的了解（云原生）。云原生下的开发（WEB IDE）

    • 传统虚拟机

      • 在物理机中模拟出多个虚拟机，每个虚拟机拥有自己的操作系统
      • 运维人员负责维护和交付虚拟机
      • 每个虚拟机中都要安装相应的依赖环境

    • 容器化

      • 容器是在操作系统中虚拟出来的
      • 通过cgroup，namespace和Union Mount等技术实现了容器之间的相互隔离，同时容器只有很低的开销
      • 应用和其依赖作为一个整体，打包成镜像交付

    • 单体架构

      • 多个模块共同组成一个服务，服务体量大
      • 模块之间直接调用，不需要PRC进行通信
      • 服务整体扩缩容量
      • 多人开发一个代码仓库，需要充分集成测试

    • 微服务架构（网络通信消耗大）

      • 各个功能在不同的服务中
      • 不同模块需要进行PRC通信
      • 不同模块可以独立扩缩容
      • 每个服务的代码仓库仅由少部分人维护

    • 团队之间的分支策略

      • 各自用什么分支
      • 冲突怎么解决
      • 如何回退到之前的版本

    • 代码规范

      • 养成良好的注释习惯
      • 不要有魔法数字，魔法字符串
      • 重复的逻辑抽象成公共的方法
      • 正确使用IDE的重构功能，防止修改错误

    • 自测

      • 单元测试
      • 功能环境测试
      • 测试数据构造

    • 文档

      • 大型改造需要有技术设计文档，方案评审

      • 好的接口文档能更方便的前端进行沟通

        测试阶段

    • 为自己的代码负责

    • 不要依赖测试人员

    • 功能环境

      • 需要一个能模拟线上的环境进行开发和测试
      • 环境和环境之间能够隔离吗，不影响其他功能的开发和测试

    • 集成环境

      • 不同人开发的功能合并在一起测试，相互之间的影响可能会产生缺陷
      • 迭代发布的所有功能合并在一起测试，确保发布的所有功能之间的应先不产生缺陷

    • 回归环境

      • 确保新的功能不对老的功能产生影响
      • 回归测试一般会借助自动化测试脚本

    发布阶段

    • 检查发布的全过程，排查问题

    • 发布负责人

      • 负责按照计划执行发布
      • 需要通知各个相关人员发布进展
      • 观察各个服务的发布状态，即使处理异常

    • 变更服务的相关RD

      • 按照上线checklist检查服务的日志，监控，响应上线过程中的告警
      • 对于自己负责的改动，在小流量或者预览环境进行环境验证
      • 执行发布计划中的其他操作

    • 值班同学

      • 发布过程中的监控和告警需要特别关注，如果有异常需要立刻判断是否由变更引起
      • 如果有变更引起的报警或者用户反馈，需要及时终止发布

    • 发布模式

      • 蛮力发布（测试环境）
      • 金丝雀发布（服务会中断）
      • 滚动发布（流程复杂，新老版本不兼容）
      • 蓝绿发布（需求资源量大，一半机器承担所有的流量）
      • 红黑发布（需要扩容一倍）
      • 经常使用的是滚动发布（虽然发布速度慢，但是用户体验好）

      运维阶段

      • 止损
      • 周知
      • 定位
      • 修复

    流程优化

    • DevOps解决方案

      • 代码管理
      • 自动化测试
      • 持续集成
      • 持续交付
      • 效率竖井

    • 通过效能平台串联各个阶段

    • 减少无价值的等待