目录

  1. 一、团队简介
    1. 1.1 团队组成
    2. 1.2 使用工具
  2. 二、 实践总结:sprint 1 - sprint 4
    1. 2.1 Sprint 1
      1. 2.1.1 迭代周期统计
      2. 2.1.2 优点
      3. 2.1.3 问题
    2. 2.2 Sprint 2
      1. 2.2.1 迭代周期统计
      2. 2.2.2 优点
      3. 2.2.3 问题
    3. 2.3 Spring 3
      1. 2.3.1 迭代周期统计
      2. 2.3.2 优点
      3. 2.3.3 成员评价和总结
    4. 2.4 Sprint 4
      1. 2.4.1 迭代周期统计
      2. 2.4.2 优点
      3. 2.4.3 问题

一、团队简介

1.1 团队组成

Dev Team:

  • 后台开发 * 1
  • 前端开发 * 1
  • 客户端开发 * 1
  • 测试 * 1

PO:

  • PO * 1
  • UI设计 * 1

Scrum Master:

  • scrum master * 1

1.2 使用工具

  • Leangoo
  • Jenkins
  • Selenium
  • TestStack.White

二、 实践总结:sprint 1 - sprint 4

2.1 Sprint 1

整个项目团队是新组建的,没有实施敏捷的经验

2.1.1 迭代周期统计

Sprint长度:2 week

统计:

WEB 总计
功能点 42 42
工作量 61 61
bug 未做探索性测试
完成功能点 39 39

结果:

功能没有完成,迭代失败

2.1.2 优点

  • 团队对于敏捷的兴趣比较高,工作积极性高

2.1.3 问题

  • 问题暴露不及时:由于团队刚刚组建,成员彼此不熟悉,遇到问题不习惯当面沟通

    在Sprint3开始后(一个月),该情况明显好转,遇到问题时,开发人员逐渐习惯整个团队来讨论解决问题

  • 没有做探索性测试:sprint1中,只针对AC做自动化测试,忽略了探索性测试

    Sprint2开始后,补充探索性测试

  • 发布时间长:没有为开发、测试、生产环境做独立配置,容易出错

    Sprint2开始后,上jenkins持续集成,Sprint3开始后,整体正常

  • 开发团队不习惯任务领取

    由于Sprint1没有持续集成,发布麻烦,所以开发不愿意逐个领任务。要求Sprint2开始后,开发人员要按优先级逐个领取任务并签名

  • 演示太慢:花费2个小时

    Sprint2开始后,由测试人员来演示,由于测试人员对AC和流程比较熟悉,演示速度能控制到1小时左右

  • 不会看燃尽图:PO和开发不会看燃尽图,不会评估开发进度

    Sprint2教会团队和PO通过Leangoo查看燃尽图

  • 立会内容表达不准确:开发团队每日立会讲述的内容不准确

    制定了一个参考模板:

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    功能
    今天在XX配合下做完了XX相关的X个功能的开发/测试,工作量共计X,是否达成目标
    今天还在做XX相关的X个功能,工作量共计X
    明天会做完XX相关的X个功能,工作量为X
    存在什么问题,没打成目标的原因
    任务
    今天做完了哪些任务,正在做哪些任务
    明天要做完的任务,任务预期是什么时间完成
    存在什么问题

2.2 Sprint 2

2.2.1 迭代周期统计

Sprint长度:2 week

统计:

WEB 总计
功能点 39 39
工作量 64 64
bug 4 4
完成功能点 20 20

结果:

功能没有完成,迭代失败

2.2.2 优点

  • 团队沟通和配合更默契
  • 上了Jenkins,发布更快捷

2.2.3 问题

  • 团队对全量回归测试认识不足:验收会前2个小时,团队修复2个bug,之后没有及时做全量回归测试,导致验收时19个功能没通过验收

    在Sprint3开始后,将全量回归测试加入jenkins持续集成中

  • 开发人员不按需求擅自增改功能

    要求开发人员遇到有争议的需求,必须和PO商量解决,不能擅自增改AC

  • 大任务拆解:对于网站页面UI这种比较大的任务,不方便评估工作量,也不方便及时测试

    工作量过大的任务,根据模块、页面拆解成子任务

  • 测试环境预览:PO和UI设计也想看到测试环境,好尽早判断开发是否复合需求

    给PO权限,让PO和设计人员也参与到测试中

  • 优先级调整和需求替换:PO刚开始不太能把控需求的优先级,Sprint开始前,如何确认和调整?PO不清楚如果有需求变化,需要改变或增加功能,需要怎么做?

    • 在下一个Sprint开始前,PO先大概罗列近期要做的功能,开发先写出AC并评估出工作量,PO根据工作量再考虑下一个Sprint要做的功能,从而重排PB优先级。在下一个Spring计划会上,确定该周期要做的功能。
    • 一般不建议在迭代周期内增改需求,如果迭代开始后,一定有需求需要修改或增加,一般有两个方式:等量替换和请客吃饭。从现在的周期内拿出等量或工作量略大于需要修改增加的功能,保证迭代能按期完成。或PO请团队吃饭,让团队加班完成。但不论哪一种,都不能经常使用。

2.3 Spring 3

2.3.1 迭代周期统计

Sprint长度:2 week

统计:

WEB CLIENT 总计
功能点 35 36 71
工作量 67 70 137
bug 13 2 15
完成功能点 35 36 71

结果:

迭代成功

2.3.2 优点

  • 迭代周期中替换了部分需求,没有影响到迭代周期
  • 自动化测试也集成到jenkins中,整套流程正规化

2.3.3 成员评价和总结

  • 开发评价Sprint1是忙,很多技术债要偿还,要适应新的开发模式;Sprint2是茫,有点不知所措,团队和协作不流畅;Sprint3团队已经逐渐熟悉这种模式
  • PO已经找到和开发团队沟通的方法,PO遇到疑问时,如果不是很重要的,会在每天下午5点后空闲时间和开发沟通,不打断开发人员正常的节奏

2.4 Sprint 4

2.4.1 迭代周期统计

Sprint长度:1 week

统计:

WEB CLIENT 总计
功能点 12 27 39
工作量 35 17 52
bug 0 9 9
完成功能点 13 27 40

结果:

迭代成功

2.4.2 优点

  • 从Spring4开始,尝试将迭代周期长度变成1周,以适应产品发布的实际情况,过度良好
  • PO和设计人员也“参与”到测试中

2.4.3 问题

  • Scrum的节奏比较快,团队压力比较大,容易疲劳

    在Spring4后,整个团队休息一周,调整节奏、偿还技术债