迭代中不仅追求“业务价值”，还要“获取知识”

表面上看，多数敏捷方法都简单地根据业务价值决定故事的开发顺序。但在很多情况下，更明智的做法是将增加业务价值与有意识的"获取知识"步骤结合起来。 Alistair Cockburn 介绍了如何有效地进行此种结合，以及如何借助这样的实践在正确的时间交付正确的功能。

Cockburn 的阐述从一项基本断言入题——设计活动的关键产出是创造知识：

在任何团队的设计活动中，我们都是在解决一项当前仍未理解通透的问题，建立一种当前仍未理解通透的解决方案，用我们仍未完全领会的语言及技术来表达自身想法——而以上各方面都在我们的眼前不断变化着。
随着工作进展，我们对问题了解得愈多，对技术了解得愈多，对规划中的方案了解得愈多……

接着 Cockburn 举出瀑布方法的典型特征——“大爆炸”式的集成作为极端的例子，说明它是如何妨碍任何 _ 实质上的 _ 知识获取，直到项目的最后阶段，从而必然导致没有时间应对的“大惊喜”。用精益的术语来说，积累起来的未经验证的设计决策，构成了不断增长的"库存（inventory）"。Cockburn 的原话，“从减少风险的角度来说，我们认为该情形直到最后都留有很大风险，在很后的阶段才产生知识，总之不是什么赏心悦目之事。”

Cockburn 接着介绍了一种敏捷的处理方式，在其中团队将早期的迭代重点放在“积累知识”，也就是学习：

团队及早地、经常地集成，可使“大惊喜”分散到许多小的阶段中。这样做，团队可及早发现自身的错误，“学习”到错在何处，并因而减少以后的集成出现重大失败的机会。换言之，“学习”因素对项目的影响越来越小。这是一件好事。

为了促进这种实践，Cockburn 建议团队问自己“我们担心 / 害怕什么？”的问题，并且将开发前期的精力集中在减少那些恐惧因素，而不要盲从“业务价值 高的优先”这种教条。他提醒说这一阶段的工作次序可能表现得没什么条理，“但是它会满足在花费同样金钱之下，知识提升速度从高到低的排列次序，和降低项目 风险从多到少的次序”

这种方法的底线是，一旦减轻了大的风险，就开始按照业务价值的次序安排工作

当知识曲线开始变平坦，那就是转向按照业务价值高低排列的时刻。这时候就与一般的敏捷建议相一致了。请注意，原则上在着力获取知识的阶段，业务价值也总是在提高的；因此并非把业务价值丢到一边，只不过获取业务价值不是主导的推动力。

读者还应该注意，Alistair 特别明确警告不要将“获取知识”与“BDUF （Big Design Up Front）”的意义相混淆。

Cockburn 在最后收尾时解释如何将这种实践与功能疏剪（Feature thinning）的一种实际运用相结合，使项目有效地平滑收尾，最终有效地提升团队的敏捷程度：

当知识曲线与业务价值曲线都变平后，资方就处在一种位置，既可以按时交付一组疏剪过的功能（或因竞争对手的动作而提前！），又可以稍后交付完整的功能集合。决定权理所应当地在资方的手上。

一如既往，请把这篇新闻仅仅当作一则提纲挈领的广告，务必阅读Alistair 的完整文章。文章中还包括了几幅很有说服力的图，Alistair 也介绍了他在两个截然不同的实际项目中采用这种实践的经验。

那么，您的看法如何呢？Alistair 的方法符合你的经验吗？假如把这种方法用在你过去的项目中会不会有帮助？现在的项目又如何，以后的呢？如果有帮助，好在哪里？如果没有，又为什么？你会不会觉得这种方法“不是敏捷”？请留下您的想法。

查看英文原文： Iterating To Acquire Knowledge, Not Just ‘Business Value’