Scrum 是什麼（17）：Story寫得好才容易估算(下)

March 20 18:30~19:10

前情題要：

• 〈Scrum 是什麼（1）：雙重回饋機制〉
• 〈Scrum 是什麼（2）：Scrum 的內涵〉
• 〈Scrum 是什麼（3）：三種補充文件〉
• 〈Scrum 是什麼（4）：Product Backlog〉
• 〈Scrum 是什麼（5）：初探 Sprint Planning Meeting〉
• 〈Scrum 是什麼（6）：Sprint Planning Meeting 眉角〉
• 〈Scrum 是什麼（7）：Daily Scrum〉
• 〈Scrum 是什麼（8）：Sprint Review Meeting〉
• 〈Scrum 是什麼（9）：Retrospective Meeting〉
• 〈Scrum 是什麼（10）：時程估算〉
• 〈Scrum 是什麼（11）：不信邪之流程改善精神〉
• 〈Scrum 是什麼（12）：不要再用focus factor與unplanned items了〉
• 〈Scrum 是什麼（13）：為什麼不建議使用focus factor？〉
• 〈Scrum 是什麼（14）：好問題〉
• 〈Scrum 是什麼（15）：誰適合當Scrum Master？〉
• 〈Scrum 是什麼（16）：Story寫得好才容易估算(上)〉

 

上一集提到用「第一種信用卡付款方式」與「第二種信用卡付款方式」這種方法來撰寫相依性story的方法，此外還有一種可能的解決方式，就是根本不要事先估算全部user story的story point（不要沒事先去估算product backlog裡面每一個user story的story point），這樣就根本不會遇到上一集所提到的煩人問題。為什麼？

假設Product Owner採用在上一集中所提到的第二種寫法把信用卡付款的user story拆成兩個小user story：

• 身為使用者，我可以使用Visa信用卡付款。
• 身為使用者，我可以使用Master信用卡付款。

在product backlog中這兩個story都還沒有被估算story point。假設在專案進行到第N個sprint的時候，Product Owner挑選了「使用Master信用卡付款」這個user story準備交給開發人員實作。在sprint planning meeting時，開發人員估算這個user story的story point為13。在N+1的sprint時，Product Owner又挑了「使用Visa信用卡付款」這個user story。由於之前開發人員已經實做過「使用Master信用卡付款」這個story，因此開發人員發現剩下的這個「使用Visa信用卡付款」user story只需要5點便可完成（感覺起來比之前估得更準）。

傳統軟體開發方法要求開發人員做一大堆有的沒的估算，但是很遺憾的很多估算都是錯誤的。估錯也就算了，偏偏很多專案經理或是老闆卻喜歡在這個錯誤的基礎下進行很多不合理的要求。如果不合理的要求能夠讓專案成功也就算了，偏偏專案卻又是不斷的延遲，產品品質也不好。因此有一派的敏捷式軟體開發人士認為，「做決定（估算也是一種決定）」這件事情，最好能拖就拖，在非不得已的情況下，不要太早做決定。道理很簡單，因為隨著專案進行，團隊所獲得的資訊越來越多，因此「理想上」越晚做決定，則決定的品質會越好。至於相不相信這套 歪理 理論，民眾心中自有公評…XD。

最後請鄉民們回答以下三個問題：

• 請問昨天天氣如何？
• 請問今天天氣如何？
• 請問三個月後天氣如何？

如果可以只問「明天天氣（只估算這個sprint預計要完成的user story）」就可以把專案做好，為什麼還要浪費時間去猜測「三個月後的天氣」呢？把時間省下來準時下班回家抱老婆小孩、陪女友吃飯、做家事、看書、甚至是玩遊戲、看海綿寶寶或是烏龍派出所都要來的有意義。

***

下一集：〈Scrum 是什麼（18）：到底為什麼要估算Story Point哩？〉

***

友藏內心獨白：把時間浪費在美好的事物上，不要浪費在沒意義的猜測上…XD。