敏捷社区的一些成员强调了反馈循环对于提高敏捷开发流程效力方面的重要性。
“反馈循环”是什么呢？简单来说，如果某个流程的执行结果可以影响到此流程未来的运作方式，那么它就存在反馈循环。
在敏捷开发流程中存在哪些类型的反馈循环呢？在 Henrik Kniberg 和 Mattias Skarin 的著作《看板与Scrum：把两者发挥到极致》（Kanban and Scrum: Making the Most of Both）中，他们描述了Scrum 和XP 中的一些反馈循环。他们提到的一些在较短时间内形成反馈循环的XP 实践，包括：
- 结对编程
- 单元测试
- 持续集成
而需要较长时间才能形成反馈循环的 Scrum 实践包括：
- 每日站立会议
- Sprints
然而，在所有例子中，这些反馈循环背后的主要目的就是迅速提升流程能力。正如 Kniberg 和 Skarin 所说的：
做些改变 => 搞清楚它的实施状况 => 从中汲取教训 => 再做些改变。一般而言，你会希望反馈循环尽可能短，这样就能迅速优化你的流程。
Rune Sundling 最近的一篇博文提到了更多能够支持敏捷反馈的实践：
- 代码审查
- 静态代码分析
- 自动集成测试
- 自动验收测试
- 你与客户或者业务专家紧密协作，贯穿项目过程
- 高频率发布（至少发布至测试环境）
除了流程和生产力的改进，紧凑的反馈循环还能使团队成员在工作方面感觉更好。 Lisa Crispin 指出：
如果我们实施“持续集成”这一实践，对每个代码新版本做回归测试，在几分钟或几个小时之内我们就可以知道新写的或者更新后的代码是否导致别的功能不能工作。一旦我们第一时间发现，修正起来就很容易。问题不会困扰我们，因为我们知道我们能够及时修正它们，继续前进。
较短的反馈循环使我们信心倍增。有了信心，我们也就乐在其中。
评论