Scrum FAQ (4)

August 22 21:00~22:40

今天繼續昨天的議題，回答上禮拜上Scrum第三梯次課程由學員們所提出來的問題。

問題六：Scrum Master和Product Owner可以是同一個人嗎？

Teddy：「理論上不行」，因為這兩者的責任在許多地方是互相衝突的。PO通常會希望團隊在每一個sprint當中，完成越多的story越好。PO基本上不管團隊用什麼方式開發軟體，反正在單位時間之內能夠完成越多的功能就越好。Scrum Master則需要觀照全局，必須協助團隊持續改善開發流程與技術能力。而這些改善的工作，很有可能是短時間看不到立即的功效，因此PO不一定會願意將這些改善的需求排入優先的施工對象。

當Scrum Master和PO變成同一人時，如果Scrum Master是技術人員背景，那麼很可能發生「重改善而輕功能」的問題，把很多時間花在為改善而改善上面。反之，如果Scrum Master是非技術人員出身，則可能會排斥所有的改善工作，把全部的時間都拿來開發功能，而導致「重功能而輕改善」。

結論就是，「逆練 英九 九陰真經」，要自己小心一點，注意不要走火入魔了。

問題七：Bug fix 的story要如何估算點數？

Teddy：這個問題很好，簡單地說，就是「用猜的」。基本上，bug可以分成三種：

1. 修改方法很明確的bug：這種bug最簡單，只要花時間就可以改好。例如，網頁打錯字、修改CSS、欄位檢查邏輯錯誤等。
2. 大致知道問題可能會出在哪裡的bug：從回報bug的敘述中，團隊「大致上」可以猜到bug發生的原因，但是對於要花多少時間才可改好比較沒有把握。
3. 完全沒有頭緒的bug：只知道在某種狀況下系統會發生錯誤，但是可能還沒辦法重複發生錯誤的步驟，也不是很清楚錯誤發生的原因，更不知道要如何排除錯誤。

Teddy通常會把好幾個bug集中在一個bug fix的story裡面去修復，而這些集中在一起修復的bug，最好是有80%左右是屬於上述第一種或是第二種bug，而20%左右是屬於第三種bug。然後，心理先預估一下，看看這些佔80%的bug（第一種與第二種）和其他story相比，大概需要多少story point。假設是5個story point好了。藉著再看看剩下的20%第三種的bug，如果整個bug fix的story point變成8，對於修復剩下第三種bug的信心如何？舉例而言，如果大家的信心只有30%，那就把story point再往上跳一級，變成13，此時如果大家的信心可以提高到70%~80%左右，那就差不多可以了，就用這個數字當作這個story的story point。看到這裡鄉民們可能會問，那為什麼不在往上跳一級，用20個story point？這樣信心指數可能會到95%啊？這也是一種方法，團隊可以依據大家投票的結果，取得一個大家認為可以接受的大小。重點是，決定之後就去做，做了之後再依據實際狀況，作為下次修正的參考。

問題八：內部討論API的文件，是否需要紀錄。

Teddy：類似的問題（敏捷方法是否需要寫文件）上一集回答過了。如果是Teddy，應該會直接把文件寫在API上面（寫在code裡面），而不會特意寫一份文件（例如Word文件），來敘述API的介面與使用方法。

問題九：Sprint planning meeting part 1在估算story point時，因為尚未切割task（尚不清楚施工項目），所以此階段所估算的story point是不是很不準？

Teddy：通常來講應該不會。在Part 1 雖然沒有切割task，但是團隊在討論與出牌過程中，其實在心裡面已經把如何完成這個story的方法「綜合演練」過一次了。如果大家的想法差異很大（所謂的很不準），那麼在出牌的時候自然會顯示這樣的差異，然後再引發另外一輪的討論，逐漸把這個差異給縮小。當然也可能會發生，在part 2切割task的時候，才想到剛剛有一些因素忘了考慮，而影響了story的估算。這也沒關係，就重估story的story point就好了。

問題十：團隊的工作是由Product Owner還是Scrum Master來分配？

Teddy：都不是，工作是團隊成員自己認領的。Scrum Master在「必要的時候」可以「提醒」團隊成員工作施工的順序是否有依據story的優先順序來施工。當團隊成員不知道要認領什麼工作來做的時候，Scrum Master也可以「建議」可能可以認領的工作。總之，工作絕對不是由Scrum Master或是PO指派的。

***

剛剛看新聞，明天照常上班、上課。要繼續去修訂這週末要上課的design pattern教材。

***

友藏內心獨白：颱風趕快走啦。