作者：Mike Cohn
译者：李洁（Jerry Li）
原文链接：
https://www.mountaingoatsoftware.com/blog/why-you-should-consider-stopping-sprint-reviews
对许多团队来说，冲刺评审会议已经走到尽头，是时候停止了。
是亵渎吗？也许是，但请听我把话说完。
冲刺评审会议的目的
冲刺评审会议的目的是：为团队获取对已开发成果的反馈信息。这种反馈会引发产生新的产品待办项，这些产品待办项要么代表着新的特性思路，要么代表着对最近开发特性的调整。产品负责人会在最终确定下个冲刺的优先事项时，考虑此反馈。
由于目的是收集对已开发成果的反馈信息，所以冲刺评审会议通常在冲刺结束时进行。对于大多数团队来说，会在冲刺回顾会议之前完成。
但是，对许多团队来说，等到冲刺结束时再进行冲刺评审会议，就太晚了。任何在冲刺评审会议上收到的反馈信息，对于要其用于当前冲刺的团队来说，都来得太晚。
多年前，团队就已经知晓这一点了。几乎在每次Scrum Master认证课的授课期间，我都会被问以下问题：
- 如果反馈信息导致必须进行变更，团队还会由于完成产品待办项而得到好评吗？
- 如果只是一个非常小的变更，该怎么办？
- 如果变更确实是很好的优化，该怎么办？
多年来，对问题的标准答案是：团队应当尽早地和持续地向产品负责人演示其工作成果。从来没有一条规则规定：反馈只能发生于冲刺结束时的正式评审会议上。
但是，时代已经不同了！
十年前，优秀的团队会持续集成他们的代码——每次代码签入时都会触发构建和确保所有功能正常运行的自动化测试。
现在，优秀的团队会持续交付或部署代码——在代码签入后，团队不但会运行自动化测试，而且还会真实地部署。
这就完全改变了冲刺评审会议的本质。
考虑这样一种团队情况：他们平均每天向生产环境交付7次新功能。对于一个优秀的网站开发团队来说，这在当今并不罕见。
那在为期十天的冲刺结束时，他们的冲刺评审会议该讨论什么呢？在这段时间里，团队交付了70个新功能（每天7个，持续10天）。
我想，团队会在冲刺评审会议中询问干系人：“那么，您对我们开发的70个新功能有什么想法？”
而干系人则会回答说：“谁会在意我们想什么？重要的是——我们的用户在想什么？他们都已经在用这些功能了。”
在持续交付/持续部署的世界里，等到冲刺结束的评审会议上再去寻求干系人的反馈，会太迟——用户都已经在使用功能了，最好的反馈会来自他们。
应该以什么来取代这些团队的冲刺评审会议？
对于频繁发布的团队，如果一个正式的、冲刺结束时才开展的评审会议不再适合他们，那他们该改为做什么呢？
他们应该少而频繁地“获取反馈”。只要一个产品待办项完成了，团队成员就应该将其向1-3名需要查看它的干系人做演示，然后执行发布。通常，这些干系人只会是新功能的申请人和产品负责人（如果他们不是同一个人）。
由开发产品待办项的那1-2名团队成员来安排一个面向功能申请人的快速演示。他们会演示这个产品待办项，如果其满足功能申请人的期望，就会被交付——立刻执行。
也许两小时后，其他团队成员完成了另一个产品待办项。他们也会邀请申请该产品待办项的1-2个干系人，或许还会叫上产品负责人一起，做一个快速演示，并交付该特性。
这种模式可以根据需要而重复进行。当然，有时候，这些一次一个的小型功能评审也可以批量进行：团队可以一次向产品负责人演示2-3个产品待办项，然后在得到批准后全部交付。多数情况下，开发团队、产品负责人和干系人之间会产生一定程度的信任，这样团队就可以自行打交付特性的电话，而无需经过这种小型评审。如果团队发布得极快，这会成为一种必然。
授权团队做发布决策的风险并不大。其中多数变更都是独立的，而且只有几十行代码。如果团队错误地发布了产品负责人不认可的内容，新功能通常也能得到快速地变更或回滚。
持续交付时，冲刺评审会议还存有一席之地吗？
之所以被称为冲刺评审会，而不是冲刺演示会，是有原因的。名称上的细微差别，提醒团队冲刺评审不仅仅是做演示。演示是大多数评审会议的核心活动和关注焦点，但是在一个好的冲刺评审会议上不会只做演示。
在冲刺评审会议上，团队和干系人可以讨论产品的优先级和计划。常常可以看到类似这些的讨论话题：
- 当看完当前冲刺已完成成果后，我们认为下个冲刺该做什么？
- 在产品待办列表中，是否有些条目要做优先级调整？
- 是否存在不再需要和可以丢弃的产品待办项？
- 当前冲刺的工作，是否有机会发布？
如果您的团队虽然已在持续交付但仍能通过冲刺评审会议解决这类问题，那么您可能会发现仍然值得实施传统的、冲刺结束时的评审会议，即使某些产品待办项已经预先被批准发布（以我已描述的、一次一个的方式进行）。
冲刺评审会议的教育功能
冲刺评审会议还有教育功能。如果团队已持续交付并使用一次一个的小型评审，那么可能会是这样一种情况：每个产品待办项在交付前都已被至少一个干系人看过；然而，采用这种方法，会导致多数干系人不清楚整个冲刺的多数工作成果。
例如，团队在冲刺期间可能部署了50次。其中您看到了其中五次部署前的演示，我则看到了其他五次。而我们俩，谁也没有看过所有的演示。
这就为冲刺评审会提供了教育功能——它是让每个人观看所有冲刺成果的唯一时机。在多个特性组成的更大集合的上下文中观看交付的功能，不但能产生新的想法（新的产品待办项），而且还可能会改变干系人对已实现结果的审核意见（认可或者拒绝）。
该怎么做？
如今，我已不再把冲刺评审会议看成是Scrum必不可少的元素。但对多数团队来说，它仍然适合，并还像以前一样有用。例如，一个按季度部署的团队，仍然能从传统、正式、冲刺结束时才进行的评审会中获益（同多年来所描述和运作的一样）。
然而，对于另一些团队，尤其是那些持续部署或交付的团队，或许您会发现：传统的冲刺评审会因实施得过晚而会错过获取有用反馈的时机。
对于这些团队，冲刺评审会的实施需求会被例行的“获取反馈”取代。
何时以及如何“获取反馈”由这些团队自行决定，但多数团队都会选择以一次一个的小型功能评审形式来实施。当一个待办项完成时，团队成员会向提出功能申请或受影响的少数几个人做演示。在某些情况下，这些小型评审可能会一天发生多次。
而对于某些团队来说，完全取消冲刺评审会议，则可能太激进了。因为好的冲刺评审会议并不总是只做产品演示。这些团队会实施我所描述的小型功能评审，也会在冲刺结束时实施冲刺评审会议——就像正常情况一样——但会更强调评审会议的教育和知识共享功能。
您有何想法？
您是否有时也会觉得仅在冲刺结束才实施的评审太晚？您的团队如何通过尽早获取用户和干系人的反馈来适应变化？如果团队已在持续交付或部署，您是否已改为采用一次一个的小型评审？请在下面的评论中分享您的想法。
