慢不是目的，慢讓走的更穩。如果一個大的目標問題很難實現考慮周全，很難去控制，而且容易出錯。 那么將它分解成為若干個小問題時，每次就能更好的去控制；每一步都圍繞一個問題，每一步都解決一個問題，然后再行下一步。
快速反饋，是一種機制，告訴當前的狀況，有沒有錯，如果有錯了，哪里錯了。如果有這種機制，那么軟件開發是多么愜意的一件事情？ 大多數bug直接就修掉了。 但是實際情況卻不都是這樣。軟件開發中，一個復雜任務，直接分解后就直接沖上去做，做的過程中沒有反饋，那么很可能就走偏了， 做錯誤的事或者把事情做錯。這時候再回過頭來糾正，這是折騰，浪費。? 比如寫代碼，就會有bug，不管是理解錯，考慮錯了，考慮不周，語言有誤解，還是此地方工具有坑。 如果此刻沒有快速反饋機制，在bug發生的時刻，發現問題糾正問題，最好的機會就浪費掉了。等到出錯了，或進行不下去，或釀成大禍回頭看，再去研究哪個地方出錯？ 這個時候距離上次寫代碼的地方不管是時間和空間都很遠了，而且這一段時間又有很多修改？到底是哪一次出錯了？ 這個就是一個查錯，定位的過程. 當找到問錯的根源，大多數情況下修正起來卻不難。 但是這個查找定位問題過程，卻耗時而且有挑戰，效率就大大降低了，而且軟件開發的時間不可預測。
如果將二者結合起來，又是什么樣子呢？小步慢走，快速反饋。小步讓你每一次只處理一個小問題，而不用考慮其他（釋放大腦空間），更好的理解控制； 而快速反饋，即使做錯了，快速告訴你。二者結合起來，每一次反饋更快速，更準確。每次都做對，才一直往前走； 這樣不用回頭，減少折騰，走的更快，效率更高。 那么生活就是多么美好！
軟件開發里面都有哪些小步快走，快速反饋的例子？
1. 需求，review， demo， prototype
2. 設計，review， prototype
3. 敏捷實踐都是與反饋相關： 自動化測試，TDD， pair programming， CI/CD.
4. 開發方式： 增量開發，迭代。 增量開發就是小步慢走，迭代就是反饋。
下一篇: 小步慢走： 如何分解？
