【翻译】为什么您应该考虑停止迭代评审

【本文翻译自Mike Cohn的博客】

在持续交付的世界里，仅在迭代结束时的评审中寻求反馈为时已晚

对于许多团队来说，迭代评审（sprint review）已成为顺其自然的事，但是现在到了该停止这样做的时候了。

亵渎神灵？也许吧，但听我说。

迭代评审的目的

迭代评审的目的是使团队获得有关他们已经开发内容的反馈。该反馈可能会产生新新的产品待办列表项（product backlog items）（译者注：原文中的product backlog items我翻译成了产品待办列表项，product backlog item我翻译成了产品待办事项），这些列表项（items）描述了对功能（features）的新想法或对最新开发内容的调整。产品负责人（product owner）在最终确定即将到来的迭代的优先级时会考虑这些反馈。

由于其目的是收集最新开发内容的反馈，因此评审通常在迭代结束时进行。对于大多数团队来说，这是紧跟在回顾会（retrospective）之前完成的。

但是，对于许多团队来说，在迭代结束时进行评审为时已晚。评审收到的任何反馈都太迟了，因为团队无法在当前迭代中完成它。

多年前团队就发现了这个问题。在我教的几乎每门Certified Scrum Master（CSM）课程中，我都会被问到以下问题：

• 如果有需要更改的反馈，团队可以因完成的产品待办事项（product backlog item）获得荣誉吗？
• 很小的变更怎么处理？
• 如果变更只是一项功能优化怎么办？

多年来，对这些问题的标准答案是团队应尽早并持续不断地向产品所有者展示其工作。从未有过这样的规则：仅在迭代结束时的正式评审中才可能给出反馈。

但是时代变了。十年前，优秀的团队在每次签入（check in）代码时就在持续集成（continuously integrating）他们的代码、触发构建（build）并进行自动化测试（automated tests）以确保一切仍然工作正常。

现在，优秀的团队不断交付或部署代码。他们不仅在签入（check in）后运行自动化测试（automated tests），而且许多优秀的团队实际上在每次签入（check in）后还会进行部署（deploy）。

这完全改变了迭代评审的本质。

考虑一下一个团队的以下情况：该团队每天平均要向生产环境交付新功能七次。对于一个优秀的Web开发团队而言，这在现在一点也不罕见。

在为期十天的迭代结束时，他们迭代评审中的讨论将是什么样的？在此期间，团队交付了70项新功能（每天七项，共十天）。

我想团队会在评审中问利益相关者，“您如何看待我们开发的70项新功能？”

利益相关者回答：“谁在乎我们的想法？我们的用户已经在使用这些功能，他们怎么看？”

在持续交付（continuous delivery）/持续部署（continuous deployment）的世界中，在迭代最后的评审中寻求利益相关者的反馈为时已晚，因为用户已经在使用该功能，并且最好的反馈将来自于用户。

用什么代替这些团队的评审？

如果一次单独的、正式的、迭代结束时进行的评审不适用于频繁发布的团队，那么他们应该怎么做呢？

他们应该经常且小批量地获得反馈。产品待办事项（product backlog item）一旦完成，团队成员应该在发布之前，将其向可能需要查看该功能的1-3个的利益相关者展示。通常这些利益相关者可能只包含新功能的请求者和产品所有者（PO），如果他们不是同一个人的话。

团队中处理该产品待办事项（product backlog item）其中1-2个成员，向请求者进行快速的演示。他们会展示待办事项（item），如果待办事项（item）符合要求者的期望，则待办事项（item）会立即交付。

大概两个小时后，其他团队成员又完成了另一个产品待办事项（product backlog item）。他们会见一两个要求该项目的利益相关者，可能还有产品所有者（PO），进行快速演示并交付该功能。

该模式可以根据需要重复多次。当然，有时可以分批进行这些小型的一次性功能评审：团队可以一次向产品所有者（PO）展示2-3项内容，然后在批准后全部交付。在很多情况下，开发团队，产品所有者（PO）和利益相关者之间将建立起一定程度的信任，从而使团队本身可以在不进行小型评审的情况下进行功能交付。如果团队发布非常频繁，这非常必要。

允许团队做出决定的风险并不大。这些更改中有许多是孤立的，只有几十行代码。如果团队错误地发布了产品所有者（PO）不同意的内容，则通常可以快速更改或撤消新功能。

持续交付时，迭代评审仍然有用吗？

被称作“迭代评审（sprint review）”而不是“迭代演示（sprint demo）”之类的名称是有原因的。名称上的细微差别提醒团队，迭代评审不仅仅是演示。演示是大多数评审的主要活动和焦点，但是在良好的迭代评审中，发生的不仅仅是演示。

迭代评审是团队和利益相关者讨论产品优先级和计划的机会。常见议题如下：

• 看到当前迭代完成的功能之后，我们认为应该在下一个迭代中做什么？
• 产品待办列表（product backlog）的优先级是否需要调整？
• 不再需要的待办列表项（backlog items）是否可以删除？当前迭代的工作适不适合发布？

如果您的团队持续交付并在迭代评审中讨论此类话题，那么即使一次一次预先发布了单个产品待办事项，传统的迭代评审对您可能仍然是有价值的。

迭代评审的教育意义

迭代评审也有教育意义。如果一个团队持续交付并且每次交付都使用一次小型评审，则可以保证每个待办事项（item）在交付之前至少被一个利益相关者看到了。但是，使用这种方法，许多利益相关者将不会觉察到迭代的其他工作。

例如，一个团队可能在迭代期间部署50次。在这些部署之前，他们向您展示了其中五个，又给我看了另外五个。但是我们两个都没有看到所有的功能。

迭代评审为每个人提供了一个唯一看到所有内容的时间。在更广泛的功能集范围内查看交付的功能可以产生新的想法（新的产品待办列表项），但也可以更改利益相关者是否批准实施。

该怎么办

我不再认为迭代评审是Scrum的强制性要素。对于许多团队来说，它仍然是适当的并且像以往一样有用。例如，一个按季度部署的团队很可能会受益于传统的、正式的、迭代结束时进行的评审活动，因为它已经被详细描述并运行了多年。

但是，其他团队，特别是那些持续部署或持续交付的团队，他们发现传统的迭代评审为时已晚，无法获得有用的反馈。

对于这些团队，进行迭代评审的需求已被“获取反馈”的规则所取代。

他们何时以及如何获得反馈取决于他们，但是许多人选择一个一个的小型功能评审来收集反馈。待办事项（item）完成后，将向一小部分要求该项目或受其影响的人展示。在某些情况下，这些小型评审一天可能会发生多次。

但是对于某些团队来说，完全取消迭代评审可能就有点过了。这是因为良好的评审永远不仅仅是产品的演示。这些团队进行了我所描述的小型评审，但将以迭代结束时的评审扩大了这些小组评审的范围，但在评审过程中更加重视评审的教育意义，知识共享方面。

你怎么看？

您有时会觉得仅在迭代结束时评审我们的工作为时已晚吗？您的团队如何通过尽早获得用户和利益相关者的反馈进行调整？如果您的团队持续交付或持续部署，您是否进行一次一次的评审？请在下面的评论中分享您的想法。