关于敏捷开发流程的一点思路

这篇文章并不完善，更多的是在团队初期总结的一些快速执行的思路和流程和一些规则。

关于敏捷开发

什么是敏捷

敏捷的核心是迭代：

我们的研发流程使用敏捷开发的Scrum方式，相对传统的瀑布模型和其他的敏捷方式来说，更加符合我们的现状：

• 迭代开发
• 增量交付
• 自组织团队
• 高优先级的需求驱动

同时我们的研发流程也并非标准化的Scrum，结合了自身企业的特点以及团队的特点，做到更符合我们实际情况的一套流程。

以下是敏捷开发的价值观：

• 程序员的主观能动性，以及程序员之间的互动，优于既定流程和工具。
• 软件能够运行，优于详尽的文档。
• 跟客户的密切协作，优于合同和谈判。
• 能够响应变化，优于遵循计划。

以下是敏捷开发的十二条原则：

1. 通过早期和持续交付有价值的软件，实现客户满意度。
2. 欢迎不断变化的需求，即使是在项目开发的后期。要善于利用需求变更，帮助客户获得竞争优势。
3. 不断交付可用的软件，周期通常是几周，越短越好。
4. 项目过程中，业务人员与开发人员必须在一起工作。
5. 项目必须围绕那些有内在动力的个人而建立，他们应该受到信任。
6. 面对面交谈是最好的沟通方式。
7. 可用性是衡量进度的主要指标。
8. 提倡可持续的开发，保持稳定的进展速度。
9. 不断关注技术是否优秀，设计是否良好。
10. 简单性至关重要，尽最大可能减少不必要的工作。
11. 最好的架构、要求和设计，来自团队内部自发的认识。
12. 团队要定期反思如何更有效，并相应地进行调整。

敏捷开发要求

• 高水平的代码质量和人员素质
• 高水平的自动化测试
• 高水平的配置管理（代码版本、应用、环境）
• 持续集成、持续交付、持续部署

团队划分

我们的团队划分为物理团队和敏捷团队：

• 物理团队：UI团队、Android团队、IOS团队、FE团队、Java团队、QA团队、产品团队

  • 拥有一个团队负责人
  • 代码库、配置库、知识库等跟随物理团队
  • 人员归属于物理团队

• 敏捷团队：

  • 跨职能，包括UI、前端、后端开发人员、QA
  • 可以依据项目而建，也可以依据需求周期而建

  • 角色：

    • Power Owner(PO)：项目负责人，最好有技术背景
    • Dev Team(DT)：开发团队

研发流程

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

• 团队是平级的。
• 所有必要产出必须进入知识库管理。
• 所有人员必须严格使用项目管理工具jira，持续跟踪属于自己的任务状态。
• 当某个阶段PO不太擅长的时候，需要由物理部门负责人提供支持。
• 物理团队需要对项目团队进行支撑。
• 所有研发事宜必须遵守各个物理团队的规范标准，物理团队负责人校验产出。

需求

当确定需要做的时候，进入需求阶段，需求阶段分以下步骤：

1. 需求收集

   • 确定PO。
   • PO向需求来源方收集需求，来源方可能是产品也可能直接是客户

2. 需求分析

   • 参与者：PO、需求分析人员（目前基本是各物理团队负责人）、UI、QA、产品

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

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

   • 关于需求的边界

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

     • 若需求不分阶段

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

     • 若需求分阶段

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

   产出：

   • 历次会议纪要，归档知识库
   • 需求周期以及需求边界

3. 需求定稿

   • Jira和Confluence初始化项目
   • PO编写需求文档
   • UI设计原型

   产出：

   • 需求文档

     • 若需求分阶段

       • 需针对每个Epic建立需求文档
     • 需求文档以矩阵方式，明确Epic下 User story（用户故事，相当于功能模块的概念）的列表，避免像传统方式的需求文档一样冗长，只需简单描述功能（在敏捷的短周期下，每个User story并不会太复杂）。

   • UI设计原型

     • UI设计当前Epic的原型
     • 若需求分阶段，并且各阶段需求明确，UI必须在下一个阶段的开发环节前，提交相应Epic的原型。

4. 需求内部评审

   • 参与者：PO、需求分析人员（目前基本是各物理团队负责人）、UI、QA、产品
   • 根据需求文档和UI设计原型确认需求是否符合预期。若有需求变更以及不及预期处，及时调整。

5. 需求外部确认

   • 和业务部门确定需求
   • 业务部门签字

6. 需求分解

   • PO需对需求进行分解，按照：

     • Epic（史诗）
     • User story（用户故事）
     • Task（任务）
     • Sub-Task

     的层级来分解需求，保证到DT团队人员身上已经是很细的开发任务。

   • PO需要在Jira上录入Backlog。
   • 若PO没有技术背景，可由物理团队负责人协助。

7. 组建DT团队

   • PO需要和物理团队负责人进行沟通，协调人员。
   • 物理团队负责人需要根据需求的优先级、团队成员的能力、现有工作量、和需求的匹配度进行判断和合理安排。

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

     • 团队做什么？
     • 什么时候要做好？
     • 谁来做？

     物理团队负责人也需要参与沟通，进行协助和建议。

设计

• API接口设计

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

• 数据结构设计

  • 物理团队负责人设计数据结构，交付开发团队。（数据结构比较特殊，应避免不同的人来设计）。

