例如，我的第一个想法是提出对质量标准的期望，即对交付成果的接受标准，例如“作为运营工程师，可交付成果以及安装和验证自动化脚本，以实现快速透明的部署”，但是还有更多内容吗？
#1 楼
确保您的故事不以运营为中心。请记住，DevOps不是一种文化，而是一种角色。 “操作工程师”真的是故事的利益相关者吗？
考虑一下他们提供的功能和商业价值。作为利益相关者，我想要功能，以便获得商业价值。如果您正在努力确定业务价值，为什么要这样做呢？
故事应该是“垂直切面”而不是“水平切面”。这意味着故事应该关注整个功能，而不是图层。这非常适合DevOps文化，因为您的故事可以跨越传统的开发和运营层。
您已经具有一些有趣的功能，例如质量标准。现在，您只需要确定最终的利益相关者是谁，这将是什么商业价值，并确保您以一种具有开发，运营和QA技能的人的工作方式来编写故事。 br />
评论
您需要什么使您受益？你为什么需要它？您可以使它如此通用以至于故事永远不会完成，也可以如此具体以至于它不需要进一步细分。例如，作为一名运维工程师，我需要在script_y中实现feature_x，以便我能够使用something_z。