问题标签 [user-stories]

我们进行分布式敏捷开发，并且真的可以在墙上/板上提供类似故事卡的解决方案，仅在您可以轻松拖放它们的网页上。有什么建议么？谢谢。

我正在尝试更好地管理我的项目，因此我正在考虑尝试应用scrum的一些（最终全部）功能。

具体来看用户故事，高级格式似乎是：

作为用户，我可以进行功能描述

或者

工件正在做某事

我将如何编写“升级数据库”？

它只是升级数据库吗？

我认为我被抛弃了，因为没有特定的参与者/客户，而且客户是 IT 部门。

我想一个功能可能是“信用卡授权”，而用户故事可能是“为贝宝授权信用卡”。

那么，用户故事是功能的子集吗？

我来自 XP 背景。我非常了解这个过程，并且有扎实的工作经验。我发现它是开发软件的最佳方式。

我发现自己处于某种流程医生的位置，这产生了很多自我检查和对自己理解的重新评估。

我听到的一个很常见的事情是，有些作品不能变成故事。我个人不相信这一点。借口包括

1. 它太大了（开发人员在 5 周结束之前将没有任何东西可以显示）。
2. 这是一个复杂的算法或抽象概念（将需要 5 周的时间来编写并且什么都没有显示）。

这个问题是为了获得提示、提示或建议。

我正在寻找关于如何解决这些和类似的感知问题的提示、技巧和建议（如果你能想到的话，还有更多）。

我将标记关于如何绕过不会写故事的用户/开发人员的信息最多的答案，并解决他们为什么不写故事的许多借口（我只列出了几个，还有更多）。

在尝试将敏捷原则应用到我们的开发过程中，特别是 Scrum 原则和类似 XP 的用户故事时，我们遇到了架构方面的问题。

也许我们仍然过多地与以架构为中心的开发联系在一起，但是我们正试图保持一个强大的基于组件的开发，并与敏捷建模原则相结合。我们的目标是预先进行小型设计，在开发过程中易于演变。

我正在寻找的东西可以让我将关于我的架构和其中的组件的积压故事放入我的积压故事中：开发故事，而不仅仅是使用故事。系统故事可能是一种不同类型的用户故事，它讲述的内容与业务价值并不严格相关，而是与系统的架构和质量问题相关联。

编辑： 我发现了奥尔堡大学关于“开发者故事”的这项研究。

你有什么经验、想法或反对意见吗？

先感谢您！（这是我的第一个问题！：D）

我的公司使用 Jira 来存储需求，这些需求以用户故事（“作为……我想要……所以……”）的形式编写，并在子任务中包含详细信息（“给定……当 .. ……然后……”）。

我编写需求，通常是在开发人员之前进行迭代。

我倾向于先在文字处理器中起草我的要求，然后再将它们放入 Jira。我喜欢这种灵活性，因为我正在寻找组织信息的最佳方式，从一个故事跳到另一个故事，在我找出最清晰的措辞时使用搜索和替换等。

虽然文字处理器大纲对此很有帮助，但它不太擅长跟踪问题链接：依赖关系和相关要求。

那么，任何人都可以推荐一个用于编写故事和任务的好工具，它可以让我在写作时绘制关系图？ 我一直在考虑处理概念映射的东西（尽管不是思维导图，通常仅限于 1 个中心概念）。这仅用于我的个人创作；我不需要项目管理系统。

提前致谢。

更新：发布后，我开始想知道 TiddlyWiki。考虑到它的链接方法，这不是完全正确的工具，但似乎是正确的方向......这条静脉是否激发了任何想法？

我们使用 Scrum。当我们发现用户故事的粒度不足以捕捉完成 sprint 所需的工作时，我们会在 sprint 期间遇到问题。

特别是，我们发现提供给我们的 UI 线框包含的复杂性比原始故事所暗示的要复杂得多（例如，出于可用性原因复制了功能）。这导致燃尽图看起来像是在冲刺的最后一天完成的。

我们在每个 2 周 sprint 开始的星期一花时间回顾项目团队创建的故事，在此期间，我们通常会稍微改进故事并将它们分解为任务，估计每个时间以创建燃尽图图表。在这一天里，我们感觉没有时间有意义地提高故事的质量。

如何最好地打破我们冲刺的故事不完整/不足的循环？

这是项目团队一开始就没有充分确定故事的失败，还是我们（即开发团队）应该承担一些责任？

在使用故事时，处理细微界面调整的首选方法是什么，例如“将鼠标悬停在菜单上时使菜单颜色变浅”。

我的第一个想法是将其视为错误。将其粘贴在索引卡上并将其添加到错误文件中，以便安排到即将到来的迭代中。

我只是想知道是否有其他人有他们会推荐的替代品

在 Scrum 团队中，在继续之前完成一个故事有多重要？

我们的 Scrum Master 非常教条地在继续之前完成一个故事。我可以看到，在这种情况下，开发似乎更加“受控”，而且 Scrum Master 可以非常准确地了解团队成员在任​​何给定时间的工作内容......但我对这真正购买的东西感兴趣我们？

显然，Scrum Master 希望尽量减少燃尽与现实的差异，以避免冲刺结束时的冲击——但如果冲刺持续两周，燃尽会持续更新，并且在站立会议上传达阻碍者——任何这样的分歧都会受 sprint 长度的限制，并通过通常的渠道（即站立或单独与 scrum master 交谈）在 sprint 中期可见。任何剩余的问题都可以在每两周一次的回顾中处理。

提出这个问题的原因是，我似乎发现我的工作效率最高，方法是在我认为合适的任何给定时间保持说 2 个（或 3 个，如果一个特别容易的话）故事在进行中。这似乎有助于帮助完成任务的潜意识背景思想。如果有几个故事相关，它还可以让我更好地理解大局。

我们的故事通常需要一两天的工作量。

那么，一次处理几个故事是否令人不悦，如果是这样，一次一个故事会给你带来什么？

据我了解，Scrum backlog 由一系列代表最终用户的故事组成，这些故事进一步分解为功能。

如果是这种情况，所有与故事没有真正联系但仍然有用的幕后功能在哪里？

例如，假设我正在制作一个对硬盘内容进行编目的应用程序。一个故事不需要它，但在每个文件上都有一个 md5 散列将是标记重复项的一个很好的功能。