定時檢視目前的進度與問題，是所有專案管理都會做的事情。Scrum方法會在每個Sprint之後，舉行檢討會議(驗屍會議)，找到在過去一段時間最需要改善的事項。
請參考前篇：Scrum - 回顧。檢討？驗屍！
假設團隊依照正確的Scrum的事實認定原則，踏實的列出問題。接下來就應該「解決」它。誠如前篇，所有的問題必須要有歸屬「某人」。某些事情是「很多人」或者「不知道什麼人」，這種情況的歸屬就屬於Scrum Master。
稍微強調一下，只要Scrum Master稍微不注意，就會讓歸屬人這件事情變成互相指責，試圖鞭屍，對人不對事的謾罵。但是，如果不試圖歸屬某人，就常會讓問題懸空，無法真正解決。
只要確切的定義真正的問題，就等於是產生了一半的解決方法。
不過有些常見老問題，還是值得探索一下。
例如：
(1) PM/PO 常常在Sprint中間要求修改規格，甚至新增額外的項目...
(2) 某個人的產出和績效，明顯的比其他人差很多...
(3) 某個功能的實際時程遠超過預估，以至於某些團隊成員需要很大幅度的加班...
而常見問題都有其共通性，常見的試圖解決方法也有共通性。然而，以Scrum而言，Scrum Master在此扮演非常重要的角色，因為所有的問題，其有效解決方式，應該都和Scrum Master本身有關。
Scrum Master必須要掌握以下原則：
原則一：試圖做到完美是不可能
完美的team不可能存在，每次sprint應該試圖解決最重要的幾個問題就好。
原則二：持續做同樣的事情，不可能產生一樣的結果
參考愛因斯坦的名言：Insanity: doing the same thing over and over again and expecting different results.
原則三：任何創意方式都應該嘗試：包括「無作為」
當定義好問題之後，下一個sprint應該要試圖改善問題。但是，改善問題的本身有時候需要「時間」，而由於Scrum每個sprint都只有4週，Scrum Master應該要將「無作為」當作某些問題的處理選項。畢竟，有時候過度反應某個未來可能不存在的問題，也沒太大意義。
但是也請謹慎區分「無作為」和「逃避」，這兩者只有一線之隔(註1)。
針對身為Scrum Master的人，在此提供一些解決問題的範例：
(1) 時間相關的問題
由於時間是軟體專案衡量進度的唯一單位。時間是最初，也是最後要考慮的事情。因此許多檢討事項都和「時間」有莫大關係。
--- 在Sprint中某些時間估計錯誤，導致加班 ---
這在專案前幾的sprint特別常發生。建議解決方式有：
(a) 探詢真正的需求點和重要的事情，移除根本不重要的工作事項
(b) 減低時間浪費，特別是大型專案中開會的時間
(c) 無作為：因為團隊已經了解問題，而且下個sprint估算也應該會比較正確，加班問題很可能自然消失。
(d) 厲行「最大時間」單位，假設是1天。換言之，工作項目超過1天，就需要分拆成不同的項目，或者不同的完成階段。這樣可以在比較短的時間內，很快發覺時間錯估的規模。
絕對不建議解決的方式是：讓某些人繼續加班；犧牲品質；謊報進度...
--- 某個人的事情老是做不完 ---
這個也很常發生。如果是該員能力無法趕上團隊。似乎是個很大的問題。然而，絕大部分的團隊都應該利用分工導致的比較利益法則（參考這篇），根據相對優勢來分工。
細節請參見下一節：(2)人才和人力的問題
建議解決方式有：
(a) 先確定他不是不想做。假設有個不想在這個團隊努力的人，無論再怎麼調整，也都沒有意義。應該用最快的方式讓他好好離開。
(b) 讓他做可以用時間苦勞換取績效的工作，而非需要能力才拿達成的工作 ，例如將其人力保留用於意外任務或者PM臨時修改需求
(c) 找到他的相對優勢，換言之，Scrum Master要略為調整scrum的精神，改以指派的方式指定工作。但這點需要觀察並且徹底了解他的優勢才有辦法執行。
--- 團隊有意外任務 ---
這個問題也很常見，可能的解決方式有(a) 無作為：經過一番思考，發現這只是意外，下個sprint應該不會發生
(b) 根據前sprint所耗在意外任務的時間，重新估計下個Sprint意外任務要花的時間
(c) 設定意外任務防火牆：可以找一個專門的人，處理所有意外任務。不得已的時候也可以找工讀生，委外人員等等。
(2) 人才與人力的問題
許多軟體開發的相關研究，都一再顯示，一個好的設計師和普通的程式設計師的績效相差很大。某些1980-1990之間的研究認為可能差距10倍，當然這個10倍厲害的程式設計師的爭論很多(註2)。但就一般的情況來說，超過5個人的團隊，就自然而言有人能力以及產出比較好，而有可能有某人能力和產出都比較差。
一個團隊裡，人力和人才必須要平衡，並且由Scrum Master在前幾個sprint的結果瞭解哪些是人力，哪些是人才。人力和人才的衡量標準在於「產出」而不在於「個人能力」。換言之，即便大家都認為他能力很好，但是某些原因，他的產出只有一般般，那麼他就不是人才，而是人力。
但是，無論是人才還是人力，團隊的組合的先決條件就是1+1>2，團隊合作可以讓整個團隊獲利。Scrum Master在發現團隊有某些人的績效和產出問題時，應該優先考慮分配工作上的比較利益法則。（台灣經濟學的入門書通常會用蓋木屋與磚屋的例子：參見這裡）
要注意的是，過於追求表面上的公平，但是反而會團隊績效的降低。公平雖然重要，但是團隊合作產生的獲利更為重要。Scrum Master要能讓團隊追求團隊目標，而非追求個人公平。其方法有：
(a) 讓團隊成員看這篇文章
(b) 不要設定表面的績效衡量標準(例如：bug數量) 而是設定每個人不同的標準
(c) 所有不同的標準，朝向同一個目標。例如，在籃球比賽中，得分籃板助攻失誤阻攻...等等都是指標，而所有指標必須都要朝向球隊勝利才有意義。而不應該對每個球員設定同樣的目標。
(3) 目標的問題
目標指的是現在要做什麼，現在什麼事最重要，要達到什麼效果...簡單的說，每個專案都有其最終目標，但是在專案開發過程中，都有中間目標，PM/PO理論上應該會透過各類型中間的目標，達到（也有可能會修正）最後的目標。
然而，Scrum為了讓開發人員專注於工作，在一段短時間的Sprint是不允許修改目標。因此，如果遇到PM中間亂入，常常會造成團隊困擾。
但其實更為重要的是，如果團隊方向具有很大的不確定性，Scrum Master應該視其為「機會」，而非「威脅」。因為Scrum的天生優勢就是在於處理不確定性。
--- PM客戶或其他長官常常突然要求修改做的一半的規格---
(a) 無作為：因為這可能是專案開始的意外插曲，Scrum Master很確定下個sprint不會發生
(b) Scrum Master作為擋箭牌。在Sprint中間過程，用盡一切手腕，擋住所有需求修改，直到sprint結束為止。但是，允許PM重新開始一個sprint。
(c) 找個專門窗口作為擋箭牌。指定一個專門「被聯繫」的擋箭牌，將擋下需求，或者臨時修改需求這件事情是為他的工作項目。但是他所完成的程式碼，放在另一個branch(分支中)，每個sprint結束之後，才檢討他的branch是否要合併。這個做法的依據在於，通常會修改的規格，都會被一改再改，與其影響團隊作業，不如將影響範圍降到最低。
這樣的抱怨也很常見，它不是問題，而是Scrum天生所展示的優勢。Scrum Master只要解釋幾點Scrum基本概念即可：
(a) 我們頂多白做4個禮拜，如果是project結束才發現這件事情？那浪費的成本是高得嚇人。
(b) 如果是PM不喜歡，那麼起碼我們會了解什麼地方他不喜歡。如果他「不要了」表示這是PM在產品需求判斷上的錯誤，在檢討會議應該要求PM改善此項目。
如果有其他常見問題在這裡沒有獲得解答？也請用email與我們聯繫 support@talent-service.com。我們會持續修改這篇文章。
(b) Scrum Master作為擋箭牌。在Sprint中間過程，用盡一切手腕，擋住所有需求修改，直到sprint結束為止。但是，允許PM重新開始一個sprint。
(c) 找個專門窗口作為擋箭牌。指定一個專門「被聯繫」的擋箭牌，將擋下需求，或者臨時修改需求這件事情是為他的工作項目。但是他所完成的程式碼，放在另一個branch(分支中)，每個sprint結束之後，才檢討他的branch是否要合併。這個做法的依據在於，通常會修改的規格，都會被一改再改，與其影響團隊作業，不如將影響範圍降到最低。
--- Sprint產出PM不喜歡或不要了 那我們不是白做 ---
這樣的抱怨也很常見，它不是問題，而是Scrum天生所展示的優勢。Scrum Master只要解釋幾點Scrum基本概念即可：
(a) 我們頂多白做4個禮拜，如果是project結束才發現這件事情？那浪費的成本是高得嚇人。
(b) 如果是PM不喜歡，那麼起碼我們會了解什麼地方他不喜歡。如果他「不要了」表示這是PM在產品需求判斷上的錯誤，在檢討會議應該要求PM改善此項目。
如果有其他常見問題在這裡沒有獲得解答？也請用email與我們聯繫 support@talent-service.com。我們會持續修改這篇文章。
註1：許多事情好與壞都只有一抹微妙的界線。除了「無作為」和「逃避」之外，還有「足夠自信」vs 「自我感覺良好」；「自卑」vs「謙虛」...
註2：請參見這裡
註3：如果有其他常見問題在這裡沒有獲得解答？也請用email與我們聯繫 support@talent-service.com
沒有留言:
張貼留言