在試點項目之后，我們投入了另一個新產(chǎn)品的開發(fā)，繼續(xù)使用Scrum結(jié)合極限編程實踐的混合式敏捷方法。不過我們從一開始就決定要采用持續(xù)集成的實踐，而且100%自動化也無爭議得到集體認同。當時我自己的設(shè)想是希望能夠嘗試Scrum中的所有三種角色，就申請擔任其中一個團隊的Scrum Master并且如愿以償。
在第一個迭代中，兩個Scrum Master有著不同的預(yù)期，我堅定地認為我們的開發(fā)應(yīng)該以完成標準（Done Definition）為準，必須達到。于是，我們將完成標準打印出來，帖在每天開站會的墻上，和Sprint Backlog以及燃盡圖貼在一起，每天都要檢查它的滿足情況。于是乎，在迭代結(jié)束的時候，我們團隊完全滿足了完成標準的所有要求，這也是我一直以來最自豪的事情之一。當然，在Sprint計劃會議上，我們也已經(jīng)預(yù)先將不可能完成的特性（Feature）剔除出去，大家只選擇了在Sprint中按照完成標準可以完成的那些特性。
承擔Scrum Master角色的同事必須同時也要在團隊中擔綱實際的工作任務(wù)，我也就選擇了繼續(xù)做測試，兩個角色各分配一半時間。不過隨著產(chǎn)品開發(fā)進度的不斷進展，有越來越多的各種閑雜事務(wù)需要Scrum Master這個角色去解決，導致我無法很好地履行團隊成員這一角色的職責。團隊內(nèi)部連續(xù)好幾個Sprint回顧會議都在討論這個問題，試圖尋找解決方案。最后的辦法是我不再承接具體的測試工作任務(wù)，以免影響其他人的工作進度，轉(zhuǎn)而把時間用來輔導團隊里的兩位測試工作者，和他們結(jié)對工作。大概在2~3個Sprint之后，大家提高的測試效率、質(zhì)量得到了回報，因此而節(jié)省下來的時間或多或少地填補了我不干活的那0.5個人頭。
由于產(chǎn)品變得更加復(fù)雜，持續(xù)集成系統(tǒng)也同樣更復(fù)雜，維持其運轉(zhuǎn)也更不容易，還得考慮到有很多新的成員加入，他們并不熟悉持續(xù)集成實踐以及實踐對他們提出的要求。Scrum Master通常也是持續(xù)集成監(jiān)管團隊的一員，專門監(jiān)控系統(tǒng)狀態(tài)，集成失敗時就要一起分析、定位問題并且找到相應(yīng)的人員解決問題，以及阻止其他人員檢入代碼。這在前期尤為重要，需要幫助所有人都養(yǎng)成習慣，保持版本一直可工作，遇到版本失敗第一反應(yīng)是去修復(fù)而不是繼續(xù)寫代碼。
還有就是實踐可接受性測試驅(qū)動開發(fā)，包括結(jié)對編程、結(jié)對測試和測試驅(qū)動開發(fā)等等實踐。這些實踐的推動效果很受Scrum Master擔當者能力的影響，如果Scrum Master自身不具備相應(yīng)的能力，只是靠空口說話很難贏得大家的信任。就算是要引入外部咨詢師、教練也一樣，他們需要能夠花時間和團隊一起干活，幫助團隊習得動手能力。言傳不如身教，絕對是真義。
為了更好地培育Scrum Master，幫助大家不斷提高，我們設(shè)立了Scrum Master Network實踐社區(qū)，周期性地聚在一起討論問題，分享自己的經(jīng)驗。和測試關(guān)系不大，就不多說了。
相關(guān)鏈接：
我的軟件測試之旅：（1）起點——作為軟件開發(fā)人員
我的軟件測試之旅：（2）轉(zhuǎn)變——作為專職測試人員
我的軟件測試之旅：（3）同期——加入測試自動化小組
我的軟件測試之旅：（4）并行——自動化回歸測試
我的軟件測試之旅：（5）難點——功能改進的測試
我的軟件測試之旅：（6）跳轉(zhuǎn)——追逐新鮮事物的探險者
我的軟件測試之旅：（7）啟程——Scrum中的測試工作者
我的軟件測試之旅：（8）困難——沒有現(xiàn)成的測試工具
我的軟件測試之旅：（9）行動——簡化測試文檔和流程
我的軟件測試之旅：（10）貢獻——開發(fā)項流程