• 业务流程/交互设计

  • PO根据需求文档对于一些核心的、复杂的业务需要设计好流程和前端交互。
  • 若PO没有技术背景，需要物理团队负责人协助。

• 系统设计

  • 系统设计由物理团队负责人执行

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

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

  • 设计解决方案

    • 若涉及较小，物理团队负责人直接安排人员解决。
    • 若涉及交广，包括了前后台，各物理团队负责人协商方案，各自安排人员解决。
    • Jira新建User story和Task，归属于当前项目需求。
    • 安排人员不属于当前项目团队。

• 高效沟通

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

    • DT对于需求的疑问
    • PO对于需求的设计目的
  • 物理团队负责人随时对团队进行协助和支持。

产出：

• API接口文档
• PDM数据结构文件、数据库升级脚本

开发

• 物理团队负责人初始化相应的代码库、配置库、权限等开发前置条件。

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

  • PO需根据实际情况控制开发进度，调整人员任务
  • PO与DT需要保证高效的日常沟通
  • 物理团队负责人需要对提交代码进行审查

• 每日站会

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

• 内部测试

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

• 提交测试部门

  • PO有权决定是否按照每日或者某几个已完成任务来部分提测版本，来调整个冲刺的的时间（例如开发慢了）。
  • 物理团队负责人审查代码并建立测试版本，准备好升级脚本（sql、配置等）。PO与测试部门沟通该版本涵盖内容（Jira上任务号），并告知测试版本号。

  产出：

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

• 回归

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

• 关于DT

  • DT必须实时更改Jira上自己任务的状态。
  • DT必须严格按照所属物理部门的代码规范编写。
  • DT实时反映自己的疑问和问题，业务问题PO负责，技术问题由各物理团队负责人负责或者与团队其他成员讨论。

• 关于冲刺失败

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

测试

• 开发和测试的连结主要是提测和回归，通过标准的测试版本号和Jira工具互动。

部署/评估

• 部署

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

  • 上线

    • 参与人员：PO、物理团队负责人、QA
    • 物理团队负责人负责上线
    • 准备好上线失败的回退方案
    • 上线后QA做线上测试，确定没有问题，上线成功
  • 物理部门负责人需要维护上线列表，包括预计上线时间、范围、影响等，方便版本管理，避免造成上线混乱，前后台不统一。

• 评估

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

    • 物理团队负责人、QA需要参加
    • 分析冲刺中做的好的部分和不好的部分，总结经验
    • 若冲刺失败，讨论失败原因。

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

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

日常维护

• 线上问题

  • 由PO和物理团队负责人一起解决

快速通道

针对优先级非常高、需求迫切或者影响比较大的需求走快速通道。

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

  • PO和物理团队负责人协商，安排人员。

  • 快速流程为：

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

  • 相关产物为

    • API接口
    • Jira的Task
    • 缺陷记录
    • 部署需要的配置脚本、可上线包

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

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

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

  • 人员不够的情况下

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

日常管理

日常管理是基于物理团队来进行的。

团队管理

• 团队内部架构

  • 团队内部划分由物理团队负责人负责管理和优化

  • 团队人员应主要分3部分：

    • 核心人员

      承担核心业务和模块的开发工作，也需要承担部分纯技术工作（技术框架升级、新技术学习研究）以及新进人员的帮带，PO的挑选主要为核心人员。

    • 开发人员

      承担主要开发工作，挑选素质好、有上进心、品格端正的作为核心人员培养。

    • 实习培养人员

      承担一些简单的，基础的功能模块的开发，旨在深入学习以及尽快融入团队。如果不行需要及时淘汰。

• 人员培养

  • 帮带

    • 一对一

      新进员工或者实习人员，将由团队核心人员或者技术扎实的人员进行一对一的帮带。主要在技术上进行指导，使相应人员尽快上手和融入。

    • 结对编程

      在人员条件允许下，分解的开发任务可以按2人一组进行完成。

      • 一个骨干开发者 + 一个稍弱的开发者
      • 一个核心人员 + 一个实习或新进员工

  • 培训/共享

    • 定期举行团队内部的交流会

      • 针对开发规范、开发技能进行培训
      • 团队内部分享好的技术方案、方法、工具，采取轮流制。
      • 对于问题解决的经验分享

  • 分享

    • 鼓励团队内部人员分享自己所擅长的技术、工具、方法等，上传知识库。可以根据结果适当激励。

  • 止损

    • 对于不能适应团队、不愿意提高自己、品行不端的人员即使淘汰。
    • 对于潜力不足，主观能动性不强，但是不影响完成任务的人员，适当收回培养的重心，降低期望值。

• 团队氛围

  • 团队负责人需要保持团队内部积极向上、忙而不乱。

技术体系

• 技术体系的优化和升级是一项持续的、生态性的工作。

  • 技术框架升级
  • 实现方案的优化
  • 新技术、新概念的学习、引入
• 技术体系主要由团队负责人以及核心人员来负责

这个方面的工作见效慢，产出低，但是确是整个团队能走多远的基础，作为技术人，停止脚步意味着被淘汰。

代码库/配置库管理

• 由团队负责人负责管理， 要做到保证安全性，不泄露生产环境的配置。

欢迎关注我的博客