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

朱世伟

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

关于敏捷开发

什么是敏捷

敏捷的核心是迭代:

迭代

我们的研发流程使用敏捷开发的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人一组进行完成。

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

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

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

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

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

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

技术体系

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

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

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

代码库/配置库管理

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

欢迎关注我的博客

阅读 467
4 声望
3 粉丝
0 条评论
你知道吗?

4 声望
3 粉丝
宣传栏