检查5阶段模型中先前的（敏捷）回顾性问题

Question

事实：

Esther Derby和Diana Larsen在书"Agile Retrospectives - Making Good Teams Great"中描述的5相方法是正确建立的。

这五个阶段是：

  

  
1. 设置舞台
  
2. 收集数据
  
3. 生成见解
  
4. 决定要做什么
  
5. 关闭回顾展
  

许多博客，文章或Retromat（感谢：）遵循/描述了这种模式。

怪异：

实际上，缺少对先前回顾性决定的检查！

例如马克·洛夫勒（MarcLöffler）的书"Improving Agile Retrospectives: Helping Teams Become More Efficient"提出了6个阶段，其中附加阶段

  

检查假设

放在“收集数据”阶段之前的第一阶段“设置阶段”之后。

我的问题：

1. 有什么原因，为什么这个重要的主题在5个阶段的方法中丢失了？
2. 您如何实施对先前假设/假设/行动的检查？

Answer 1

可以肯定的是，对以前的追溯行动的检查可以作为追溯议程的一部分。 但是，团队可以决定以不同的方式处理此类行为。我已经看到动作作为技术用户故事或看板中确定的任务处理。 这样，团队就可以很好地了解追溯过程中决定的动作。

Answer 2

该书的第2章介绍了团队历史和环境的重要性，并为回顾制定了目标。因此，您可以进行回顾以专门检查您为实现进一步目标而采取的最后行动，或者让其自然发生。我的意思是，如果发生同一问题或团队认为未完全解决，则在收集数据阶段可能会出现运行实验。

Scrum的任务是至少包括上次回顾会议中确定的一项优先重点改进。在我看来，它已包含在内，以应对一个常见问题：不进行任何改进。有时是因为回顾只是没有改进措施的遗憾，或者是因为在下一次迭代中没有给出连续性（不执行可操作的项目）。如果您设法克服了这两个障碍，则对改进措施的检查将包括在迭代本身的检查中。因此，当您检查上一次迭代时，您已经在检查假设/假设/动作。

无论如何，如果您想要一种具有显着连续性的工具进行一次以上的迭代来解决更复杂的问题，则可以关注Toyota Kata：Toyota Kata

Answer 3

我希望“决定做什么”部分将包括如何验证操作并决定如何进行。可能会说出类似“在下一次回顾之初我们将审查对其进行质量检查的错误数量的影响”之类的内容，或者该操作的计划时间可能长于或短于一次冲刺，或者可能在另一时间验证。我绝对希望团队在采取行动时决定这一点并设定成功标准（因为避免半途而废或避免确认偏差）。

自从我读了书已经有一段时间了，但是我不记得它说过除了这五个步骤之外，您无法在复古中做任何其他事情。