Scrum实施总结（一）

一、团队简介

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查看燃尽图

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

  制定了一个参考模板：

  功能
  
  今天在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后，整个团队休息一周，调整节奏、偿还技术债