我正在尝试以更有条理的方式工作并开始采用用户故事。
我认为我误解了如何将用户故事用于技术方面。
假设我正在编写一个应用程序代码，该应用程序会为我提供Google中某个关键字的网站排名。
用户故事就是这样：
作为互联网营销人员 我想知道我的网站在哪里为关键字排名 所以我会知道我的SEO工作是否有效
现在这很简单，以用户为中心......但是，如果我需要将代理引入循环，会发生什么。
另一方面，Proxies是技术实现细节，代理是Internet Marketer域的一部分。
我该如何制作这样的故事？
作为互联网营销人员 我想在谷歌搜索时使用Proxies 因此，我们可以检查很多关键字，而不会阻止我们
以上情况对我来说听起来不合适......也许我可以将其重写为：
作为互联网营销人员 我希望能够一次检查很多关键字 所以它会节省我的时间
这听起来更合适，但是我可以给出什么样的验收标准呢？尝试在一分钟内刮掉谷歌100次？是不是浪费时间？
这是另一种情况。当我想要实现的功能是代理可以在30秒内使用一次时，我应该如何制作用户故事？我不知道如何从以用户为中心的角度来解决这个问题...
我想做的另一件事是提出另一个Role。我可以说我们有一个名为Internet Marketer的角色，而不是以Google Scraper为中心。我可以说Internet Marketer与Google Scraper有关。
现在我可以写一个用户故事，如：
作为Google Scraper
我想在每次搜索时更改代理 所以谷歌不会禁止我
您对如何处理上述技术实施细节有什么看法？它还可以帮助将系统分解为模块......
答案 0 :(得分：11)
你不写技术故事。用户故事应符合INVEST criteria。
代理听起来像一个实现细节，应该避免。您不应该在故事中提及代理服务器。即使它们是域的一部分，也可能有其他方法来实现相同的效果。
而不是写“我想使用代理，以便我不被阻止”，你应该写道，“我想伪装我的身份，这样我就不会被阻止”。如果我是你的客户，我不知道你为什么要代理？它是前向，开放还是反向代理？有大量uses for a proxy server。您应该选择要利用的功能。
然而，你不应该对完美的故事太过痴迷。敏捷宣言说：“个人和流程与工具之间的互动”。
在编写用户故事时，您还应该考虑3 C：Card, Conversation, Confirmation。客户和您都了解故事的含义吗？
卡是否符合投资标准？如果你对这两个问题的回答都是肯定的，那么这个故事就可以了。
答案 1 :(得分：2)
用户故事不应包含技术细节。在Sprint Planing期间，应将技术详细信息添加为嵌套在用户素材下方的交付团队任务。应通过交付团队的讨论创建这些任务。您不应该尝试记录太阳下的每个实施细节，因为您将达到收益递减点。针对每个用户故事的实现细节（任务）覆盖60-75％的覆盖率，因为细节可能随着编码的开始而改变。开发人员在编码期间发现的任何其他详细信息可以在每日站立期间进行简要共享和记录。用户故事应该是简单而非技术性的，而交付/开发团队将充实故事细节作为嵌套任务。 开发人员可以通过其集成开发环境（IDE）查看这些任务。当开发人员完成任务时，他们可以将签到的代码与工作项跟踪工具（Jira，Team Foundation Server，准时）中的任务相关联。