作者 Dave Nicolette译者 郑柯 发布于 2008年11月19日下午3时56分

很多人都觉得：迭代的长度应该由发布周期的长短确定。我不同意，我认为这两个周期之间不应有关系。相对于长迭代来说，短迭代可以提供更为频繁的客户反馈，同时也给予团队机会，让他们可以反思并改进自己的工作实践。短周期可以形成"心跳节奏"，这样的快节奏也足以展现更多意义。由于短周期的本性使然，团队不大有机会创建过于冗长的工作项目，而这样的项目会使得人们很难产生成就感，除非等到大量的工作完成之后。即使发布的周期很长，下面这些好处仍然存在。

好处

1. 快速响应。在不影响正在进行的工作的情况下优先快速响应变化。产品负责人、客户或是代理人在迭代中期改变优先级或是添加新功能，这样的情况很多见。如果迭代时间足够 短，这种状况就可以得到更好的处理，因为变更在下个迭代中就可以容纳进来了，这样也可以避免打乱当前迭代本不应受影响的正常节奏。
2. 问题检测。成熟的敏捷团队能够发现流程上的问题并马上处理。然而，目前看来，很多敏捷团队仍然在学习曲线上前行，他们还没有成熟到可以自己 发现并解决问题的地步。他们需要根据项目度量数据的变化来识别问题。由于趋势要靠三个点的连线才能体现出来，而项目数据每个迭代才能收集一次，因此更短的 迭代可以更快地暴露问题。
3. 范围管理。如果待办事项列表中的条目都很小，那就可以灵活移动。较长的迭代会产生较大的用户故事。如果产品负责人需要变更待办事项列表条目的优先级，如果用户故事较大，那么变更这些用户故事造成的影响也更大。较短的迭代则趋向产生较小的用户故事。遵循INVEST原则，产品负责人也更容易变更用户故事的优先级。
4. 迭代规划和跟踪。长迭代产生的较大的用户故事，经常要被分解为"任务"，也就是要将大块儿的开发工作拆分为可操作性更强的明细任务。接下 来，为了让团队知道所有用户故事的状态，这些任务要在迭代中跟踪，要么使用类似于"看板"的系统，要么使用迭代的燃尽图。很多团队每天都会停下来重新估算 尚未完成的个人任务。使用短迭代，可以去除所有这些内部流程的管理成本；用户故事变成了更小的工作单位，而人们也能够以更简单的方式跟踪迭代状态。
5. 成为转向"无迭代流程"的基础。迭代式开发保留了一些瀑布开发过程固有的管理成本，即使我们付出代价想去掉它们也是如此。如果将每个迭代从 头到尾画一个价值流累积图（cumulative flow diagram），这些管理成本就会以"在途时间（lead time）"的形式体现出来。我参与过的一些团队，他们在自己承受范围之内尽量压缩迭代的时间。我注意到他们可以消除大量类似的管理成本。迭代时间越短， 让一切工作顺利进行所需花费的流程管理成本就越少。

从另一方面来看，在有严格时间限制的迭代中工作，也可以带来一些敏捷方法的附加价值，包括频繁和有规律的演示和回顾、用来交付增量开发结果的一致性时间表、频繁得到客户反馈的机会、以及对于"心跳"或是"脉搏"类似节奏的感觉，这样的感觉可以让团队在长期的开发过程中保证认真投入。使用时间盒的方式工作是有一些额外的好处的，而有些团队在采纳无迭代的流程时会把这些好处丢掉，这就等于是"连孩子带洗澡水一起泼出去了"。而使用短迭代，可以减少转向超轻量级、无迭代的流程所带来的痛苦；这也是可以预期的。

人们在转向无迭代流程时经常会犯一个错误，他们会将所有与"迭代"有关系的实践都抛弃掉。我们要将"迭代"的概念与有附加价值的敏捷开发特定实践区分开，并寻找能够减少流程管理成本、同时还可以保留有价值实践的解决之道。

潜在问题

有人在使用短迭代时遇到了困难。短迭代的拥护者Mishkin Berteig也提到一些潜在的问题 ：

• "密集的工作回让人筋疲力尽。"我想这是团队选择何种工作方式的问题。周期短，不一定意味着工作就一定密集。短迭代可能仅仅意味着小时间盒；也就是说，每 个时间盒承诺交付的工作更少了。在工作密度上不一定有什么变化。其他的敏捷原则（特别是"可持续的步调"）就是为了防止发生筋疲力尽的情况。
• "战略层面的思考很难跟日程相结合。"战略层面的思考跟每个迭代要做的具体工作没有太大干系。迭代是战术层面的。战略层面的思考是……呃，非战术层面的。这听起来更像是管理上的问题，而不是短迭代的特性之类的东西。
• " 每个迭代必须完成的、耗费管理成本的相关任务占用了短迭代的大部分时间。"这似乎又是一个团队如何选择工作方式的问题。我曾观察到挤压迭代时间长度而引 发的一个有趣结果：人们首先"发现"一些并不是非常必要的管理任务，然后就不再做它们了。最后，团队只做必要的事情，换句话说，他们去除了流程中的浪费。 实际上，这些观察让我对Jim Shore在Java Ranch上的发言持 保留意见。他认为更长的迭代给团队的压力更小，因此有经验的敏捷团队更适合用长期的迭代。我觉得我们不必在迭代规划上花费更多时间， 我认为迭代规划还可以更少些。我支持更短的迭代，如果客户可以采取拉式的方法以单件流 （single piece flow）的方式提出需求，这些迭代甚至可能逐渐消弭。
• "对团队之外的资源或是人员的等待，这会使得工作的完成要跨越多个迭代。"组织上的约束造成了此类状况。如果试图采取的迭代长 度过短，以至于组织不能应 对，这样做并不合适。如果真这么做了，也就不能称之为"迭代"了，因为不可能在那样短的时间内交付工作结果，而组织也无法吸收这样的结果。要想有所进步， 我们必须识别出组织的约束。我并不认为临时的组织约束（它们是临时的，只要你真心愿意改变）就会使得短迭代不可行。简单么？没人会这么想。但如果组织的变 革很容易的话，那就没什么乐趣了，不是么？

相关内容： Extremely Short Iterations as a Catalyst for Effective Prioritization of Work。

作者简介

Dave Nicolette自 1977年起就从事IT行业了，他在2002年找到了敏捷，并视其为传统IT行业很多内在问题的缓解和去除之道。从那时起，在敏捷和精益的思考和实践上，他就成为了一名尽心竭力的实践者和大力鼓吹的提倡者。他喜欢与IT从业人士分享经验和有益的实践，并积极参与到敏捷社区的活动中。Dave目前是美国 Valtech科技公司的敏捷团队教练。

作者 Mike Bria译者 郭晓刚 发布于 2008年11月16日上午2时44分

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