洗衣機與軟體工時估算

作者已有八次搬家及安裝洗衣機的經驗，根據經驗他只需要十分鐘安裝新的洗衣機，但這次花了他四小時，是估計的 24 倍。

作者由此經驗反思，即使是熟悉的經常性開發工作，也有可能有各種未知或原本認為很小的問題，導致原來的預估大大失準。

我的意見:

公司仍然經常要求事先規劃整年度計畫，然後依計畫執行，否則要扣績效，我還是一直認為完全不敏捷。

開發人員為因應估算的困難，通常要把心裡想的時間再乘以十倍以上。

的確會有很多事插進來，開會/溝通/協調，等待它人成果，以及開發當中遇到的未知問題。

但也有意料之外提早完成的，也許是發現有先前類似的程式可以抄，有適合的函式庫解決大半問題。而現在就有 AI 來幫忙。

但即使是有提早完成的，開發人員也不會提出說時程可以提前，因為還得要包含其他工作的意料之外所需要之緩衝時間。

若是能夠依估算完成的開發工作，要不是留下債務先藏著等以後再說 (只是表面完成，未確實完全完成，待以後空出來的緩衝時間看有沒有辦法回來補，不過通常就是不會有空再補)，要不就是提早完成了，但壓著先不放出來 (或刻意就是按著不完成，等期限快到再去完成)。

而管理階層無法信任開發人員，老是認為不押時間就不會完成，開發人員就會拖拖拖，事情永遠不會有完成的一天。

想衝想做的開發人員，獲得更多工作與隨之而來要求擔負更多的責任，然後他更容易超過估算時間又被責罰，最後的績效分數也沒比別人好到哪裡，最後大家都落入不想衝不想做的狀態。

對我而言根本問題是彼此無法互信，所以只能用強迫性的手段做推動，被動被迫推著走。

在這樣的工作環境中，推動 Scrum 的好處，只有減少浪費開發人員的時間產出沒人要看的文件，其他的好處 (比如快速因應環境變化)，還是很難拿到的。