我有两个与SCRUM相关的查询。它们如下：
我已经读过SCRUM故事的格式是“作为＆lt;用户类型＆gt;，我想＆lt;某个目标＆gt;所以＆lt;某些原因＆gt;”。我必须为API写一个故事。此API将发送一封电子邮件，其中包含用于验证用户电子邮件地址的链接。这里的用户类型是什么？是否是用户登录？
子任务的故事格式是否与故事类似，或者可以是正常的描述？
答案 0 :(得分：0)
让我们先开始澄清一些概念。
Scrum不是首字母缩略词，因此写成Scrum（专有名称）。然后，没有什么叫做“Scrum Stories”。你所指的是：用户故事。用户故事广泛用于克莱斯勒C3项目中，开发了极限编程。此外，您指的是由Mike Cohn推广的特定模板，称为规范形式。因此，可以将产品Backlog项目表达为API的用户故事。但是考虑到你可以使用这个模板，你可以使用用户故事，或者你可以用更有意义和价值的方式编写Product Backlog Item。在您的情况下，哪个是将使用API的角色，机器或服务？
关于你的第二个问题。 Scrum Guide只是说你应该在1天或更短的工作单位中分解你的Sprint计划。通常，实现是创建这个工作单元并将它们称为任务，这是执行用户故事所必需的工作。编写的方式也是开放的，但以规范形式编写它们并不常见。所以你可以把它写成ID，标题和描述。
答案 1 :(得分：0)
您遇到的麻烦可能是您从一个坚定的实施开始，然后尝试向后工作（除非您的产品是您的用户使用的API，在这种情况下，我认为这可以回答您的问题）。
当我们从用户需求接近它时，我们通常会得到更多的问题陈述，例如
＆＃34;作为度假者，我希望该网站能够计算最佳路线 我的所有类型的交通工具，所以我不必经营许多 搜索自己弄清楚。＆＃34;
如果您的应用程序架构需要，那么提供此需求的其中一个部分就是创建API调用。然后＆＃34;为聚合调用添加API方法＆＃34;可能是该用户故事下的任务。
您将遇到所有特定故事需要的API工作，这很好，但它不会在用户故事中出现。例如，让我们说我们做了关于用户的故事，但是第一次开始时将它限制在飞机和火车上，然后我们创建了另一个故事：
＆＃34;作为美国的度假者，我希望我的旅行计划者能够考虑公共汽车 所以我可以在度假时使用巴士旅游。＆＃34;
现在，也许唯一的任务就是创建一些API更改以在搜索中包含总线路径，但这不会导致用户故事出现问题，因为我们重新开始使用用户＆＃39 ; s问题陈述在开头而不是从期望的实现开始并向后工作。