问题标签 [user-stories]

在回答项目的文档？, Chris Ballance 回答说，“用户故事”和“燃尽图”是对开发人员最有用的两种项目文档类型。

我的问题是，你知道我可以看到（例如在互联网上或在书中）这些类型的文档的任何好的例子吗？

如果可能的话，我很乐意看到很多例子，包括：

• 小/短/简单的例子
• 大/长/复杂的例子
• 著名的例子
• 高质量的例子

对于谷歌来说，我发现这不是一个简单的话题：我发现很多关于它的文章，但展示它的演示较少。

我们使用 Scrum 方法。假设产品所有者想要一个允许用户搜索网站内容的新功能。

总工作量为 8 分，这些将是用户故事：

• 用户可以输入搜索词（0分）
• 搜索结果显示给用户（8分）

我想更深入地了解开发人员的进度。但是，我无法进一步分解这些故事。

然而，我可以重写这些故事。我很不情愿，因为这些故事都是技术故事。

• 添加搜索文本框（0 分）
• 在数据库中创建索引表（0 分）
• 确保在数据 ABC 更改时更新索引表（3 分）
• 确保在数据 XYZ 更改时更新索引表（2 分）
• 从数据库中获取结果（1 分）
• 为每个搜索结果撰写正确的网址（2 分）

你如何处理这些情况？

就故事板上使用的良好颜色编码而言，您会推荐什么？

根据您的经验，这是一个好的模式吗？
http://maxheapsize.com/static/ScrumBoardCheatSheet.pdf
最标准的颜色编码是什么？

我即将第一次使用 BDD（行为驱动设计），并试图习惯这种不同的解决问题的方式。

您能否提供一些您会为使用 BDD 的简单登录应用程序编写的故事/场景？

例如，从我读过的内容来看，这似乎很好：

当用户输入无效的用户名/密码时，会显示错误消息。

相对于：

通过在数据库中搜索匹配记录来验证 ID 和密码。

你如何组织用户故事？

我为 Web 应用程序所做的是：

为“索引”之类的网页制作标题，然后列出用户可以在此页面上进行的所有商店。

我继续阅读所有页面。

这是最有效的方法吗？

“我们需要显示与当前文档相关的报价。”

这个用户故事将导致我们的许多子系统被修改，它或多或少是 4-5 个 sprint 长度。将其拆分为子故事是不可能的，因为修改没有商业价值。但是，在第 5 个 sprint 中，会有一个商业价值。

你有什么建议？我们将如何创造商业价值，在每个 sprint 中向我们的客户展示它，并让我们的客户在每个 sprint 中优先考虑工作？

我工作中的几个人聚集在一起组成了一个小组，其目标是分析实施一些敏捷软件开发/项目管理原则的好处。

作为一名开发人员，我在用户故事中看到了巨大的好处。我们正在寻找一个信息辐射器，可用于监控当前版本的各个阶段并规划未来的版本。我想在这个过程中使用用户故事。

现在，我们正在使用 Bugzilla 进行问题跟踪。大多数发布计划都是使用该系统中的错误完成的。Bugzilla 的使用可能不会改变。它以合适的成本（0 美元）提供了我们所需的大部分内容。

一个问题是用户故事与错误的映射。发布管理目前使用错误编号完成。问题是一个用户故事可能包含三个错误，反之亦然。

在单个用户故事有多个报告的错误的情况下，一个想法是有一个用户故事错误来说明故事并设置对构成该故事的子错误的依赖关系。我担心这最终可能会变得过于复杂，并在利益相关者、开发人员和 QA 之间造成混淆。此外，它会使 Bugzilla 变得相当混乱。

有人已经走过这条路了吗？如果是这样，你做了什么？我应该放弃在 Bugzilla 中使用用户故事的想法吗？有没有更简单的解决方案？

任何想法将不胜感激。

我们开始了一个将使用 Scrum/XP 管理的项目。为了评估目的，我们预先编写了整个产品 backlog。我们确保所有故事都以客户为中心，并通过以下方式对其进行评估

• 故事商业价值：莫斯科技术 - 必须、应该、可以、不会/不会实现这个
• 故事工作量/复杂度（= 故事点数）：1、2、3、5、8、13、21、100 - 与故事复杂度/工作量有关，而不是理想的持续时间

100 个故事点可能有一些带有会/不会有的故事，因为它们实际上是更大的复杂故事，如果需要，稍后会分解。

计算的故事重要性基于不重叠莫斯科故事的价值和努力。

但是，如果没有 100 点故事，我们的故事到目前为止（也被分解）的复杂度在 2 到 8 之间，我们认为这是避免微观管理的合适故事大小。但有些故事变得相互关联或相互依赖。如果先完成，我们的故事可能会花费更多，如果在他们之前完成其他故事，则可能会花费更少。

问题
是否可以在开发过程中稍后调整故事点，就像我们可以对故事任务做的那样，我们可以重新评估它们、添加新的、删除现有的，或者故事不是这种情况？因为改变它们的复杂性，也会改变基于计划速度的结束日期估计。在这种情况下，最佳做法是什么？

由于我们是一家小公司，我既是项目经理又是开发人员。我为客户创建的规范包含许多用于描述和定义项目的元素，包括用户故事以及我认为需要包含的任何其他元素以向客户定义项目（例如线框、用户流、站点地图等）。

如果功能规范“完全从用户的角度描述产品将如何工作。它不关心事情是如何实现的。它谈论功能。“。那么有没有人认为使用用户故事来定义网站的功能规范有什么问题呢？真的有人用这种方式做功能规范吗？

真的，我正在尝试提高我的游戏水平，并且想知道这种方法是否适用于可能对功能规范应包含的内容有更严格想法的大客户，因此可能需要正式的方法。目前，我们的客户肯定对我们制作文档的方法反应良好。

我很想听听专业从事项目管理的人对此有何看法。

因此，如果用户故事很模糊，例如：

作为销售代表，我想获取联系信息，以便稍后跟进。

我什至不确定这是否是一个有效的用户故事，但我确信它足够接近。

然后是实现该用户故事的细节/任务。而且我确信“销售代表应该能够从一个文本框切换到另一个文本框。” 是要求之一。我们如何捕捉/跟踪这个？这是用户故事的一部分还是需要单独考虑？