[敏捷价值观系列1]敏捷与反馈（应对变化的本质）

 

敏捷与反馈（应对变化的本质）

 

反馈的定义：在信息的传播中，指接受者对传播者发出信息的放映。反馈的很重要一个属性就是时间滞延。

 

 

XP 团队致力于在尽可能快的情况下产生尽可能多的反馈。尽量将反馈的周期（时间滞延）缩短为分钟或小时，而不是星期或月。知道得越早，就可以调整得越早。（摘自《拥抱变化 2 版》）下面我举一些例子来说明反馈在敏捷软件开发中的重要性。

 

 

IDE ：

当我们在学校还用 Turbo C 时，是不是为它的难于调试而郁闷呢？后来出现了一些比较人性的 IDE ，不用编译就可以发现很多简单的错误。缩短了发现 bug 的周期。

 

 

Test － Fix － Retest ：

测试人员测出 bug ，开发人员修改 bug ，测试人员再复测。 Test 到 Retest 的周期一般都比较长，于是出现每日构造，每天测试人员可以用新的版本复测问题。同时应用了一些预防措施，比如单元测试，先写测试代码，在写功能实现，运行单元测试，看到绿条表示通过，看到红条修改代码。大大缩短了测试周期。

 

 

重构：

重构是为了提高软件的内部质量（可读性，可修改性等等），降低修改成本。重构需要以风险为导向，对于没有单元测试支持的重构，安全措施尤其重要。于是在重构的书中就提到：每次一小步，看到修改后反馈的结果，再根据结果采取相应的行动。

 

 

迭代：

有人说敏捷的本质是迭代。那么迭代的本质是什么呢？是为了快速响应不明确的东西（需求、技术等），针对反馈的结果，采取相应措施。所以本质上也是反馈。

 

 

Scrum 会议（立会）：

每天的 Scrum 会议中（ XP 开发演化为立会），每人需要回答三个问题。分别是：

 

1、 自从上次 Scrum 之后你都做了些什么？

2、 从现在开始到下一个 Scrum 你将做什么？

3、 是什么阻碍了迭代目标的实现？

 

无论是每天的 Scrum 会议，还是 Scrum 会议的内容都是为了得到对现实的工作状况的快速反馈。

 

 

估算：

估算在软件开发中常常被大家轻视，其实估算是管理客户（管理者）期望值的一个很重要工具。把每个软件开发阶段（里程碑）的估算反馈给客户，让客户及时了解项目进展（每日构造让客户知道项目的现状），这也是一种反馈。

 

 

反馈是沟通的关键部分，敏捷中的探索是指把风险比较大的模块先尝试一下，看能不能满足需求，这种尝试也是一种反馈。

 

 

反馈在敏捷中无处不在，难怪乎成为敏捷软件开发的核心价值观之一。快速的反馈对于其它领域也很有价值，比如在管理领域，《一分钟经理》这本书的核心就是快速反馈。