敏捷不該有重構階段
這是 Martin Fowler 在 2011 年的 Opportunistic Refactoring 其中的概念。
作為工程師，我們當然都經歷過，程式碼擴增到了某個時間點就會開始變得笨重，笨重到連新增一個理論上應該很簡單的功能都變得麻煩。如果你夠有責任感，你可能會想要花些時間整理程式碼，也就是所謂的「重構」。甚至，你可能會想要一個 sprint 來專門重構程式碼，我們姑且稱為「重構階段」好了。
但從職場政治的角度來說，利益相關者很難理解為什麼會有一個開發階段叫做「重構」。畢竟需要人力與工時，簡單來說就是額外花錢，但卻沒有新增額外的功能，也就是產品價值。因此如果一個團隊提出「重構階段」時，對利益相關者來說就是叫他們「多花一些錢」，很容易降低信任感。
從職場政治的角度來說，你確定你要叫資本家「多花一些錢」？
顧客的角度
假設你接了外包程式工作，當你評估 A 功能要花費 X 時間來完成，而且假設你的評估足夠正確的話，你應該會也會認同花費 X 時間完成 A 功能並交給客戶後，客戶就不用繼續在這個功能上花錢了。
如果你是基於其他人的程式碼來新增功能，作為專業的工程師，你當然會根據現有程式碼的狀況評估時程。若有必要先進行重構的話，你當然也是會把重構的時間納入 X 時間內，而不會跟客戶說你需要額外重構，反正客戶又聽不懂。
敏捷的角度
回到敏捷的角度，Uncle Bob 也在 Clean Agile 提過，利益相關者就是我們的顧客，包括工程團隊的 PM 與管理層。工程師在規劃迭代時，都是在分解與產品價值直接相關的故事，也就是利益相關者所需要的故事，這些故事理所當然不會有「整理程式碼」這種內容。你提出的功能實作估時，就應該要納入重構所需的時間。
你這時候當然會認為，這樣實際上不就還是有「重構階段」，但是沒有跟客戶說的意思嗎？反了，真正的問題是在這之前，為什麼會發生「重構階段」的需求？
童子軍原則
Martin Fowler 也講出重構階段的需求，本質上就是平常小小的重構做得不夠多造成的。回想一下 Uncle Bob 在 Clean Code 中提過的童子軍原則，每次看到不好的程式碼，就花個幾分鐘處理一下力所能及的部分。要是規模有點大，那就先處理一部份，下次再處理一部份，更下次再處理一部份。當然童子軍原則也告訴我們，自己不要留下垃圾，否則垃圾永遠清理不完。
當然，如果整座山都已經是垃圾了，那真的是應該要先加減清理一下才能好好做事。如果垃圾是自己造成的，那當然是自己要檢討。如果垃圾是別人造成的，你當然有權利抱怨，但你還是得清理。
重構這個行為只是在開發時順便的動作，就跟童子軍清理垃圾一樣，並不是什麼大型維護工作。如果團隊有遵循童子軍原則，每次看到不好的地方都花個幾分鐘做小小的改進，那麼程式碼應該可以一直維持在某個水準。理論上也就不需要所謂的「重構階段」了。