反馈与前馈：各有所长

过去某件事情的输出对未来产生的潜在相关影响，即为反馈。为了构建高质量的产品，敏捷非常重视在每个步骤中促进和提供反馈。反馈的好处数不胜数，而 Tom Ferguson 建议团队应该开始将前馈视为有用的工具进行研究。前馈为团队提供关于未来方向的帮助和建议。

Dietrich Kappe 认为反馈循环非常重要，他提出：

敏捷软件开发的前三条戒律是： 1. 反馈循环
2. 反馈循环
3. 反馈循环

他提到：从结对编程开始，到尽早、频繁发布软件，在整个流程中集成了很多反馈过程。

Michael Hugos 引用了 Glenn Vanderburg 编写的白皮书，其中将反馈循环分为3 个级别。最内层的级别包括比较底层的实践，比如结对编程、编码标准、单元测试和功能测试、重构、简单设计，以及每周工作40 小时。位于该层之上的，是一些更大的实践，比如系统隐喻、持续集成、现场客户、代码集体所有制、验收测试、规划游戏，还有短期发布。这些实践为敏捷项目应该遵循的方向提供了反馈。在这些实践之上的，是最高级的反馈循环，包括监控和管理项目的项目级活动。这些实践有助于项目干系人了解项目是否满足他们的期望。

Zachary Spencer 进一步将反馈循环划分为积极和消极两种。他提到积极反馈相对于消极反馈的好处，并鼓励所有敏捷团队推进积极反馈。在他看来：

有两种收集反馈的方式。你可以请求反馈，也就是积极反馈；或者你可以观察别人的行为，这是消极反馈。积极反馈和消极反馈的适用场合不同。他们有各自的长处和劣势。然而，要想做出真正周全的决策，两种都要使用。

在另一个地方， Tom Ferguson 认为：反馈总是聚焦于过去，而在敏捷项目中，有必要向前展望，因为情景总在发生变化。他建议：

反馈的问题在于它是“后面”的。反馈希望将注意力放在过去的事情上。这样一来，它就会是受限制而且静止不同的。在项目中，我们可不能受到什么限制、保持静止不动，或是总盯着过去。虽然我们希望从过去吸取经验教训，过去的已经成为历史，无法改变。考虑到这些困难，为什么不试试前馈？

Tom 补充说道：前馈是 Marshal Goldsmith 提出来的，他建议“尝试前馈，而不是反馈”。Tom 提到使用前馈的下列原因：

这来自更为积极的视角，好比说：我们得一起做这个事情，让咱们彼此互相帮助吧。这会整个改变团队之间人们关系的互动和风气。

1. 它不会对人妄加评论。
2. 不会出现对过去失败的负面暗示。在前馈中，没有“失败”一说。
3. 更容易进行。人们在讨论未来的表现时没有太多防御心理。前馈针对个人的可能性更小，而且不容易引起抗拒心理。
4. 速度更快。纠缠于过去会耗费很多时间。为将来推荐一些经过深思熟虑的主意，这会快很多。
5. 过去的都是历史，今天就是现在，而明天将会是新的历险。从今天开始，我们只能改变我们的行为。讨论过去的失败有何意义？关于我们期望的美好明天不是更好么？
6. 前馈与指导有更多的相似性，因此构建的团队关系更有助于大家做出最好的表现。
7. 很多人真的希望得到帮助，以提升个人表现，因为这最终将使他们在职业生涯中更为成功。
8. 沟通，是成功项目的灵魂，它将会得到大大提升。
9. 为什么投入时间和精力去思考我们都讨厌的事情？

Tom 认为：前馈有助于带来积极的能量，而不是负面的影响以及反馈导致的质疑气氛。进行前馈还能帮助构建团队成员之间的和谐关系，因为没有人会像反馈那样，将前馈看做是针对他们个人的。

Marshal Goldsmith 提出：

其目的不是要说带头人永远都不应该提供反馈，也不是说应该放弃绩效评估。目的是要告诉人们：在日常交互中，应该多使用前馈而不是反馈。除了它的效率和有效性之外，前馈还能让人们更加享受生活。当经理被问及：“上次你接收到自己反馈的时候，你感觉如何？”他们最常见的反应都是非常负面的。而当他们接收到前馈后，再被问及类似问题，他们的回复认为：前馈不仅很有用，而且还很有趣！

因此，前馈和反馈都是保证项目和敏捷团队走向正确方向的工具。关键在于做出正确决策，保证符合当前的情景和工作环境。

查看英文原文： Feedback and Feedfoward: Best of Both Worlds