「團隊有時候會提出一長串的待改善清單，但是太多的提議會壓垮你改變的能力。」——《Agile Retrospectives 中文版》

大家應該都有過一種經驗，一份 ToDo List 從少少的項目逐漸累積，最後變成一份無用的 List。

同樣的，軟體專案中記錄了各種技術債與未處理的 Issue，最後被永遠擱置在專案的角落。

如果上面兩種情況都曾發生過，那麼你覺得在 Retrospective 中列出來的待改善清單會不會也有同樣的狀況呢？

這似乎是一種很常見的弔詭現象，團隊越是認真的找出需要改善的項目，結果只是徒增清單的長度，最後什麼都沒有改變。

什麼都想做，於是什麼都沒做，本來應該是一份 Action list，結果只變成 Wish list。

DevOps 提倡的持續改善，需要的是團隊能夠小步、逐漸且長期執行改善的能力。

為改善清單排出優先順序，分配團隊有限的資源，然後認真的完成它。

讓團隊在每一次的 Retro 中，都能確實感受到改善正在發生，相信改善計劃是會成真的。

你們有任何定期回顧的機制嗎？這些機制是玩真的？還是⋯⋯不好説呢？