再议敏捷开发流程

前言

说到敏捷，是我个人一直想贯彻的思想，但是现实是一直在做部分敏捷化的优化工作，因为各种现状、环境问题，没有办法去完整的践行敏捷理论，更多的是去寻找一种传统研发方式和敏捷研发方式的中和产物。企业的体制不会轻易改变，领导的思想也没那么容易变化，组织划分和团队的隔阂没那么容易打破。渐渐的，我并不特别在意敏捷里的那些概念，实践，环节等等，而是转为去坚守敏捷的核心理念并变通的去改善现有的研发流程，比如：快速迭代、高优先级需求驱动、尽力培养团队的自趋性等等。

所以我并不确定这个标题是否适合，这还是不是敏捷？2019年也写过一篇关于敏捷开发流程的一点思路，针对那个时期的现状总结的研发流程。今时今日，组织、职能、团队都发生了变化，本文仅作为针对现状的一点想法，并且范围在研发部门内部，些许不合理还是存在，但是适合的就是最好的。

研发角色划分

• 软件架构师

  架构师针对所有项目、产品制定总体业务架构、应用架构、技术架构，确保产品稳定、可扩展；引导前沿技术的预研与实施；参与团队的梯队搭建、人才培养，提升团队技术能力；制定统一的技术标准、工具、流程。

• 团队负责人

  负责实际物理团队的工作范围管理、工作时间管理、质量管理、团队管理、沟通管理以及相应的问题解决。

• 项目负责人（可能和团队负责人重合）

  负责具体项目的研发流程管控。

• 研发人员

  

研发流程

对于研发阶段的基本要求有：

• 团队是平级的。
• 所有必要产出必须进入知识库管理。
• 所有人员必须严格使用项目管理工具（研发内部目前是MasterLab工具），持续跟踪属于自己的任务状态。
• 物理团队需要对项目团队进行支撑。
• 所有研发事宜必须遵守各个物理团队的规范标准，物理团队负责人校验产出。

对于研发阶段不同的需求来源，我们的研发流程可以分为：

• 需求驱动型

  将会成为最主要的研发方式，特点是需求的发起、收集、边界由研发上游部门（目前是产品）提出，研发的流程边界起于需求评审，终于提交测试部门。

• 业务驱动型

  项目性质决定业务直接对接研发，多见于规模小或者企业留存系统。研发的流程边界起于需求收集，终于提交测试部门。

  对于二次开发性质的项目可以视规模和未来规划灵活采用需求驱动型或者业务驱动型

• 事件驱动型

  主要针对临时事件、线上问题、优先级超高小需求等应急性事件的发生。研发需要采用高机动、高响应的特殊流程来应对。

需求驱动型

项目团队构成

团队特点包括：

• 跨职能，包括前端、后端开发人员（建议包括测试人员）。
• 跨技术栈，囊括所需要的技术线人员。
• 可以依据项目而建，也可以依据需求周期而建。

• 角色：

  • Product Owner(PO)：项目负责人

    项目负责人最主要的职责就是最大化 ROI（Return on Investment 投入产出比）。具体来说就是要确定产品功能，保证需求在研发层面合理，确定功能优先级；制订和执行研发计划；管控整个研发流程，保证项目进度和产物质量；

  • Dev Team(DT)：开发团队

    开发团队需要具备一定的技术广度、并且人员稳定。

  • Scrum Master(SM)：团队导师/组织者

    Scrum Master需要为团队排除一切影响目标的障碍，尽可能的保证团队成员能够专注在自己的事情上。促进团队的沟通，并帮助他人明确自己的职责。是典型的服务型 Leader，并且指导团队运作。

    可以由架构师或者经验丰富的团队负责人来担任。

流程运转方式

研发环节

研发环节流程图如下：

需求阶段

