做演示软件
| 本系列是关于我们所做的实践的，没有理解我们为什么这样做，因此可能无法从中获得我们想要的价值。 如果您也不能从中受益，那您做错了。 | |||
|---|---|---|---|
| 迭代计划，Pt。 1个 | 迭代计划，Pt。 2 | 完成的定义 | 演示版 |
| 完成完成 | 每日站立 | 回顾展 |
又经过了一次迭代，因此他们聚集了开发人员，测试人员，产品所有者和Scrum管理员，以观察增量的显示。
但是，他们也可以解决这个问题吗？ 完全正确。
但是在我们这样做之前，让我们回顾一下为什么我们首先要有一个演示。 还记得开发团队和企业之间的交易吗？ “您让我们连续工作了两个星期，我们会为您提供有用的服务。” 我们试图建立的信任需要双方的保证。
企业如何知道他们得到了可行的东西？ 经过多年的“仅需几处调整就可以完成”的承诺，我们现在有了一个演示。 产品人员现在可以检查结果并做出决定-是否足够？ 我们要继续开发吗？ 我们扔掉它吗？
敏捷是一种降低风险的方法，它将该演示用作另一个反馈点来进行课程纠正。 它限制了开发人员构建错误事物的时间，直到下次检查为止。 既然如此重要，演示就成为了必不可少的仪式。 任何敏捷框架都可以节省时间，所以我们不会忘记这样做。 你知道，就像回顾 。
硕士生
精明的团队已经知道反馈对他们有好处，所以不必等待演示。 他们了解产品人员并不会设法获得它们，并且如果他们进行早期审核，实际上可以节省他们的时间。 他们主动进行初步演示以获取反馈。
但是，有了早期的评论，官方演示会议有什么意义？
有时，演示的重点不在团队的范围内。 邀请其他团队查看我们已完成的工作或进行管理。 或者吃些比萨饼，为自己的成就感到自豪。
开始采用敏捷实践的团队仍然需要演示会议作为反馈检查点。 但是，该演示会很快失去其价值，因为我们专注于过程性内容，而不是其价值。
交给我那个过程修复工具，好吗？
在“不良”演示中，您会听到很多东西。 这是一对：
- 还没有完成，但是还是让我们展示一下
- 这是“开发完成”，但未经测试，但无论如何让我们展示一下
- 准备演示需要太多时间
- 团队展示的是API，而不是GUI，因此对用户没有用
还有许多其他。
当然，我们可以在适当的指导下解决所有这些问题。 例如，仅显示完成的项目，因为我们正在使用软件 。 如果仅显示API，则不会完成。 错误打开？ 未完成。 演示需要准备吗？ 未完成。
所有这些都是基于我们的工作流程。 它们直接源于敏捷宣言，原则和敏捷实践。
但是，所有这些人都错了。
如果演示是用于获取反馈的 （并且，演示已经是敏捷大师的工作方式了），那么为什么还要从演示中排除任何内容呢？ 显然，如果我们解决了信任问题，就不会出现半成品的问题。
只是有API还是有一半的用户界面都没关系。 反馈仍然有帮助。 “但是向产品人员展示测试是愚蠢的”。 不，他们中的大多数人似乎都不这么认为。 问他们。
演示是关于允许团队做出决定并通过反馈来改变路线。 我们拥有的检查点越多，我们将犯的错误越少，所花费的时间也越少。
因此，“应该在演示中”这个问题的答案是肯定的。
翻译自: https://www.javacodegeeks.com/2016/09/youre-wrong-demos.html
做演示软件