在試點項目之后，我們投入了另一個新產品的開發，繼續使用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實踐社區，周期性地聚在一起討論問題，分享自己的經驗。和測試關系不大，就不多說了。
相關鏈接：
我的軟件測試之旅：（1）起點——作為軟件開發人員
我的軟件測試之旅：（2）轉變——作為專職測試人員
我的軟件測試之旅：（3）同期——加入測試自動化小組
我的軟件測試之旅：（4）并行——自動化回歸測試
我的軟件測試之旅：（5）難點——功能改進的測試
我的軟件測試之旅：（6）跳轉——追逐新鮮事物的探險者
我的軟件測試之旅：（7）啟程——Scrum中的測試工作者
我的軟件測試之旅：（8）困難——沒有現成的測試工具
我的軟件測試之旅：（9）行動——簡化測試文檔和流程
我的軟件測試之旅：（10）貢獻——開發項流程