為什麼 Scrum 害你們產能下降、品質低落、時程 delay？

2019-01-15

Scrum 真是害人不淺的東西，只是包裝很美好的「商業詞彙」罷了。

我們原本沒那麼多問題，在用了 Scrum 之後問題很多，當我們改回原本的開發方式之後，問題就瞬間又減少了。

前情提要

忘了多久之前，我在 Facebook Scrum Community in Taiwan 社團中，曾經講過一句話。

跑 scrum 如果沒有自動化測試的保護，最終一定死路一條。

當時也有引起某些朋友的反駁，認為只要開發人員功力強，架構規劃得當，就不會有 bug，沒自動化測試也死不了人。

當時忙，也不想跟人家吵，就懶得詳細說明。

不過剛剛剛好又被 cue 到一次相關的話題，懷抱著有被 cue 到就是種證明專業價值的機會，也是種挑戰，索性就順手把圖也畫出來說明，為什麼我會那樣說。

其實我那句話，針對的不只是 scrum，而是任何頻率高、週期短的短迭代產品增量交付，在沒有自動化回歸測試的保護下，最終會因為手動測試的範圍與成本越來越大，而拖慢交付速度，或是品質開始低落。

通常你的測試人員或測試任務開始成為瓶頸點時，就是在突顯這問題。

從上面那張圖可以看到，一般來說開發團隊的開發能量，長期平均來看是穩定的。

如果每個 sprint 都能交付 10 個 story point 的產品功能，那最一開始的測試範圍，也就是這 10 個 story point 的功能範圍。這時 effort 還是 1:1。

第二個迭代，開發團隊理想狀態下，仍然交付 10 個 story point 的 feature。但，測試的範圍呢？

你不能只測試功能增量的部份啊，產品是整體的，得確保整個產品品質與功能沒問題。

所以，最差的情況下，手動測試的 effort 是兩個迭代的功能總產出，也就是 10 + 10 = 20，這時比例是 1:2。

恩...所以四個迭代之後就是 1:10 了。第五個迭代，1:15，第六個迭代，1:21。

這樣下去，產品跟團隊能撐多久？

除非這個產品功能很少，要不然就是沒人用，所以沒人反應品質問題。

到最後，大家就把問題都怪罪到【敏捷/Scrum 是個理想化、不落地的商業詞彙】，因為他們在用 scrum 之前，沒有這問題啊！

過去的瀑布式開發，是照需求系統分析、系統設計、開發、測試的階段來進行，也就是針對一整包要 release 的範圍（如果是 min-waterfall，就是「某階段要 release 的一整包功能」）來整包分析、整包設計、整包開發、整包測試。

如果一個 release phase 是半年，那等整包都開發完後，在最後一個月才做一次測試，沒有迴歸測試造成的 effort （嚴格來說，這個 effort 會在 phase 2 之後才出現，到時就是用人海戰術，趕快結案收錢就好）。

所以一般產品的開發測試團隊，在嚮往 Scrum 的種種美好而開始進行 Scrum 模式的開發與交付過程中，就會開始突顯出基礎建設不足，以及團隊工程實踐能力不足以支撐迭代式交付的問題。

另外常見的問題，還有 component team 分工、團隊之間依賴、多團隊 priority 不一致、item 無法切細並滿足 end-to-end 的要求、item 無法小到產生價值或是無法在 sprint 中完成等等...我們之後再另闢文章說明

所以，scrum 把產品與團隊的基礎建設與工程實踐不足的缺點血淋淋暴露出來之後，大部分的人並不樂意面對自己有這些缺點或問題，進而質疑 scrum 在實務上的問題很多、scrum 不適合我們公司或產品。

其實是基礎建設問題很多、工程實踐的技能不足、你們的基本功還不適合用 scrum

blog 與課程更新內容，請前往新站位置：http://tdd.best/