聊聊开发过程中的“反馈”

沟通，反馈，简单，勇气，尊敬是敏捷开发的五个价值观， 它们深刻地反映了当前软件开发组织中相对缺少但又对团队建设和成功交付至关重要的东西。

这里我想聊聊反馈，但并不讨论关于反馈的全部，主要是集中在对“想”与“做”的节奏的探讨。
反馈是我认为最特别的一个价值观。实际上，做很多事情，我们总是重复着“想" - "做" - "想"- "做”...的循环。比如组织一场演出，我们需要多次彩排，每一次彩排前都有一个计划，彩排完后会有反馈，下一次彩排会根据反馈调整计划，如此反复。彩排之前不管计划做的再漂亮，也都只是设想，只有去做了才能有反馈。再比如写一段实现某一功能的代码，我们会在头脑中或在纸上表达一个构想，此时还没有反馈，然后再去编码，如果实现时发现任何问题并决定调整设计再实现，这时反馈出现了，如此反复。

我们每个人都有自己关于“反馈“的习惯，尽管很多人还没有意识到这点。在上面的两个例子中，不同人的做法是有区别的，我们这里仅关注两个区别，其一是习惯于“想”到了什么程度才开始去“做”，其二是是否习惯于为在“做”过程中的“反馈”修改“想法”。

有些人习惯于在头脑中或在纸上详细决策好每一步，反复构想，直到确信无疑时才去编码，编码前都没有反馈，这样做更有可能导致设计超出了问题的需要，或者做了很多未知的假设，甚至完全把设计导向错误的方向。有的组织将设计和编码分为不同的阶段，设计人员做完设计后就去干别的工作了，对于他的设计工作，是很难有反馈的，这说明开发过程本身缺乏积极地接受反馈的意识。

反馈对设计的修正有非常积极的价值，这个价值有时甚至超过前期设计本身，而过渡设计则对项目有非常消极的影响，它不仅仅是浪费，这一点往往没能被团队发现并正确认识。

基于反馈的设计更容易体现真实的需求，更容易产生简单的设计，增个过程中少了很多可能不需要的艰难决策。测试驱动开发包含了基于反馈的设计思路。

敏捷倾向于尽早制造反馈，频繁产生和处理反馈。敏捷开发对前期设计持谨慎态度，设计就像计划一样，是用来被调整的假设，而不是要来严格执行的构想。前面想再多都只是设想，只有编码才可能产生反馈，根据反馈的再设计比前期设计有更多的现实基础。

敏捷团队习惯于在“想”与“做”的快速节奏中保持对客户价值的关注，这是一种不错的感觉。常做过度设计的人往往不善驾驭反馈的节奏，经验是保证不出大问题的关键。