Scrum 答客問 (三)

May 5 21:57~22:52

 

今天來回答上禮拜六、日（5/3、5/4）Scrum課程學員提出的幾個問題：

Q1：軟體架構設計算是quality story還是technical story？

Teddy：先澄清一個觀念，雖然在課堂上Teddy介紹了user story、quality story、technical story和bug fix這四種常見的product backlog item（PBI），但這並不是鼓勵團隊將所有的「技術問題」或是「設計問題」變身為quality story或是technical story。在product backlog裡面，絕大部分的項目應該都是user story，也就是對使用者有直接價值的需求。

Teddy：軟體架構設計，以及大部分的技術問題，在敏捷專案中，「最理想」的情況是跟隨著user story的完成而逐步成形，並沒有一個專門的時段或是特定的story來做架構設計。如果團隊在剛開始的時候還無法做到「軟體架構逐步成長」，而且非常擔心直接實作story會導致非常混亂的局面，則可以考慮在專案開始前先跑個iteration 0做點初步的架構設計。請參考〈Iteration 0 要幹麼？〉、〈萬事起頭難：如何開始第一個 Sprint？〉。

Q2：在寫user story的時候要暴露多少實作細節？

Teddy：User story談的是what，是使用者的需求，不是實作（how），所以不用暴露實作細節。

Q3：運行Scrum總是會有很多內部的反彈，牽扯到人的變動與利益，該怎麼導入比較好？

Teddy：這是個很大、很難的問題，任何變革對於組織來講都是不容易的（請參考〈牛頓第一運動定律〉）。如果能得到高層支持那當然是最好，否則請參考〈史記和導入Scrum〉以及〈都市游擊隊〉。

Q4：在sprint planning meeting的時候，團隊成員想得越多，時間拉太長，該怎麼控制？

Teddy：sprint planning meeting活動是一個4~8小時的time-box，時間到了活動就結束，不可以延到隔天再繼續開會。習慣這個步調之後，團隊成員自然會在有限的時間內把會議開完。

Q5：Product backlog item是否全部都要預先估算它們的大小？

Teddy：不一定，如果你要做release plan，則至少下次release之前所包含的product backlog item需要全部估算。如果你不需要做release plan，只需要在sprint planning meeting的時候再將本次sprint準備完成的product backlog item帶到會議中估算即可。如果你有辦法把每個product backlog item都切成一樣大，那你也不用估算了，如果要預估團隊生產力或是做release plan，只需要算product backlog item的個數就好了。

***

友藏內心獨白：Scrum很簡單，但卻很難。