敏捷测试模式之Scrum及其实践

摘要：本文首先简单介绍了敏捷开发模式和Scrum，之后详细介绍了在测试团队的具体实践以及作者的经验总结。...

摘要：本文首先简单介绍了敏捷开发模式和Scrum，之后详细介绍了在测试团队的具体实践以及作者的经验总结。

　一、敏捷开发模式简介

敏捷是近年来软件研发领域很火的一个词，采用敏捷开发模式的研发团队是越来越多了，尤其是敏捷模式中的Scrum更是佼佼者大行其道，这表明敏捷模式确有其好处，能给企业带来效率的提升和成本的降低。

让我们看看大名鼎鼎的敏捷宣言，如下图所示：

大家对这段敏捷宣言都有自己的理解，我理解的其核心观点就是敏捷：能够快速，灵活的对变化做出响应，能够去掉繁文缛节，做到身轻如燕，专注于目标并在短期内产出成果物。

其实敏捷开发模式的提出和壮大也是被现实所迫。近年来软件需求变化越来越迅速，如何快速响应这种变化及时推出满足市场需要的产品是对软件从业者的巨大考验，而敏捷开发模式就是一种较好的解决方案，可谓是银弹。

二、Scrum简介

Scrum很多研发团队都在用了，Scrum是当前最流行的一种敏捷开发模式，原因我认为关键是该模式简单明了，给出了具体的实践方式，可操作性很强。

Scrum由一组迭代周期组成，每个迭代(sprint)为2-4周，在每个迭代中都依次有planning (计划)，daily standup meeting(每日站会) ， review(评审) 和retrospective (回顾)会议组成，由ScrumMaster (Scrum负责人)来召集这些会议，当然由团队负责人担任ScrumMaster也是比较常见的；有些团队也采用成员轮流担任ScrumMaster的方式，这样可以增强每个团队成员的主人翁和责任意识等。

三、敏捷测试模式

敏捷开发模式大家都耳熟能详了，但敏捷测试模式还是比较新颖的名词，不能说是本人的创造，但本人在当初组建测试团队时就有运用敏捷开发模式的想法，团队成立后便着手实践该模式并坚持至今，自认为是取得了良好的效果。

当然肯定有人会反驳我的观点，他们认为敏捷开发模式每个迭代都包括设计，开发和测试，无需单独出来一个敏捷测试模式。这种观点当然是正确的，但无论什么模式都要应用到实际工作中去。我所在的公司测试部门是独立的部门并独立开展测试工作，不属于某一具体的开发团队，也就是说开发团队并没有人进行专门的测试工作，在职能架构上研发部和测试部也是并行独立的。

在这种情况下，测试团队应该根据产品计划合理的开展工作，采用敏捷测试模式就是一种不错的选择。

四、Scrum在测试团队的具体实践

下面具体介绍下我所在的团队的敏捷测试模式实践。

我们采用的仍是业界流行的Scrum作为具体的敏捷测试模式，一般情况下每两周一个sprint(冲刺，也就是迭代的意思)，每个迭代由计划，每日站立，演示和总结共四类会议组成。

在计划会议中由ScrumMaster(ScrumMaster负责人，由部门负责人也就是本人兼任)根据产品计划列出本迭代的backlog (待办事项，有的地方也称为User Story既用户故事)，之后再将每个待办事项细分为多个任务，每个任务都会指定具体的负责人和预估的花费时间，这个时间以小时为单位，一般最小单位为2小时，最大为16小时。太短的时间会导致任务过多，可通过整合到其他任务的方式处理；太长的时间则导致任务较粗放，难以把控进度情况和出现的问题。每个任务的预估时间不一定准确，这需要ScrumMaster的经验或者采用团队每个成员进行估算然后取平均值的做法来设定。需要注意的是：请把这个会议的时间控制在一小时内，经常见到这个会议超长的现象，主要原因是没有提前计划，在会议中才开始列出待办事项，我认为待办事项在开会前ScrumMaster就应该已经胸有成竹了，在这个会议中只需要把待办事项具体分解为多个任务即可，甚至于有些待办事项也提前分解好了，在这个会议中只是让团队成员认领任务或者直接分配给团队成员即可。

让团队成员自己认领任务还是进行分配需要根据团队的具体情况进行处理，我所在的团队一般情况下都是由ScrumMaster来分配的，因为自由认领的情况下很可能会出现一些任务大家去争抢，一些任务没人愿意去认领的尴尬情况。当然分配任务也是根据每个团队成员的所长和发展方向作为依据的。
......
本文出自《51测试天地》原创测试文章系列（四十一）