反馈的定义：在信息的传播中，指接受者对传播者发出信息的放映。反馈的很重要一个属性就是时间滞延。
XP团队致力于在尽可能快的情况下产生尽可能多的反馈。尽量将反馈的周期（时间滞延）缩短为分钟或小时，而不是星期或月。知道得越早，就可以调整得越早。（摘自《拥抱变化 2版》）下面我举一些例子来说明反馈在敏捷软件开发中的重要性。
IDE：
当我们在学校还用Turbo C时，是不是为它的难于调试而郁闷呢？后来出现了一些比较人性的IDE，不用编译就可以发现很多简单的错误。缩短了发现bug的周期。
Test－Fix－Retest：
测试人员测出bug，开发人员修改bug，测试人员再复测。Test到Retest的周期一般都比较长，于是出现每日构造，每天测试人员可以用新的版本复测问题。同时应用了一些预防措施，比如单元测试，先写测试代码，在写功能实现，运行单元测试，看到绿条表示通过，看到红条修改代码。大大缩短了测试周期。
重构：
重构是为了提高软件的内部质量（可读性，可修改性等等），降低修改成本。重构需要以风险为导向，对于没有单元测试支持的重构，安全措施尤其重要。于是在重构的书中就提到：每次一小步，看到修改后反馈的结果，再根据结果采取相应的行动。
迭代：
有人说敏捷的本质是迭代。那么迭代的本质是什么呢？是为了快速响应不明确的东西（需求、技术等），针对反馈的结果，采取相应措施。所以本质上也是反馈。
Scrum会议（立会）：
每天的Scrum会议中（XP开发演化为立会），每人需要回答三个问题。分别是：
1、自从上次Scrum之后你都做了些什么？
2、从现在开始到下一个Scrum你将做什么？
3、是什么阻碍了迭代目标的实现？
无论是每天的Scrum会议，还是Scrum会议的内容都是为了得到对现实的工作状况的快速反馈。
估算：
估算在软件开发中常常被大家轻视，其实估算是管理客户（管理者）期望值的一个很重要工具。把每个软件开发阶段（里程碑）的估算反馈给客户，让客户及时了解项目进展（每日构造让客户知道项目的现状），这也是一种反馈。
反馈是沟通的关键部分，敏捷中的探索是指把风险比较大的模块先尝试一下，看能不能满足需求，这种尝试也是一种反馈。
反馈在敏捷中无处不在，难怪乎成为敏捷软件开发的核心价值观之一。快速的反馈对于其它领域也很有价值，比如在管理领域，《一分钟经理》这本书的核心就是快速反馈。
查看本文来源
京公网安备 11010802021500号