• 需求宣讲/确认/分析/确认

  • 参与者：架构师、研发团队负责人、需求分析人员、UI、QA

  • PO组织需求宣讲会，对需求进行分析、分解、提出问题并解决问题、确认需求各个细节。

    • 需求宣讲会可能多次，直到再无对于需求的疑问。
    • 需求宣讲会是平等的，不是命令的形式，否则会降低效果。
    • 需求分析人员需要较高的业务理解力和参与度，尽量缩小会议的范围，避免所有人都参与的低效的方式。

  • 关于需求的边界

    • 若需求较大，对于需求是否分阶段进行以及每阶段需求边界必须确定，当需求周期超过4周必须分阶段。

    • 若需求不分阶段

      • 当周期超过两周时，PO有权在开发流程进行分期，即多个冲刺，保证持续产出。

    • 若需求分阶段

      • 各阶段需求必须明确，若有阶段需求不明确，不应当划入本次的需求分析。每个需求阶段针对敏捷开发中的一个Epic(史诗)。
      • 接下来的研发过程仅针对当前的需求阶段开始。后续需求阶段直接从开发流程开始周期

  产出：

  • 历次会议纪要，归档知识库
  • 需求周期以及需求边界
  • 业务部门关于需求 的签字

• 需求资源筹备

  1. 需求内部评审

     研发架构师及团队负责人内部评审需求，包括：

     • 需求难易度
     • 需求所需人员匹配度
     • 工作量预估
     • 人员安排

     并且通过研发内部st会议决策。

  2. 项目团队组建

     • PO和SM需要和DT进行初次的沟通，明确：

       • 团队做什么？
       • 什么时候要做好？
       • 怎么做？

  3. 需求分解和宣讲

     • PO通过MasterLab工具对需求进行任务分解
     • 针对复杂需求，PO编写需求文档

     产出：

     • 需求文档

       • 若需求分阶段，需针对每个Epic建立需求文档。
       • 需求文档以矩阵方式，明确Epic下 User story（用户故事，相当于功能模块的概念）的列表，避免像传统方式的需求文档一样冗长，只需简单描述功能（在敏捷的短周期下，每个User story并不会太复杂）。
     • PO需要与团队成员紧密沟通，宣讲需求，确保每个人都能理解要做什么。

设计阶段

• API接口设计

  • 根据UI原型设计前后台数据交互接口。
  • 若PO没有技术背景，可能需要团队负责人协助。

• 数据结构设计

  • PO设计数据结构，并由研发架构师审核后，交付开发团队。（数据结构比较特殊，应避免不同的人来设计）。

• 业务流程/交互设计

  • PO根据需求文档对于一些核心的、复杂的业务需要设计好流程和前端交互。

• 系统设计

  • 系统设计由研发架构师执行，需要站在整个技术中心或者整个自研的角度来通盘考虑

  • 评估此次需求对于现有线上系统的影响

    • 是否需要其他服务的支持
    • 是否需要改动现有架构
    • 是否导致现有服务需要进行扩展

  • 设计解决方案

    • 若涉及较小，研发架构师直接安排人员解决。
    • 若涉及较广，包括了其他项目团队，架构师协调沟通安排人员解决。
    • 此类额外的工作量也必须包含在项目工作量中，并通过st会议调整。

• 高效沟通

  • PO和DT必须建立高效的沟通

    • DT对于需求的疑问
    • PO对于需求的设计目的
  • 架构师或者st团队随时对团队进行协助和支持。

产出：

• API接口文档
• 系统设计文档（忽略形式，简明概要）
• 数据结构文件、数据库升级脚本

研发阶段

• PO初始化相应的代码库、配置库、权限等开发前置条件。

• PO在MasterLab上建立对应的冲刺阶段，并对冲刺的质量富有监督责任。

  • PO需根据实际情况控制开发进度，调整人员任务
  • PO与DT需要保证高效的日常沟通
  • SM需要指导团队正确运行，排除障碍

