慢不是目的，慢让走的更稳。如果一个大的目标问题很难实现考虑周全，很难去控制，而且容易出错。 那么将它分解成为若干个小问题时，每次就能更好的去控制；每一步都围绕一个问题，每一步都解决一个问题，然后再行下一步。
快速反馈，是一种机制，告诉当前的状况，有没有错，如果有错了，哪里错了。如果有这种机制，那么软件开发是多么惬意的一件事情？ 大多数bug直接就修掉了。 但是实际情况却不都是这样。软件开发中，一个复杂任务，直接分解后就直接冲上去做，做的过程中没有反馈，那么很可能就走偏了， 做错误的事或者把事情做错。这时候再回过头来纠正，这是折腾，浪费。 比如写代码，就会有bug，不管是理解错，考虑错了，考虑不周，语言有误解，还是此地方工具有坑。 如果此刻没有快速反馈机制，在bug发生的时刻，发现问题纠正问题，最好的机会就浪费掉了。等到出错了，或进行不下去，或酿成大祸回头看，再去研究哪个地方出错？ 这个时候距离上次写代码的地方不管是时间和空间都很远了，而且这一段时间又有很多修改？到底是哪一次出错了？ 这个就是一个查错，定位的过程. 当找到问错的根源，大多数情况下修正起来却不难。 但是这个查找定位问题过程，却耗时而且有挑战，效率就大大降低了，而且软件开发的时间不可预测。
如果将二者结合起来，又是什么样子呢？小步慢走，快速反馈。小步让你每一次只处理一个小问题，而不用考虑其他（释放大脑空间），更好的理解控制； 而快速反馈，即使做错了，快速告诉你。二者结合起来，每一次反馈更快速，更准确。每次都做对，才一直往前走； 这样不用回头，减少折腾，走的更快，效率更高。 那么生活就是多么美好！
软件开发里面都有哪些小步快走，快速反馈的例子？
1. 需求，review， demo， prototype
2. 设计，review， prototype
3. 敏捷实践都是与反馈相关： 自动化测试，TDD， pair programming， CI/CD.
4. 开发方式： 增量开发，迭代。 增量开发就是小步慢走，迭代就是反馈。
下一篇: 小步慢走： 如何分解？
