我的软件测试之旅：（11）尝试——Scrum Master

　　在试点项目之后，我们投入了另一个新产品的开发，继续使用Scrum结合极限编程实践的混合式敏捷方法。不过我们从一开始就决定要采用持续集成的实践，而且100%自动化也无争议得到集体认同。当时我自己的设想是希望能够尝试Scrum中的所有三种角色，就申请担任其中一个团队的Scrum Master并且如愿以偿。51Testing软件测试网O#l9BsDg_

aWd } cc0t0　 　在第一个迭代中，两个Scrum Master有着不同的预期，我坚定地认为我们的开发应该以完成标准（Done Definition）为准，必须达到。于是，我们将完成标准打印出来，帖在每天开站会的墙上，和Sprint Backlog以及燃尽图贴在一起，每天都要检查它的满足情况。于是乎，在迭代结束的时候，我们团队完全满足了完成标准的所有要求，这也是我一直以来最自 豪的事情之一。当然，在Sprint计划会议上，我们也已经预先将不可能完成的特性（Feature）剔除出去，大家只选择了在Sprint中按照完成标 准可以完成的那些特性。51Testing软件测试网'`3^.r!TT j0B?

　　承担Scrum Master角色的同事必须同时也要在团队中担纲实际的工作任务，我也就选择了继续做测试， 两个角色各分配一半时间。不过随着产品开发进度的不断进展，有越来越多的各种闲杂事务需要Scrum Master这个角色去解决，导致我无法很好地履行团队成员这一角色的职责。团队内部连续好几个Sprint回顾会议都在讨论这个问题，试图寻找解决方 案。最后的办法是我不再承接具体的测试工作任务，以免影响其他人的工作进度，转而把时间用来辅导团队里的两位测试工作者，和他们结对工作。大概在2~3个 Sprint之后，大家提高的测试效率、质量得到了回报，因此而节省下来的时间或多或少地填补了我不干活的那0.5个人头。

　　由于产品变 得更加复杂，持续集成系统也同样更复杂，维持其运转也更不容易，还得考虑到有很多新的成员加入，他们并不熟悉持续集成实践以及实践对他们提出的要求。 Scrum Master通常也是持续集成监管团队的一员，专门监控系统状态，集成失败时就要一起分析、定位问题并且找到相应的人员解决问题，以及阻止其他人员检入代 码。这在前期尤为重要，需要帮助所有人都养成习惯，保持版本一直可工作，遇到版本失败第一反应是去修复而不是继续写代码。51Testing软件测试网2j8JJ+B4?q

eq`6~ e%}0　　还有就是实践 可接受性测试驱动开发，包括结对编程、结对测试和测试驱动开发等等实践。这些实践的推动效果很受Scrum Master担当者能力的影响，如果Scrum Master自身不具备相应的能力，只是靠空口说话很难赢得大家的信任。就算是要引入外部咨询师、教练也一样，他们需要能够花时间和团队一起干活，帮助团 队习得动手能力。言传不如身教，绝对是真义。51Testing软件测试网 ?6f\a&I+O+t/S
X

　　为了更好地培育Scrum Master，帮助大家不断提高，我们设立了Scrum Master Network实践社区，周期性地聚在一起讨论问题，分享自己的经验。和测试关系不大，就不多说了。51Testing软件测试网5O4JN+p4bvtSL&N r

`s\*[[F)p0相关链接：

%cCN4],m0s.C0我的软件测试之旅：（1）起点——作为软件开发人员

我的软件测试之旅：（2）转变——作为专职测试人员

:Dp9}-o`5}2oX0我的软件测试之旅：（3）同期——加入测试自动化小组

我的软件测试之旅：（4）并行——自动化回归测试

!s rH
\/k Q0我的软件测试之旅：（5）难点——功能改进的测试

我的软件测试之旅：（6）跳转——追逐新鲜事物的探险者51Testing软件测试网;n|#Ii$M,v

doY5CVI+cu)V0我的软件测试之旅：（7）启程——Scrum中的测试工作者51Testing软件测试网)W tfRf2Vb!Ii

我的软件测试之旅：（8）困难——没有现成的测试工具

G$whhF@_0我的软件测试之旅：（9）行动——简化测试文档和流程

l&y(p/VnQ0我的软件测试之旅：（10）贡献——开发项流程