在试点项目之后，我们投入了另一个新产品的开发，继续使用Scrum结合极限编程实践的混合式敏捷方法。不过我们从一开始决定要采用持续集成的实践，而且自动化也无争议得到集体认同。当时我自己的设想是希望能够尝试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实践社区，周期性地聚在一起讨论问题，分享自己的经验。和测试关系不大，不多说了。