我是敏捷/ TDD世界的新手，并试图了解一些基础知识。 这与我应该如何实现用户故事有关。
例如假设我有一个假设的内容管理系统，我有2个以下的用户故事：
故事1：
作为内容作者
我需要能够创建新闻文章
这样可以用来吸引用户访问网站
故事2：
作为编辑器
我需要能够查看现有文章
以便我可以查看它们以提高质量
我接近这个的方式是，
我的困境是关于作为用户故事的一部分。
特别是在这些示例中，他们间接暗示了一些身份验证，授权相关的要求，因为用户故事提到了两个用户类别。
所以我的问题是，我是否应该有任何控制身份验证/授权的任务/测试来完成这些用户故事 或者我应该只关注尝试实现功能的用户故事的我需要部分，并等待任何明确提及身份验证，授权<的用户故事/ strong>相关要求？
我们非常感谢您的所有投入。
干杯。
答案 0 :(得分：7)
不要担心现阶段的影响。
用户故事应为：
如果尚未完成，您可以将授权故事添加到产品待办事项中，以便产品所有者确定优先级。授权故事可能由其他团队（例如您的网络管理部门或类似团队）接收，因此请专注于提供您正在处理的故事所要求的功能。
答案 1 :(得分：6)
你一定要专注于我需要部分，并将作为和视为作为某种上下文。
你的故事中有很多漏洞。基础授权/识别部分是一个，另一个我看到以便我吸引更多访问者到我的网站是你无法真正测试的东西，所以你应该再考虑一下，找到另一个（可能是一些简单而且与不太相似的东西，以便我可以将它们放在我的网站上以吸引更多访问者）。我相信，使用这种格式以便部分应该包含一些关于如何测试故事的粗略概念。
我真的在故事中使用了一些不太正式的东西：标题，简短描述以及如何演示的一些解释。我还添加了一些优先级值（对产品所有者很重要）和粗略估算的工作量。最有用的部分可能是如何演示，因为它有助于编写测试（如果有必要，在打破故事后，我也更喜欢，如果可能的话，保持故事短片以避免需要打破它们） 。此外，我尽量不将故事分解为任务，而是将故事分解为小故事。任务往往过于关注你将如何做某事，你应该专注于你想要的结果。
在你的情况下，肯定会有其他故事，其中一个将是关于某天的身份验证，但这不应该阻止你现在编写代码页。继续一步一步，让你的故事变得简单（你有测试，稍后重构很容易），你会很快感受到什么对你有用。
你应该看一下优秀的书Scrum and XP from Trenches并看看他们是如何做到的。
答案 2 :(得分：4)
短语
“作为内容作者 我需要能够创建新闻文章 这样可以用来吸引用户访问网站“
不是故事。它是适用于卡片或电子表格列中的故事摘要，代表故事，因此您可以记住您正在谈论的是哪一个。整个故事由三部分组成 - Card, Conversation and Confirmation - 你需要的部分就是对话。
与团队中的用户或用户代表交谈，了解其真正含义。
答案 3 :(得分：3)
作为一部分并不意味着身份验证或授权。以同样的方式，您可以将用户故事编写为：
这是否意味着访问者必须经过身份验证？授权vistor有什么？用户故事不应包含“隐藏要求”。如果您需要身份验证和授权，只需为此创建用户故事。
作为部件指定应用程序中用户角色的类型。每个角色都有一些特殊需求和要求，并从不同的原因使用应用程序。在开始编写用户故事之前，您应该尝试收集角色。
用户素材不仅包含说明。它应包含在流程的不同阶段添加的其他信息。
另请注意，并非每个用户故事都会直接分解为任务。您可以拥有大型高级用户故事，这些故事将首先分解为较小的用户故事。我们称之为用户故事史诗。
答案 4 :(得分：1)
您最初可以假设用户有权进行更改，然后将授权作为单独的故事处理（当它们成为您的待办事项中最重要的项目时）。
这样做的好处是可以将故事的范围保持在较小的范围内，以便更容易使用，并且可以在之前的可部署状态下获取初始故事。
答案 5 :(得分：1)
至少我会为生成故事：
如果没有人知道如何处理故事级别的人，我会与/抓住电话/启动即时消息并与他们核实。您可以在较低级别使用TDD来实现您不想实现的功能，但端到端故事中的任何测试自动化都应该通过用户所做的事情。
这些故事的一个原因是你可能正在考虑基础任务，但从用户的角度来看，你最终可能会发现客户想要更多的具有openid / login和现有帐户感觉的博客。 它的敏捷性毕竟是滚动/完全沟通的方式，而不是在大型分析+设计阶段定义的全部。
在与项目甚至无关的用户名/密码/哈希/等的时候，没有必要专心致志。
无论你做什么，都要保持简单。
<强> PS。它只是故事中不可或缺的一部分，恰好依赖于其他故事。