关于敏捷开发:再议敏捷开发流程

前言

说到麻利，是我集体始终想贯彻的思维，然而事实是始终在做局部麻利化的优化工作，因为各种现状、环境问题，没有方法去残缺的践行麻利实践，更多的是去寻找一种传统研发形式和麻利研发形式的中和产物。企业的体制不会轻易扭转，领导的思维也没那么容易变动，组织划分和团队的隔膜没那么容易突破。慢慢的，我并不特地在意麻利里的那些概念，实际，环节等等，而是转为去坚守麻利的核心理念并变通的去改善现有的研发流程，比方：疾速迭代、高优先级需要驱动、尽力造就团队的自趋性等等。

所以我并不确定这个题目是否适宜，这还是不是麻利？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 全权负责响应并协调相干资源、人员，以解决问题为第一要务。

欢送关注我的博客