初探SCRUM

love测试

Scrum这个名词可能一大部份的同学会感到陌生。那Scrum是什么呢？需要扫盲的同学请先接受一下洗礼吧 http://baike.baidu.com/view/1528674.htm?fr=ala0_1_1  

分销平台从4月份开始实践了三个Scrum，其中有几个问题经常被人问起：

1、敏捷 就一定要坐在一起吗？

2、敏捷 真的就没有文档吗？

3、敏捷 PD就可以往Scrum中塞大把的需求了吗？

4、相同周期内，敏捷 做的需求是否比项目多？

5、不走项目流程 是否会对大批需求的质量和外部协调存在不可控的现象？
可能关于Scrum模型的培训文档大家看过不少，但可能太偏理论。我们是在实践中不断探索、不断总结、不断改进，可以说是实践出真知呀。回答以上问题之前先给大家把分销整个Scrum中的过程一一介绍一下吧，应该能从过程中解答大家的疑问：

1、需求列表确定+工作量评估阶段

1）product backlog

PD定出一个阶段内的product backlog（产品需求列表），一个季度与scrum团队review一遍，让整个团队知道我们近期的产品的发展方向。

2）Sprint    backlog

评审时间：上一个迭代中，开发后期或提交测试前期

评审内容：

a)Sprint    backlog的来源：PD从product backlog中提取一部份优先级高的需求，想放入下一个Scrum中实现

b)参与人员：由scrum团队的scrum master、测试负责人、开发负责人（其它scrum成员有空可以一起参加）

c)评审：（此时还没有产出UC）评估每个需求的功能点和所需要的工时（**人时），如果PD或运营有严格的上线时间要求，则评估在有限的开发总工时内优先实现哪几个需求（这个时候往往会重新拆分需求和划定需求优先级）；如果没有严格的上线时间要求，则做正常的工作量评估；这个时候还有一种需求就是优先级高需求的优先上线，这样一个scrum中就会做多次发布。

3）Scrum计划

计划大至的原则：需求评审、开发、测试以需求为单位交叉进行，没有严格意义上的全部完成再开始的关系；以一个月的Scrum周期20个工作日为例，UC+技术方案评审、编码、测试的时间分别为：3+9+8=>3+10+14（开发和测试时间大大增加），   换算成人时为开发和测试分别为：10*5：14*2，当然这中间也有测试测完一个需求后等待下一个需求提交测试的情况，所以开发测试比在2：1

2、文档评审

1）UC、技术方案

a) UC：由PD编写（如果涉及到交易交互图，则由开发编写）

b) 技术方案：由开发编写

c) UC、技术方案评审：评审都在分销的小房间内进行

2）  测试方案、TC

a) 测试方案：测试人员自己评估需求是否需要写测试方案

b) TC：TC编写和评审

3、编码+开发自测+代码review

4、测试阶段

1）测试提交：单个需求完成即提交测试；

2）测试阶段划分：冒烟+项目环境一轮+交叉测试+探索性测试，DAILY回归+探索性测试，预发，线上。大家可以发现，在项目环境没有按瀑布模型走三轮测试。原因有：需求是多次提交，无法统一划定三轮时间；并且由于Scrum团队对业务理解透彻、需求理解挖掘得较深入，有任务问题都及时与PD确认，把BUG消灭在提交测试前。

5、Scrum总结

1）每个Scrum结束后Scrum团队（运营、PD、开发、测试）以小贴纸的方式表达自己对这个Scrum的评价，Scrum master再将大家的意见归类，讨论并评选出下个Scrum大家努力解决的三个问题。

2）测试同学在CF上总结汇总的业务沉淀

3）开发同学总结开发技能

6、放松

每个Scrum结束会有2-3天的休息调整的时间，一是大家做一下个人总结，二是好好休息，迎接下一个Scrum。其实这一点很重要，我个人也深有体会，在做第三个Scrum的时候我就有点开始浮躁了，迫切想搬出小房间回到原来的位置透透气，放松一下。可见如果个人没有调整好，或者Scrum和Scrum衔接太紧，会使团队成员有巨大的疲劳感，无法激发出工作的热情。

———————————————————————————————

上面整个Scrum过程看下来，大家可能觉得形变神未变。我个人认为Scrum只是团队合作的另一种方式，稳定的团队、无障碍地沟通是对团队的基本要求，承诺、主动、公开、独立评估和完成任务的能力是对团队成员的个人要求。并且Scrum极大的简化了项目团队管理中的责任与权利的问题，Scrum团队成员有对项目执行与进展的直接管理权。Scrum将项目角色间的相互约束，转变为相互协作，我们要重新定义水桶原理：团队水平不是由最短的那块木板来决定，而是取决于木板间的紧密程度。因为就算木板都一样高，而木板与木板间连接不够严实，那满满的一桶水也就所剩无几了。

从上面的过程中，总结几点在Scrum中我们改变了什么？

1、不间断的每日站立晨会：参加人员PD代表、Scrum master、测试，共15分钟左右每个人讲解昨天完成了什么，未解决的问题，遇到的风险，今天计划做什么；

2、PD编写UC；

3、测试由三轮转变成 一轮+交叉测试+探索性测试；

4、在有限的Scrum周期内，弹性地增加了开发和测试时间；

5、工作任务由指派转变成认领；

6、匿名总结；

7、在一个Scrum中没有详细的计划；

8、任务墙：任务墙即白板划分成三块，待完成的任务，已完成的任务，存在的问题。所有任务都以小贴纸的方式展示，开发、测试同学完了某个任务，就将任务从待完成区，移动已完成区。如果所有任务都移动已完成区，即Scrum圆满结束。

9、打分支： 哪几个需求放在一个分支由测试根据回归工作量来决定；

三个Scrum做下来，我们目前仍存在很多问题，比如：

1、一个Scrum中多次发布，重复回归的工作量较大；

2、前端资源不固定造成了Scrum的延时；

3、核心代码没有持续地验证；

这些都有待我们团队一起解决。