筆者雖然是個年輕人(心虛)，但也聽師長說過，在很早很早的年代，寫出一段程式要debug有多麼的困難。在那個年代，寫出一段程式，要使用打孔機，很像現在大考依然常用的那種電腦閱卷卡，到計中排隊submit，過段時間去領結果，萬一錯了，就再拿張紙，修正錯誤後再去提交，再等結果...，一直到結果正確為止。

你可以想像，在那樣的年代，事前做好完整的規畫有多麼的重要！你也許需要把所有流程完整的畫出來，何時if，else時要幹啥，你甚至連print出變數內容來debug都要事前規劃，並且考慮再三。這也就難怪我們讀書時，老師們都會叫我們一定要經過充分完整規畫後再動手寫程式了。

我必須要先說，這樣的習慣是非常好的。有了好的規劃，可以檢哨走歪路的機會，也可以幫助程式設計員釐清思路與邏輯。然而，當你的產品越長越大，大到了單一專案再也容納不下，一個人也無法獨力完成時，你要怎麼辦？你還是能像以前那樣做出完整又細節的規劃嗎？以現代軟體發展的速度，也許當你規劃完，商機已經失去，那你也不用真的實作了。

現代的軟體開發，探索式的功能開發，成本已經大大降低。git幫助你錯誤時及時回頭，CI工具幫助你隨時做好完整測試與上版準備，容器技術幫助你隨時在任何環境架設一模一樣的新服務。當然，規劃還是得規劃的，但是，有需要到每個case每個邏輯轉折都要想通才能動工嗎？那倒未必...

敏捷開發，以scrum為例，有規律週期性的產出、檢討、與方向調整的過程。我們每個sprint只做目前最重要的幾件事，同時為其做出邏輯規劃，也只規畫這些，未來的功能，我們等需求更明朗時再作決定即可。同時，當有一個新功能或是新技術，你不確定是否要真的投入大量心力去實現時，你也可以花一個sprint的時間研究或是做一個prototype來看看成果如何。

敏捷流程不是快，是有彈性。我們每一到兩周就會檢討並調整方向與內容，同時產生出一個幾乎可以直接上線的商品。在這強敵環伺，弱肉強食的激烈市場，您有什麼理由不接受敏捷開發流程？