一面什麼鏡子
前些日子寫過一篇《一面鏡子的使命》。在文章裡，我倡議ScrumMaster應該把自己看作平整、乾淨的“平面鏡”。看待問題有景深，面對問題要全面。而不要去做帶有主觀偏見的“哈哈鏡”，也不要去做違心奉承的“魔鏡”。
文章反響不錯，有很多人同意這個觀點 。我很欣慰，也很感謝大家的支援。但我覺得有個角度還沒有覆蓋到。所以今天再來補充一下，貌似有點自我迭代的意思。
正如標題上說的，“你只是一面鏡子”。而鏡子是無法代替行為的。就好比一個人在鏡子裡發現自己上火了，他可以立刻用厚厚的粉底將其掩蓋；他可以決定今晚不吃火鍋了；他也可以忽視這個問題，什麼都不做。而鏡子傳遞“你上火了”這條資訊的使命後，也就沒它什麼事兒了。
在敏捷開發對於角色的定義來說，ScrumMaster不負責開發和需求制定。
如果ScrumMaster無法得到團隊的信任，他對於問題的洞察無法得到團隊的支援，那麼很多改善就無法落地。
（他擼起袖子自己乾的情況除外）
來看這麼一個場景
某個團隊在專案早期做自動化釋出策略時承諾，使用者測試環境（UAT）和生產環境（PRD）的配置是完全一致的。所以在成功釋出UAT之後再發布PRD是一定不會出問題的。
生產環境釋出當天，在過往一週多次釋出UAT成功的前提下，釋出PRD失敗了。得利於強大的團隊，在幾個小時的排查後，最終趕在期限前半小時成功釋出PRD。
排查過程中，團隊發現的問題如下：
UAT環境上某個服務的版本，和PRD環境上同服務的版本不一致
用來發布UAT環境，和用來發布PRD環境的使用者賬號許可權不一致
事後，ScrumMaster表達了自己看到團隊體現出過硬的能力。另外也提出了一個問題：如何能確保之前說的那樣，在成功釋出UAT之後再發布PRD是一定不會出問題的？因為只有確保這樣，團隊才有信心在以後進行頻繁的釋出。
對於這位鏡面ScrumMaster所體察到的問題，團隊會如何響應呢？
響應一：
很快從成功救場的興奮中冷靜下來，開始回顧在排查中發現的問題。一位對於釋出全過程很熟悉的DevOps工程師趁熱打鐵，草擬了一份釋出準備項清單。由全隊幫他補充。更讓人興奮的是，出於對“UAT和PRD的配置應該是完全一致”的追求，有人提出了取消UAT的設想，並且開始梳理和討論可行性。
當然還可能有
第二種響應：
這很正常的，在以往的專案中都有類似的情況
我們都不是很有經驗的DBA，沒辦法提前預見這些情況的 發生。即便是DBA，也可能無法提前預見的
絕對不可以沒有UAT！！！
問題不是解決了嘛。我們玩的是敏捷，就應該見招拆招
第一種情況裡，ScrumMaster的價值透過團隊得到體現。團隊認可他的存在，正面他觀察到的問題。團隊作為一個整體在逐步改善。第二種情況裡，團隊沒有重視ScrumMaster觀察到的問題，甚至可以說有意在迴避。就好像前面提到那個上火的人在鏡中看到自己時，感覺鏡子會“批判”自己一樣，找著各式各樣自己上火的理由。更糟糕的情況可能是，有的因為不願意看照鏡子，從而擱置或毀壞無辜的鏡子。
到這有人可能會說，Scrum Master是個很考驗軟技能的角色。對於如何表達來贏得他人認同，並積極引導（Coaching）他人採取行動，這本來就是ScrumMaster的職責。
是的，我認可Coaching技巧的重要性，或許我會在另外一篇文章裡分享一二。但在這，我們不能用“想救人就得就救全世界”的道德綁架來偷換概念。有些人不會被改變，或者改變他的成本很高。而ScrumMaster不是孔聖人，不是傳教士。他是站在第三人視角反應實際情況的。他只是一面鏡子。而鏡子不是所有人都能用得出價值的。
YY一下，實在被逼急了，或許可以變身貞子從鏡子裡爬出來
作者：尤承亮 CSP