11

我是敏捷/TDD 世界的新手，并试图了解一些基础知识。这与我应该如何实现用户故事有关。

例如，假设我有以下 2 个用户故事作为假设的内容管理系统开始：

故事 1：
作为内容作者
，我需要能够创建新闻文章
，以便它们可以用来吸引用户访问网站

故事 2：
作为编辑
，我需要能够查看现有文章
，以便我可以查看它们以提高质量

我的方法是，

  • 我会抓住其中一个用户故事
  • 将我需要的用户故事的一部分分解成更小的任务
  • 一项一项地抓住这些任务，并拿出测试来覆盖特定的任务
  • 以 TDD 方式执行任务

我的困境在于作为用户故事的一部分。
特别是在这些示例中，它们间接暗示了我的一些身份验证、授权相关要求，因为用户故事提到了两个用户类别。

所以我的问题是，我是否应该有任何任务/测试来控制系统的身份验证/授权来完成这些用户故事，
或者
我应该只关注我需要部分用户故事来尝试实现功能，然后等待对于任何特别提到身份验证、授权相关要求的用户故事？

非常感谢您的所有意见。

干杯。

4

6 回答 6

7

不要担心现阶段的影响。

用户故事应该是：

  • I 独立用户故事应该是自包含的，在某种程度上不依赖于另一个用户故事。
  • N Negotiable：用户故事，直到它们成为迭代的一部分，总是可以更改和重写。
  • V 有价值：用户故事必须为最终用户带来价值。
  • 可 估计的：您必须始终能够估计用户故事的大小。
  • S 大小适当或小：用户故事不应大到无法以一定程度的确定性计划/任务/优先级。
  • T 可测试：用户故事或其相关描述必须提供必要的信息以使测试开发成为可能。

[来源，维基百科]

如果尚未编写，您可以将授权故事添加到您的产品积压中，以便产品所有者优先考虑。授权故事可能会被其他团队（例如您的网络管理或类似团队）获取，因此请专注于交付您正在处理的故事所要求的功能。

于 2010-09-11T00:42:12.357 回答
6

您绝对应该专注于I need to part并将As a视为某种上下文。

你的故事有很多漏洞。基本的授权/识别部分是一个，我看到的另一个是，我的网站吸引更多访问者是你无法真正测试的，所以你应该再想一想并找到另一个（可能是简单而不是非常简单的东西）不同的喜欢，以便我可以将它们放在我的网站上以吸引更多访问者）。我相信使用这种格式，那部分应该包含一些关于如何测试你的故事的粗略想法。

真的，我为我的故事使用了一些不太正式的东西：标题、简短描述和一些关于如何演示的解释。我还添加了一些优先级值（对产品所有者很重要）和对工作量的粗略估计。最有用的部分可能是如何演示，因为它有助于编写测试（在必要时打破故事之后，但如果可能的话，我也更喜欢保持故事简短以避免打破它们的需要）。我也尽量不把故事分解成任务，而是分解成更小的故事。任务通常过多地涉及您将如何做某事，您应该专注于您想要的结果。

在您的情况下，肯定会有其他故事，其中有一天会是关于身份验证的，但这不应该阻止您现在编写代码页面。只要一步一步地进行，让你的故事保持简单（你有测试，以后重构很容易），你很快就会感觉到什么对你有用。

你应该看看Trenches 的优秀 Book Scrum 和 XP，看看他们是如何做到的。

于 2010-09-09T20:10:56.057 回答
4

词组

“作为内容作者 ，我需要能够创建新闻文章 ，以便它们可以用来吸引用户访问网站”

不是故事。它是故事的摘要，适合卡片或电子表格列，并代表故事，因此您可以记住您正在谈论的故事。整个故事由三部分组成——卡片、对话和确认——这里你需要的部分是对话。

与团队中的用户或用户代表交谈，了解它的真正含义。

于 2010-09-09T22:15:45.353 回答
3

作为一部分并不意味着身份验证或授权。以同样的方式，您可以将用户故事编写为：

  • 作为一个新访客...
  • 作为回头客...

这是否意味着必须对访问者进行身份验证？访问者有什么授权？用户故事不应包含“隐藏需求”。如果您需要身份验证和授权，只需为此创建用户故事。

作为一部分指定应用程序中的用户角色类型。每个角色都有一些特殊的需求和要求，并出于不同的原因使用应用程序。在开始编写用户故事之前，您应该尝试收集角色。

用户故事不仅仅包含描述。它应该包含在流程的不同阶段添加的附加信息。

  • 定义格式的描述。您不必使用 As a ... I need ... 这样 ... 如果您认为它不符合您的需求，但您应该对所有故事使用相同的格式。
  • DoD - 完成的定义也称为验收标准。这应该与描述一起收集。没有 DoD 的用户故事是没有用的。国防部说开发人员有关用户故事的附加信息。用户故事只有在满足 DoD 时才算完成。您还可以根据这些标准创建自动化验收测试。
  • 客户设置的优先级 - 这将帮助您按重要性对用户故事进行排序
  • 估计 - 由团队制作。估计不准确，应该基于用户故事之间的比较。通常的估计单位是抽象故事点或 T 恤尺寸。

另请注意，并非每个用户故事都直接分解为任务。您可以拥有大型高级用户故事，这些用户故事将首先分解为较小的用户故事。我们称这样的用户故事为史诗。

于 2010-09-09T22:24:40.157 回答
1

您最初可以假设用户有权进行更改，然后稍后将授权作为单独的故事处理（当它们成为您积压工作中最重要的项目时）。

这样做的好处是可以将您的故事的范围保持在较小的范围内，从而使它们更易于使用，并且还可以让初始故事更早地处于可能部署的状态。

于 2010-09-09T19:31:12.063 回答
1

至少我会为：

  1. 验证用户
  2. 注册作者/编辑...或注册用户，分配权限

如果没有人知道如何处理故事级别的那些，我会与他们交谈/拿起电话/启动即时通讯并与他们核实。您可以在较低级别为您不想实现的功能进行 TDD，但是端到端故事的任何测试自动化都应该通过用户所做的事情。

这些故事的问题是您可能正在考虑基础任务，但从用户的角度来看，您最终可能会发现客户想要更多具有 openid/login 和现有帐户感觉的博客。毕竟它是敏捷的，它是它滚动/完整通信的方式，而不是在大型分析+设计阶段定义的全部。

当用户名/密码/哈希/等甚至可能与项目无关时，花一秒钟的时间去思考是没有意义的。

不管你做什么，保持简单。

附言。它都是故事不可或缺的一部分，它恰好取决于其他故事的到位。

于 2010-09-09T20:53:06.320 回答