Scrum中允许使用“技术用户故事”吗？

Scrum中允许使用技术用户故事吗？如果是这样，在Scrum中编写技术用户故事的标准模板是什么？一样As a <user> I want to do <task> so that I can <goal>吗？

我在一些博客中读到，“ 开发人员不是用户故事”，但我也读到Scrum并没有强制要求这些。在有些情况下，他们有共同的一些博客用户故事与系统用户，它像as a <user who is not end user> i want to <system functionality> so that <some techinical thing>。那么哪个是标准？

例如，有一些用户故事，例如：

作为评论者，我想上传任何酒店/食物的照片，以便其他用户可以看到并喜欢它们

作为用户，我想添加照片评论，以便更好地解释我的观点

现在，对于这两个用户故事，都有一个重要的技术项目-保存和检索图像

因此，我可以添加带有以下描述的标题为“图像存储和检索机制”的技术故事吗？

作为开发人员，我想开发一种存储和检索图像的机制，以便用户可以在需要时添加/查看图像

允许使用技术故事，但我建议您尽量避免使用。

例如，您用于保存和检索图像的故事可以轻松地写为两个常规用户故事

1. 作为审阅者，我希望持久存储我上传的照片，以便其他用户可以随时查看它们。
   （请注意，这是假设在您的原始上传故事中，图像在上传后将不会永久存储。尽管这看起来很奇怪，但这是拆分故事以使其易于管理的有效方法。）
2. 作为用户，我想在方便的时候查看上传的图像。
   （这意味着存储的图像可以在以后检索。）

技术故事应该保留给组织来说很重要的工作，但不能作为用户的功能直接看到。例如，添加负载平衡以处理更大的数量或请求。

给定您的特定示例，问题将是开发人员为什么要开发一种存储和检索图像的机制，以便用户可以在需要时添加/查看图像，除非用户想要添加或查看图像？

也就是说，虽然您的问题是一个很好的问题，但示例不是。这是一个用户功能，应该具有用户故事。而且，如果用户确实不需要该功能，那么开发人员就不希望这样做。

技术上的故事更多是“作为开发人员，我想减少数据归档模块中的重复，这样我就不必在6个地方进行任何更改。”

是否将这些内容包含在Sprint中是一个难题，这在一定程度上取决于您认为谁是您的客户。是最终用户，还是雇用您的企业，还是雇用您的企业的企业？

许多行业咨询意见是由为咨询公司工作的人员完成的。从这个角度来看，我可以看到关于开发人员故事不好的说法。它们只是您所做的日常工作的一部分，对于为此付款的公司来说是不可见的。那些公司本能地知道，支付高昂的费用会使您的工作枯竭，因此每个开发人员都遵循只做技术开发的原则，这会缩短开发时间或提高发布无错误软件的能力。

我的经验更多是与内部团队合作，直接向支付我工资的公司提供软件。在许多这些公司中，业务与业务的技术部门之间存在信任障碍。在所有这些人中，都有一种不同的心态，即降低成本与增加收入一样。

在这些环境中，最好定义重要的开发人员案例。它提高了可见性，赢得了信任，并鼓励开发人员和管理人员考虑此类任务对企业的价值并相应地确定优先级。

最终，我建议您尝试一下。而且，如果它不提供价值，请停止这样做。

但是我的直觉是，如果您考虑此开发对企业的价值，那么您甚至都不会尝试将其发展为开发者。这对最终用户是有益的，还是不利。如果不是，那么这对企业就没有价值。

这是一个很好的问题。我没有官方的答案，但是在我工作的地方，我们添加了技术用户案例并将其称为技术债务。如果不允许使用它们，我会找到其他方法来添加它们，仅是为了记录我的工作并将其传达给企业。同样，拥有此文档使我们想起了未来项目所需的内容。

举例来说，如果不允许我们添加技术故事，那么在新应用程序中的断开连接是，在开始创建数据库模型并等待数据建模者批准之后，我要花一个星期的时间它们，使用建模器进行迭代，完成后将脚本发送到dba，等待它们创建db对象。同时，我将创建一个新的代码项目，一些基本的ORM功能以及我的源代码控制布局，当一切完成后，我将有时间创建一个空白的着陆页并进行部署。

每天进行的过程中，如果我不记录信息，那么业务就会冒充我们的团队实际上不在进行该项目。将这些项目包含在故事中意味着我们可以核对工作，记录工作并与业务进行沟通以取得进展。

如果有更好的最佳实践来做到这一点，我会非常高兴。

我个人的感觉是，团队不应过于关注Scrum所允许的范围，而应该更担心什么对团队有效。Scrum赢得了不好的声誉的部分原因是，从业人员可以变得专注于过程，这与敏捷项目管理背后的思想背道而驰。

我现在就离开我的肥皂盒，但是如果您怀疑以下内容是否真的是“混乱”，请（重新）阅读以上内容。

区分用户故事定义的“功能”和技术团队需要提供以支持这些功能的“可交付成果”非常重要。在这种情况下，需要保存和检索图片是您（作为技术团队）需要实施的技术交付物。几乎每个故事都需要一些技术成果。

之所以如此重要，是因为技术交付品（本身）并不是从用户角度产生价值的东西。如果您开始将技术交付物作为用户案例进行跟踪，那么您很容易陷入将技术产出视为产生业务价值的陷阱。用这种方式弄乱水域会使支持业务目标（即，花钱的事情）与实际业务目标（即，赚钱的事情）的工作混淆。

以上所有答案均未参考Scrum框架的权威源文档：The Scrum Guide。

产品待办列表列出了所有功能，功能，要求，增强功能和修补程序，这些功能，功能，要求，增强功能和修复程序构成了将来版本中要对产品进行的更改。

重点应放在创造价值上。有时，这些价值来自技术工作，例如升级基础架构。不要排除这些物品！

用户故事一词从未出现在《 The Scrum Guide》中，因为

它是一个框架，您可以在其中使用各种流程和技术。

使用用户故事只是记录PBI的一种可能技术。尽管常见的是“我想要的那样”格式，但它可能违背其最初的意图。敏捷2017也解决了这种麻烦的格式。

了解和利用垂直切片将有助于减小产品积压项目（PBI）的大小。考虑将单个保存和检索项目切片为保存和检索项目s。