如何为技术实现细节编写用户故事？

Question

我试图以一种更有组织的方式工作，并开始采用用户故事。

我想我对如何将用户故事用于技术方面有误解。

假设我正在编写一个应用程序，它给我的网站在Google中的某个关键字排序。

用户故事是这样的：

作为一个互联网市场 我想知道我的网站的关键词排名在哪里。 所以我会知道我的SEO努力是否有效

现在这是非常直接和以用户为中心的..。但是，如果我需要在循环中引入代理，会发生什么。

一方面，代理是技术实现的细节，另一方面，代理是Internet Marketer领域的一部分。

我该怎么写这样的故事呢？

作为一个互联网市场 我想在谷歌搜索时使用代理。 所以我们可以在不被Google屏蔽的情况下检查很多关键词

以上情景听起来不适合我..。也许我可以改写成这样：

作为一个互联网市场 我想一次检查很多关键字。 所以这会节省我的时间

这听起来更正确，但是我能给它什么接受标准呢？试着在一分钟内抓取谷歌100次吗？这不是在浪费时间吗？

这是另一种情况。当我想要实现的功能是代理可以在30秒内使用一次时，我应该如何制作用户故事呢？我不知道如何从以用户为中心的角度来处理这个问题.

我想要做的另一件事是展示另一个Role。与其以Internet Marketer为中心，我可以说我们有一个名为Google Scraper的角色。我可以说Internet Marketer和Google Scraper有关系。

现在我可以写一个用户故事了，比如：

作为Google刮刀 我想改变每一个搜索的代理程序 所以谷歌不会禁止我

您认为如何处理像上面这样的技术实现细节？它还可以帮助把系统分解成模块..。

Answer 1

你不写技术故事。用户故事应该满足投资标准。

代理听起来像一个实现细节，应该避免。您不应该在您的故事中提到代理服务器。即使它们是域的一部分，也可能有其他方法来实现相同的效果。

不要写“我想使用代理，这样我就不会被阻止”，你应该写，“我想伪装我的身份，这样我就不会被阻止”。如果我是你的客户，我不知道你为什么要代理？它是向前的，开放的还是反向的？有大量的使用代理服务器。您应该选择您想要利用的特性。

然而，你不应该太执着于完美的故事。敏捷宣言说，“个人和互动，而不是过程和工具”。

在编写用户故事时，还应该考虑到3C的：卡片，谈话，确认。顾客和你都明白这个故事的意义吗？

卡是否符合投资标准？如果你对这两个问题的回答都是肯定的，那么这个故事就没问题了。

Answer 2

用户故事不应包括技术细节。在斯普林特计划期间，技术细节应该作为交付团队任务添加到用户故事下面。这些任务应该通过交付团队的讨论来创建。您不应该试图在阳光下记录每一个实现细节，因为您将到达一个递减的回报点。为每个用户故事提供60-75 %的实现细节(任务)覆盖率，因为随着编码的开始，细节可能会发生变化。开发人员在编码过程中发现的任何其他细节都可以在每天的站立过程中简短地共享和记录。如果用户故事可以是简单和非技术的，而交付/开发团队将把故事细节充实为嵌套的任务。这些任务应该通过他们的集成开发环境(IDE)对开发人员是可见的。当开发人员完成任务时，他们可以将其签入代码与工作项跟踪工具中的任务关联起来(Jira、，准时)