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