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

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

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

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

还有就是实践可接受性测试驱动开发,包括结对编程、结对测试和测试驱动开发等等实践。这些实践的推动效果很受Scrum Master担当者能力的影响,如果Scrum Master自身不具备相应的能力,只是靠空口说话很难赢得大家的信任。就算是要引入外部咨询师、教练也一样,他们需要能够花时间和团队一起干活,帮助团队习得动手能力。言传不如身教,绝对是真义。

为了更好地培育Scrum Master,帮助大家不断提高,我们设立了Scrum Master Network实践社区,周期性地聚在一起讨论问题,分享自己的经验。和测试关系不大,就不多说了。

已经有将近两年的实践经验后,我参加Bas Vodde的诺西内训,于2007年7月7日成为了有证的CSM(Certified Scrum Master)。

enter image description here

查看更多“我的测试之旅”文章
1. 起点——作为软件开发人员
2. 转变——作为专职测试人员
3. 同期——加入测试自动化小组
4. 并行——自动化回归测试
5. 难点——功能改进的测试
6. 跳转——追逐新鲜事物的探险者
7. 启程——Scrum中的测试工作者
8. 困难——没有现成的测试工具
9. 行动——简化测试文档和流程
10. 贡献——开发项流程(Development Item Process)
11. 尝试——Scrum Master
12. 机遇——测试自动化培训师和教练
13. 转型——敏捷教练

敬请关注 《大测大悟——测试的敏捷之道》开放出版过程

联系方式:
- 新浪微博
- 谷歌邮箱 kaverjody @gmail.com
- LinkedIn