敏捷测试模式之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来分配的，因为自由认领的情 况下很可能会出现一些任务大家去争抢，一些任务没人愿意去认领的尴尬情况。当然分配任务也是根据每个团队成员的所长和发展方向作为依据的。

之后每个工作日早上上班一刻钟后召开每日站会。站会，顾名思义，就是站着开会，这样会议的时间不会太长，大家也能集中精力，会议一般控制在十分钟以内。在这个会议中，每个团队成员分别回答三个问题，这三个问题依次是：

1.上一个工作日做了什么？

2.今天计划做什么？

3.遇到什么问题或者困难或者说需要什么帮助？

其他的就不要说了，如果真的需要花较多的时间，就应该另外安排时间进行。

在每日站会中，注意团队成员是在彼此进行沟通和承诺，以便让大家都对任务做到心中有数，而不要搞成是向ScrumMaster汇报工作，这两者是不同的。

在开始实施Scrum的时候，强烈建议准备一个较大的白板和一些即时贴。在这个白板上先划出4列，这4列的列名分别是：待办事项，准备开始，进行中和已完成；再划出横行，可由团队成员数加一来确定横行的数目。在计划会议中，就可以把确定的任务写到即时贴中，一个任务用一张即时贴，可用A4纸打印出待办事项的内容，待办事项的格式可如下图所示。

待办事项的优先级越高，则应该贴在越靠上的行的待办事项列中，之后将任务即时贴都贴在白板的待办事项行对应的准备开始列中。

在开每日站会的时候，团队成员都面对白板围成一个半圆。当团队成员说完其上个工作日完成了什么和今天准备做什么之后，就可以分别移动对应的任务即时贴从进行中到已完成和从准备开始到进行中了，如下图所示。

这里如果第三个问题的答案是肯定形式的（遇到问题或者困难等），则可能无需移动即时贴了，也就是说遇到路障了，则可以在对应的即时贴中特别标注下原因，ScrumMaster和团队相关的其他成员此时应该对路障高度关注，搞清楚原因并试图给出解决方案，如果需要较长时间才能找到原因或者给出解决方案，则需要另外安排时间，不要占用过多的会议时间。

当迭代进行了一段时间，大家都对Scrum有了比较深入的理解后，就可以用更方便的电子白板来取代白板和即时贴了，常见的有https://www.pivotaltracker.com，这个比较方便灵活，微软的TFS也自带了Scrum，支持中文，使用起来很方便。不过使用电子白板后，可能就不是所有人都站着开会了，我们是ScrumMaster坐在电脑前移动电子卡片，其他团队成员站在其周围形成一个半圆。还有的团队是到会议室去开每日站会，大家都是坐着的，不过此时大家都知道这个会议不会开太长时间的，就不必要拘泥于必须要站着的形式了。

一般来说一个Scrum团队的成员数应在5-9人之间，如果团队成员多于9人，建议将其拆分为两个小的Scrum团队分别实施各自的Scrum。

到了迭代结束的那天，可以在下午召开演示和回顾会议，我们一般将这两个会议放在一起召开，当然一定是先演示后回顾。

有人要问了，研发有产出可以演示和评审，测试演示什么呢？这个问题问得好。我们是有需要演示的就演示，没有就不演示。主要是对新的测试方法和技术的演示，比如某个成员采用了一种新的测试用例设计方式，那就可以让其演示下具体的设计和编写思路和做法；又比如某个成员掌握了一种新的自动化测试技术或者方法，也可以演示下整个过程，还可以让成员分享自己的经验等等。演示会增强演示者的自信心，同时团队中的其他成员得到了宝贵的经验和学习的机会。

这个会议的时间控制在一小时以内，会议时间太长了大家都有疲惫感，所以演示者在会议召开前可以适当准备下，比如制作一个简单的PPT，准备好要演示的环境等。

最后的回顾会议其实就是总结会议，对本迭代进行回顾总结，目的就是CMM中所说的最高级别持续改进：保持做得好的，改进做得不够好的。

这个会议最多半小时就足够了。可以采用给每个成员发放一张卡片，正面写出本迭代自己认为做得好的至少三个方面，反面写出本迭代自己认为做得不够好的至少三个方面。

ScrumMaster收集大家的卡片并将其在白板中列出，如果总计做得好的或者做得不够好的数量超过三个，则可以用举手投票的方式选中得票数最多的前三个，之后对做得不够好的前三个，需要大家分别讨论下解决方案，最后由ScrumMaster整理出最终的解决方案并指定解决方案的跟进负责人，这样到下个迭代开总结会议的时候再来看看上个迭代的这三项，看看究竟有无改进，长期坚持下去，必定能使团队朝着更好的方向发展起到好的作用。

在开始阶段，大家都能写出很多，但当迭代了多次后，可能大家写不出来了或者写的和以前的迭代的内容差不多，这时候可采取针对本迭代内的每个待办事项逐一进行回顾和总结，这样更具有针对性。如果大家还是实在写不出来做得不够好的，那可能说明团队确实很优秀了，那也可以往后减少甚至不用开总结会议了。

五、总结

总得来说，采用敏捷模式开展测试工作，使得每个团队成员都非常清楚自己的目标和当前工作状态，每日站会使得大家能够有效沟通并尽快得知和解决出现的问题，同时报告自己的工作进度也无形中产生了一种压力，避免了有些员工前几天比较懒散，到了最后几天才匆忙赶工的情况；报告当天的工作计划也是一种承诺，会督促团队成员尽量按时完成任务。迭代的方式使得团队成员对自己的工作有了强烈的节奏感，这种节奏感我认为对于工作效率的提升是至关重要的，因为团队成员清楚的知道自己每天应该做什么同时也知道团队中的其他成员正在做什么，大家都为同一个目标而努力，到了迭代结束的日子大家进行演示和总结，这样会促进彼此的成长和团队凝聚力，使其不断的持续改进，长期坚持下去，这样的团队必定是一个战斗力很强工作效率很高的团队。

参考文献

作者简介

北京理工大学软件工程硕士毕业，有近二十年的软件开发/测试和团队管理经验。对软件质量管理，软件测试有丰富经验，擅长Web和移动App的自动化测试和接口测试等。