專案Bug太多要不要導入Scrum？

Feb. 04 10:22~23:26

Teddy有一位朋友對Scrum很有興趣，請Teddy當面跟他介紹，講到一半的時候朋友突然說…

朋友：什麼，deadline到了如果有做不完的需求要把這些需求移到下個版本？！

Teddy：對啊，只要Product Owner隨時都有注意product backlog裡面的需求有依照優先順序排列，而且每次sprint施工所選出來的需求都是優先順序比較高的，這樣子萬一釋出時間到了還有需求沒有做完，剩下來的也是比較不重要的需求。

朋友：可是我們的專案只要需求確定之後，就不能更改耶。

Teddy：啊？！

朋友：因為我們的產品有包含硬體跟軟體，在產品規格（需求）確認之前，行銷、業務、技術人員會先密集討論，但是一旦產品規格確定之後，接下來的開發時程就要依據專案經理拉出來的schedule來執行。規劃的上市時間到了產品就要釋出，而且規格與功能都不能縮水。

Teddy：請問你們的產品規格確認之後，需求會一直改變嗎？

朋友：幾乎不會。

Teddy：那開發過程中，所使用的技術會一直改變嗎？

朋友：也不會耶。

Teddy：那你幹嘛想改用Scrum？

朋友：因為我們的產品bug很多，導入Scrum不是會讓產品品質變好？

***

Teddy在《四種專案複雜度》介紹過一個觀念：「不同類型的專案，需要用不同的開發流程與管理方式」。Teddy這位朋友的專案，比較像是「簡單型專案（Simple）」，也許只要繼續沿用waterfall的專案管理與開發流程應該就可以了。也就是說，朋友真正最痛的問題，是bug太多，專案品質不佳。這個問題的解應該從軟體工程面或是導入實務做法著手，例如：

• Code Review
• 單元測試
• 自動化功能測試
• Pair Programming
• 持續整合
• 提升開發人員的設計能力，讓軟體更容易擴充與測試（請參考《讓軟體變軟的兩個原則》）
• 提供更多的測試設備
• 請參考《600 多個 bugs 要怎麼修？》

當然，專案bug很多非常有可能是「不合理的時程」所造成的結果。傳統「計畫驅動」的專案，在「固定產品功能（所有計畫中的功能，一定要全部做完產品才可上市）」的前提下，時程不准延後，開發成本又不能增加（開發人力有限），那怎麼辦？

除了加班以外，工程師還有另外一項法寶，那就是「降低產品品質」。如果鄉民們一定要堅持自己的專案要採用上圖左方的「計畫驅動」管理方式，又希望產品能夠有不錯的品質。在時程固定的前提之下（上市時間不可延後），只有想辦法找到「高品質的開發人力」，或是提升現有開發人員的能力（也就是增加開發成本）。

如果只是因為bug太多這個原因而希望藉由導入Scrum來解決，但卻不想也不需要改變原本waterfall的專案開發模式，導入Scrum就不是合適的藥方。

***

友藏內心獨白：Scrum不是萬靈丹，無法治百病啊。