《超越需求：敏捷思维模式下的分析》

本节书摘来自异步社区《超越需求：敏捷思维模式下的分析》一书中的第1章，第1.4节迭代，作者【美】Kent J. McDonald（肯特 J. 麦克唐纳），更多章节内容可以访问云栖社区“异步社区”公众号查看。

1.4　迭代
迭代（iterate）的一个鲜为人知的同义词是反复排练（rehearse）。仔细想一想，就会发现这是迭代的一个特征。可以通过一个又一个特性来构建软件应用，或者建造车辆的几个样板模型来尝试装配流程并生产车辆用于测试。无论哪种方法，都是在排练方法和设计决策。迭代给团队一个提出方法并进行尝试的机会，所以就算你做了一个糟糕的决定，也不至于浪费大量的工作。

迭代方法的关键是针对每个迭代的产出获得可行动的反馈，这样你就知道自己是否是在朝着期望的结果前进。为了获得有用的可行动的反馈，需要解决方案的一部分能够工作，以便利益相关者可以看到并做出反应。通过一系列迭代获得可行动的反馈，就形成了持续的学习。

与运营工作不同，IT项目和其他类型的知识工作从不直接使用可重复的流程。当你从事操作工作时，例如组装车辆或者处理索赔，许多步骤都能够从一个单元复制到下一个。识别改进变得很容易，因为在一组特定的工作任务周期之间往往只有很短的时间。运营工作具有重复性和可预测性。如果你愿意，可以反复学习如何做得更好。

另一方面，知识工作有点儿不同。项目就像雪花，没有两片是一样的。如果有机会去体验不同的项目，从一个项目获得的经验很可能并不适用于另一个项目。关注持续学习，并将迭代作为其关键组成部分，就能提醒团队要经常停下来并找出可以改进的地方。这也有助于利用实际的工作产出来确定有意义的里程碑，而不是使用中间产物衡量进展。

在会议投稿系统的案例中，我们以不同的方式使用迭代获得了收益。首先，团队产生了一条特性的定期输出流，我作为产品负责人（product owner）会进行检查并提供反馈，要么是关于系统的感观，要么是关于其功能的。团队用我的反馈来影响他们后续将要完成的特性。我们还对用户发布了投稿系统的多个版本（release），并利用第一个版本的用户反馈来影响特性如何进一步设计，并作为输入供我们决定哪些特性在下一个版本发布，而哪些特性要推迟。