工程演示在GitLab

认为工作软件是衡量进度的主要指标是敏捷软件开发的原则之一。降级会让更多的人关注这个项目，以发现bug并揭示产品需求中的模糊性。它也是一种为组织的其他成员提供状态的透明和轻量级的方法。开发人员应该定期进行演示，就像每周或每周都有产品经理在场一样。演示会议应保持在30分钟或以下。重点应放在产品要求或验收标准上，而不是在实施细节上。
演示对于跨越多个版本或正在积极迭代的特性最有效。
对于任何对该特性的进展感兴趣的涉众来说，观众都是如此。虽然通常主要由团队和他们的产品经理组成。

如何设置演示

剧本

演示以脚本开始，脚本包含演示程序为显示功能而采取的操作。列出每个步骤，不管它看起来多么小，都可能暴露隐式依赖关系。

公开通过向用户命名空间中的远程推送创建的新项目可能工作，也可能不工作。
脚本有两个部分，准备部分将由演示程序在演示之前执行。这个部分应该尽可能小，以揭示最终用户对这个特性的设置成本，同时也可以分析在这个特性上进行有效开发是多么容易。第二部分是演示本身，在调用期间执行。
脚本应该是雄心勃勃的，每个演示都应该失败。如果演示的所有步骤都成功，那么脚本就不够雄心勃勃。

变焦呼叫

工程经理应该设置一个经常性的缩放调用，它开始自动记录。记录允许无法加入的团队成员异步地跟上速度。

演示

当演示开始时，确保有一个文档，每个参与者都可以在其中做笔记。注释应该反映观察到的问题，潜在的脚本改进，在未来演示中需要探索的领域(如果场景是什么)，以及成功。

演示结束

预留最后5分钟的演示，以反思它。开始列出意外故障，指定一个DRI来创建问题并确定优先级。失败后，建议添加和删除脚本的步骤。还可以增加哪些其他领域？在运行了几次演示之后，它过去所花费的时间可能会比开始时少，这反过来又允许脚本的扩展。当步骤被移除时，是另一个承认进展的好时机。防止移走步骤以前他们被成功地演示了，因为预期一个修复交付。
最后；宣布下一个演示的人。循环演示程序降低了风险，并根据代码运行的环境降低了一些bug未被发现的风险。
建议在未过滤的GitLab通道上运行流。