您如何在Sprint Review中演示没有UI的软件？

我们基本上是根据Scrum进行敏捷软件开发。我们正在尝试进行冲刺审核，但发现很困难。我们的软件正在处理大量数据，而故事往往涉及围绕此更改各种规则。

在没有UI或可见的工作流更改的情况下，有哪些选项可用于演示sprint中发生的更改，但是更改是处理工作的微妙业务规则，可能需要10分钟甚至几小时的时间？

在冲刺期间，您可以创造价值。在sprint开始和结束之间总是存在一些差异。通常情况下，即使是客户注意到的方式。因此，请显示差异。

在某些情况下，冲刺处理的发现或内部重新安排听起来可能有些微妙，但您仍然必须能够展示差异并向公众解释为什么您认为它很好，以及所有努力的好处是什么。您可以参考爱迪生（Edison）的案例，他首先发现了数千种无法制作灯泡的方法。

如果实际处理需要很长时间，则可以显示带时间压缩的视频或仅显示表格。或预先收集的结果输出。

我个人对进行后端工作的事情的偏爱是找到最终用户的更改。如果最终处理的数据最终显示在报告中，请在报告中显示前后差异。

我假设对变更的渴望来自需求。是什么引发了需要编写故事的问题？您的用户故事“语音表单”应向您指示如何通过充当故事中的用户来解决问题（例如，作为乔安妮，我需要在没有欧洲用户的情况下查看报告）。

此外，在这种情况下，您可以寻求测试团队的帮助。测试团队必须以某种方式能够验证故事是否已完成。他们是如何做到的？您可以在演示中展示该过程吗？

您怎么知道某个功能正在起作用？当您部署它时，如何确保它真正起作用？

如果您无法回答这些问题，那么您将面临比Sprint评论更大的问题。您应该能够在演示中证明这一点。

在Scrum的演示过程中，产品负责人将审阅正在开发的每个故事，然后接受它们或将其返回给开发。您需要能够证明某个功能正在运行；通常最好通过自动化测试来完成。您是否可以挑选与验收测试相对应的自动化测试并突出显示关键更改？

您的产品负责人也应该能够提供帮助；他们应该对正在开发的产品有详细的了解。他们不需要了解完整的实现细节，但是他们需要足够了解它，以便能够解释每个功能的目的（或业务价值）。毕竟，产品负责人是首先要求您实施该故事的人！

我发现可能对业务（BSA，BA，经理等）实现的一种选择是提供五到十张幻灯片演示文稿，说明预期的结果和完成的结果。然后，如果有一种有意义的方法来显示完成的工作的结果（例如数据转储或SQL查询结果）并花一些时间来解释它们，那么我会发现利益相关者通常会感到满意。

通常很难为后端类型系统上的非程序员/非技术人员提供有意义的演示。我已经尝试了几次以上，并且感觉到利益相关者的响应比我简单地执行该软件并向他们展示结果时更加满意。

但是，对您来说，这可能是比其有价值的工作。您需要权衡收益和实现收益所需的工作。

您可以使用Powerpoint或其他图形方式传达更改。例如，如果添加了一个业务规则，该规则取决于电子表格上一个单元格中的值，则可以显示它是哪个单元格并说明其更改方式。

如果后端有很多变化，而UI则没有变化，那么您可以遍历列表进行说明并显示整体变化。如果您可以创建突出显示差异的图表或图形，则可能就足够了。刷新一些代码更改或冲刺中已进行的更改/提交的列表。

如果您的更改是“后端”，则可能会有一些最终的用户界面，这些更改会在其中显示出来。你可以证明这一点。我的团队不喜欢这样做，因为他们不“拥有”该系统，但归根结底，如果这是您的客户与您的更改交互的方式，则您需要了解该UI并充分了解它足以显示成品。