问题标签 [user-stories]

是否有可能或应该如何使用敏捷开发流程（Scrum/XP）并编写用户故事来开发纯技术编程库（例如 Spring 或游戏引擎）？

我正在寻找有关此模板的一些背景信息（需要引用报告）。谁是带着众所周知的模板而来的人？

“作为[用户]，我想要[功能]，所以[价值]”</p>

我一直在寻找答案，但没有人给出适当的引用。

我有一组用户故事和一组业务规则（主要是约束我的合规要求的法律）。在敏捷 SDLC 中，我不确定这些“规则”在我的用户故事中的位置。

例如，像这样的用户故事：

作为一名医生，我想添加患者信息以创建新的患者文件。

和这样的规则：

必须在每位患者的记录中输入以下信息： (a) 患者： (i) 姓名和名字；(ii) 地址；(iii) 出生日期；(iv) 性别；

这两个显然结合在一起，但我怎样才能将它们联系起来呢？作为我的用户故事中的测试验收定义？另一个用户故事？

好的，所以我刚刚开始尝试将 BDD 用于我们正在进行的一些新开发，并且我为日志查看器功能写了一个这样的故事：

故事：用户查看工作流执行日志

在某些情况下，例如给定用户在单击查看日志时对日志查看器具有适当的安全权限，然后他被授予对日志查看器的访问权限

现在我知道我们需要一种对日志进行排序和过滤的方法。这是否意味着另一个故事，像这样？

还是第一个故事的场景中有一些更“简单”的功能？像这样...

场景二：

我知道这可能很难回答，因为可能没有一种正确的方法可以做到这一点，但我仍然对如何拆分这些事情感到有些困惑。

我正在尝试学习如何在我们的开发过程中使用 BDD，有时我最终会写一些暗示 UI 设计的东西，因此对于全新的开发或新功能，UI 并不总是存在。

例如，如果我在“单击列标题时”的场景中这样说，则意味着此功能基于某种表格或网格，但此时我们仍然只是编写用户故事，因此没有 UI然而。

这让我很困惑，不知道我们在这个过程中的哪个阶段提出了 UI 设计？

请记住，我只阅读过有关 BDD 的文章，我认为这会对我们的团队有很大帮助，但在这方面还是很新的！谢谢！

您如何处理像这样具有长链的用户故事/验收测试，然后/何时混合在一起？是否最好将其拆分为单独的验收测试，其中一个测试对话框出现，然后第二个测试对话框显示后的行为？

应用的用户故事一书包含讨论角色的单页。书中人物角色的定义是：

角色是用户角色的虚构表示。

它进一步讨论了角色的定义：

创建角色需要的不仅仅是为用户角色添加名称。一个角色应该被充分描述，团队中的每个人都觉得他们知道这个角色。

它还建议在 Internet 或杂志上找到一张照片并将这张照片用作角色，以便每个人都可以清楚地想象角色与应用程序一起工作。

行。所有这些想法听起来都不错。为用户角色定义角色可能很有趣，但值得吗？使用它们时是否有任何真实或可衡量的质量或提高的效率？

你有什么好的例子可以说明角色模型真正帮助开发团队吗？你在用户故事中使用角色吗？

编辑：

我在MSDN中找到了关于角色的好文章。

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

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

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

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

我的方法是，

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

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

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

非常感谢您的所有意见。

干杯。

我即将在我们公司启动一个试点项目，以引入敏捷实践，包括使用用户故事。在阅读了 Mike Cohn 的两本书，特别是敏捷估计和规划以及应用用户故事之后，我现在对如何进行有了更清晰的认识。我有信心在练习中改进我们的技术。

然而，有一件事并不能说服我。在这篇博文中， Mike Cohn 定义了一种特定类型的用户故事，他称之为约束，可以用来定义所谓的非功能性需求。就我个人而言，我不喜欢约束这个词，甚至不喜欢使用经典模板“作为......，我想要......，所以......”。

相反，我会尝试让客户始终在卡片上写下，也许使用上面的模板，尼克·罗赞斯基和伊恩·伍兹在他们出色的著作《软件系统架构》中所称的那些架构原则：

“架构原则是指导架构定义的信念、方法或意图的陈述。”

（他们还将这些原则分为业务原则和技术原则，我认为我们不应该关心这种差异。）

我想对这些原则卡片做的是将它们放在我们的待办事项卡片板旁边，以便在用户故事定义和计划活动期间始终存在它们。我还鼓励客户和开发人员在每次他们认为卡片可以作为团队提醒有用的时候拿起它们并将它们放在迭代板旁边。

你有没有尝试过类似的方法？你有什么理由不鼓励它吗？你对这个问题有什么建议吗？

我想知道关于使用用户故事来描述自动化、计划或反应性功能的想法是什么。例如，当您有类似订单履行流程的事情时，您会怎么做，该流程涉及从队列中提取订单、准备“填写订单表格”、将表格发送到订单处理中心，然后等待来自处理中心，例如“订单已履行”或“订单履行错误：原因...”等。请记住，在整个过程中唯一的用户干预将是输入订单时。人们总是会争辩说，履行过程可以从订单输入故事中暗示出来，或者它是一个实施细节，但在我看来，履行过程太大了，不能简单地将其视为订单输入用户故事或实施细节中的暗示。感觉应该也应该将成就本身描述为一个故事。

特别是，我对为自动化、计划或反应性功能编写用户故事感兴趣的方面应该从谁的角度来描述？鉴于我们正在使用类似“作为[角色]，我想要[功能]以便[目的]”这样的故事格式，故事的“作为[角色]”部分中的角色是什么，以及什么是目的在故事的“所以[目的]”部分？功能通常很清楚，但作用和目的似乎有点相对。例如，我可以使用该系统作为我的参考点并编写类似“作为订单履行系统/代理，我希望能够从履行队列中提取订单，准备填写订单表格并将其发送到订单处理中心，以便可以完成订单”。或者，我可以从业务的角度来看事情，并写下类似“作为接单员，我希望能够处理客户输入的订单，以便我能够履行对客户的责任，并给他们他们想要的东西想要”（或类似的东西）。但是，我也可以从客户的角度写这个，并说“作为客户，我希望我的订单条目得到处理/履行，以便我可以收到我想要的东西”。

我意识到对于谁的观点是有效的或更有用的观点可能没有一个最终答案。我相信我会得到很多“视情况而定”的回复。尽管如此，我还是很想听听其他人在这种情况下做了什么，或者是否有人知道专门针对这些类型场景的任何建议、指导或实践。