阻礙的排除

Sep. 30 11:00~13:15

 

昨天提到〈阻礙的定義〉，今天繼續這個主題，談一下如何排除阻礙。《Scrum Shortcuts》書中談到排除阻礙的五個步驟：

• 確認：第一步當然是要先確定什麼事情是「阻礙」。在Scrum框架中，Daily Scrum是回報阻礙最典型的活動。因為每天都會舉辦一次，而且「有沒有遇到任何阻礙」原本就是Daily Scrum要回答的問題之一。不過，如果團隊成員有任何問題，尤其是急迫性的問題，可以隨時反應，不用等到Daily Scrum。另一個合適的活動就是retrospective，可以比較深入的挖掘影響團隊前進的阻礙。
• 分類：阻礙的數量通常很多，尤其在新的Scrum團隊中更是如此。人的能力有限，不可能一次處理太多數量的阻礙，也就是說不可能一次改善太多事項。因此，確認有哪些阻礙之後，將其分類，大概每次挑個1~2項最嚴重或緊急的阻礙來處理就已經很了不起了。
• 移除：分類之後接著就是要把想辦法殲滅首要敵人（阻礙）。排除的方式可以依據阻礙是屬於「內部」還是「外部」來著手。
• 內部阻礙，像是建構失敗（broken build），可以藉由加強團隊成員的訓練，或是流程改善來達成。例如，確認開發人員在提交程式碼之前有先在本地端電腦上先跑過所有的測試案例，或是程式碼必須經由其他開發人員檢視（review）之後才可以進入板控系統。
• 外部阻礙，例如公司文化、規定，或是與客戶、協力廠商的合作，通常無法由開發人員來排除。此時由ScrumMaster來擔任阻礙排除負責人，藉由管理者以集其他內部、外部資源的協助，共同來排除阻礙。
• 概述：當阻礙出現的時候，團隊與相關人等都應該要知道這個狀況。無論是採用視覺化的方式，或是電子化的方式，ScrumMaster要讓阻礙的存在變的透明，以提高大家的危機意識。
• 學習：在retrospective場合中，團隊分析與檢討排除阻礙的經驗，並討論如何避免相同的阻礙再次發生，或是如果無法避免再次發生，如何讓它對於團隊的殺傷力減到最低。

***

最後再介紹一個觀念，阻礙（impediment）與阻塞（block）的差別。有時候這兩個字會被當成同意字交互使用，實際上block只會妨礙單一工作（task）的進行，而impediment則是妨礙整個團隊的進行，所以層次不太一樣。

Block通常發生在工作具有相依性的時候，例如購買的測試機器還沒到貨，所以測試的工作被卡住了。或是與其他團隊共用的DBA（資料庫管理師）目前沒空，所以最佳化資料庫的工作被卡住了。這種狀況只要工作都被顯是在工作看板（task board）上，就可以很容易的被管理。例如，可以貼一張粉紅色的標籤在被阻塞的工作上面，一天沒被排除，就在粉紅色標籤上面點一點，做個記號，用來標示阻塞時間的長短。

***

排除阻礙與阻塞都是ScrumMaster的重要任務，做的好團隊可以順利的前進，做不好團隊走走停停，就好像紅綠燈不連鎖一樣，路程再短也快不起來。

***

友藏內心獨白：關注阻礙與阻塞的工作而非關注閒置的人。