• 每日站会

  1. 我今天做了什么
  2. 我明天打算做什么
  3. 我遇到了什么问题

• 内部测试

  • DT成员在完成自己的某个功能后必须进行测试，保证功能可用
  • PO需要对每日产出做基本的审核

• 提交测试部门

  • PO有权决定是否按照每日或者某几个已完成任务来部分提测版本，来保证冲刺的时间（例如不可抗因素、需求变更导致的延期）。
  • PO审查代码并建立测试版本，准备好升级脚本（sql、配置等）。与测试部门沟通该版本涵盖内容，并告知测试版本号，提交可测试镜像。

  产出：

  • 可测试版本镜像
  • 升级脚本
  • 部署说明（可以与测试沟通解决）

• 回归

  • 若部分提测，测试周期和开发周期重叠时，DT优先修改缺陷，再做新任务。

• 关于DT

  • DT必须实时更改MasterLab上自己任务的状态。
  • DT必须严格按照统一的技术标准和代码规范编写。
  • DT实时反映自己的疑问和问题，业务问题PO负责，其他问题SM负责协调解决。

• 关于冲刺失败

  • 若冲刺时间截止，任务没有完成，则冲刺失败。
  • 冲刺失败时，优先继续完成任务，PO预估剩余完成时间，开启新冲刺，把未完成任务拉进新冲刺里。
  • 关于PO和DT的责任，将在评估会上进行具体讨论。

测试/回归

开发和测试的连结主要是提测和回归，通过标准的测试版本号和相关回归工具互动。期间的一些问题和争议由产品和SM共同沟通协调。

发布及收尾

• 发布

  • 测试部门同意上线，约定上线时间
  • PO在代码库建立上线tag版本，准备好部署说明和相关脚本配置等必备条件

  • 上线

    • 参与人员：PO、架构师、产品、QA
    • 发布负责人负责上线
    • 准备好上线失败的回退方案
    • 上线后QA做线上测试，确定没有问题，上线成功

• 评估

  • PO需要在上线成功后，组织团队进行冲刺回顾

    • 架构师、SM、QA需要参加
    • 分析冲刺中做的好的部分和不好的部分，总结经验
    • 若冲刺失败，讨论失败原因。

  • PO需要编写冲刺回顾文档

    • 记录回顾会议的明细。
    • 总结评价DT团队人员，代码质量差、缺陷数量多的人员需要扣分，好的需要加分，结合工作量、表现等作为项目激励发放的标准。
    • 若冲刺是失败的，需要分析原因，若为外部原因导致，也需说明。

业务驱动型

业务驱动型研发流程整体上同需求驱动型研发流程，不同的是在需求收集环节上会是业务直接对接研发：

相应的，在后续研发阶段流程上也视具体情况来缩减或者调整。

事件驱动型

针对优先级非常高、需求迫切的需求走事件驱动型流程。事件驱动型流程相当于研发内部的快速响应流程，对于流程规范标准等等不做苛刻要求，以达到快速响应的目的。

• 现有项目需求变更或者新增小需求

  • PO、SM协商方案，方案需通过st决议。

  • 快速流程为：

    • 设计
    • 开发
    • 迭代测试
    • 部署

  • 相关产物为

    • API接口
    • 任务分解明细
    • 缺陷记录
    • 部署需要的配置脚本、上线镜像

• 新的需求迫切的大块需求

  • 人员够的情况下正常走研发流程

    • 测试采用部分提测的迭代测试。

  • 人员不够的情况下

    • ST会议确认需求优先级
    • 冻结正在进行的优先级较低的冲刺
    • 确定本需求PO， 直接进入需求阶段。
    • 若人员量级不够，尽可能不冻结更多的正在进行的冲刺，抽调人员进入需求，被抽调人员的冲刺延期。
    • 测试采用部分提测的迭代测试。

• 线上问题

  PO全权负责响应并协调相关资源、人员，以解决问题为第一要务。

欢迎关注我的博客