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

  • Mike Bria
  • 郭晓刚

2008 年 11 月 16 日

话题:敏捷架构文化 & 方法

表面上看,多数敏捷方法都简单地根据业务价值决定故事的开发顺序。但在很多情况下,更明智的做法是将增加业务价值与有意识的"获取知识"步骤结合起来。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'

敏捷架构文化 & 方法