定時檢視目前的進度與問題,是所有專案管理都會做的事情。Scrum方法會在每個Sprint之後,舉行檢討會議(驗屍會議),找到在過去一段時間最需要改善的事項。
假設團隊依照正確的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是否要合併。這個做法的依據在於,通常會修改的規格,都會被一改再改,與其影響團隊作業,不如將影響範圍降到最低。
--- 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