我正在尝试更好地管理我的项目，因此我正在考虑尝试应用scrum的一些（最终全部）功能。
具体来看用户故事，高级格式似乎是：
作为用户，我可以进行功能描述
或者
工件正在做某事
我将如何编写“升级数据库”？
它只是升级数据库吗？
我认为我被抛弃了，因为没有特定的参与者/客户，而且客户是 IT 部门。
问问题
21579 次
8 回答
35
AS A [person/role]
I NEED TO [do something]
SO THAT [provides business value].
对于您的示例，用户故事可能如下所示：
AS A user of the XYZ application
I NEED TO get reports of ABC faster
SO THAT we can increase our conversion rates.
ACCEPTANCE CRITERIA - The database reliably completes transactions on average in 2 seconds.
我添加了一个验收标准，因为没有这个您将永远不知道工作何时完成。现在，您有一个升级数据库的业务案例。这个故事将被分解成一个角色是 IT 部门或 DBA 的故事，如下所示：
AS AN administrator for the database server
I NEED TO upgrade to the latest version of FancyDB 11.7
SO THAT we can improve the average transaction time for XYZ users to 2 seconds.
ACCEPTANCE CRITERIA - the new version starts successfully, the XYZ developers sign off on the test installation of 11.7, data migration is successful, we have cut over to the new db
当故事分解被添加到您的工具箱中时，故事必须从用户是业务的真正组成部分开始，并且“这样”会导致真正的业务价值。然后将故事分解为一个或多个故事，内部用户在其中做事“以便”真正的用户获得所需的好处。
这里有几篇关于故事分解的文章：
http://jpattonassociates.com/the_shrinking_story/
http://old.cognitive-edge.com/wp-content/uploads/1999/11/56-1999-11-Paradox-of-Story.pdf
于 2009-11-10T11:36:38.390 回答
15
Scrum 不是很规范， Scrum 中没有任何东西会强迫您将用户故事用于产品待办事项 (PBI)。您绝对可以在不将需求/功能捕获为用户故事的情况下进行 Scrum，用户故事只是实现它的一种方式。实际上，故事确实适用于许多团队，尤其是 Web 开发团队，但这并不意味着它们适用于所有情况和每个项目（许多项目是 Web 开发，但不是全部，就像你的情况一样）。关于使用故事没有共识。
也就是说，用户故事的推荐模板实际上是作为 <role>，我想 <action> 以便 <benefits>。我并不是要挑剔，但是，如果您选择使用故事，我强烈建议您按原样使用它，而不要删除任何部分。首先，使用角色确实有助于发现故事（同一个用户/人可以有多个角色）。然后指定好处对于揭示故事的商业价值以便很好地确定它们的优先级非常重要。关于价值，您应该将其视为最终用户/客户（“戴上客户眼镜”--Mary Poppendieck）。表达好处并不总是那么容易，但一些工具可能会有所帮助，我更喜欢的是5 个为什么（用于根本原因分析）。
在您的情况下，这可能会导致以下情况：作为 IT 部门，我希望升级数据库，以便用户可以从应用程序的最新功能中受益并[做得更好|拥有更好的用户体验]（不是不过非常令人满意，请使用 5 个为什么）。
但就我个人而言，我并不认为用户故事是技术任务的最佳媒介，即使显然可以使用它们并且它们有自己的优势。从理论上讲，故事抓住了本质，而不是细节，应该成为讨论的支持。我可能错了，但我发现技术任务并没有提供太多讨论和创造力的空间。因此，取决于谁会阅读它们，应该传达什么，我可能会使用它们或不使用它们。另一种选择可能是将故事与 PBI 的另一种形式相结合。正如我所说，重点不是使用故事，重点是列出优先事项和估计项目。
于 2009-11-10T12:34:26.457 回答
6
升级数据库可能是实现另一个给用户带来直接价值的故事所涉及的任务之一，例如，我作为用户可以向我的 bar 添加一个新的 foo。
如果将foo添加到bar需要在后台升级数据库，那么您将在实现该用户故事时包含该工作。
用户故事以这种方式措辞有助于确保任何工作以某种方式直接使最终用户受益。
于 2009-11-10T11:00:04.853 回答
4
这就是为什么用户故事如此出色的最前沿。
升级数据库给最终用户带来什么好处？没有任何？然后不要花时间和金钱去做。花时间和金钱为最终用户提供价值。
如果是这样？然后换个角度想。也许您只有在拥有 x 版数据库软件时才能实现新功能？在故事的依赖中，您可以提到提供此功能所需的数据库升级。
tl; dr不要仅仅为了它而升级。确保升级为您的客户增加有形价值。
于 2015-01-16T14:32:49.090 回答
3
通常，PB 中的技术任务不受欢迎，因为它们很少直接向客户提供业务价值。这就是用户故事受欢迎的原因，因为它们迫使您思考故事的商业价值，以及故事的交付对象。
那么，为什么要升级数据库？你能确定升级它的商业价值吗？为什么产品负责人应该同意让你升级数据库而不是构建新功能？
是因为有一个新特性可以让你在应用程序中做某事变得可能或者更容易吗？在这种情况下，应该是 PB 项目，而数据库升级应该是该故事中的一项任务。如果您在 PB 上已经有可以从升级中受益的故事，那么您应该增加对其中一个或多个故事的估计，并将升级作为技术任务添加到故事中。
是因为数据库的供应商正在切断对旧版本的支持吗？在这种情况下，您可以将升级作为故事；例如，“作为部门经理，我想确保我们对所有软件都有支持，这样如果出现问题，业务的连续性就不会受到威胁”。不过，即便如此。一般来说，这种原因并不是项目的一部分，除非项目已经进行了很长时间，系统软件停止支持。
是为了表演吗？然后故事应该是关于需要改进以提供业务价值的应用程序性能的某些方面。例如，“作为 CSR，我需要能够在合理的时间内检索客户信息，以便电话中的客户对我们的服务感到满意”。然后升级成为那个故事下的任务。
是出于某种完全的技术原因吗？如果您无法确定升级将如何带来业务价值，那您为什么要这样做？为什么产品负责人会选择它进行 Sprint？
于 2014-10-19T20:22:05.633 回答
1
它只是“升级数据库”或者“安装新版本时，必须有办法迁移现有数据库”。如果您已经了解有关此步骤的更多详细信息，请包含它们。但这个故事的存在主要是为了确保不会忘记某些事情。不详。
稍后，当你开始实现这个故事时，你可以充实它（哪些表，我们是否需要一个或多个备份，是否有备用方案等）。
OTOH，如果项目更复杂，这可以成为一个“标签”，就像必须附加到许多故事的便利贴一样。这意味着您必须将此作为“子故事”包含在所有更改数据库的故事中。如您所见，这些“跨越项目的故事”有点难以用敏捷方法跟踪。
于 2009-11-10T11:00:52.120 回答
0
基础架构故事不需要遵循规定的故事模板。只需写下需要做的事情并做出相应的估计
于 2014-10-23T08:16:20.347 回答
0
怎么样：
作为应用程序支持人员，我希望使用最新版本的数据库，因为它更可靠/更安全/无论如何。
你甚至可以这样说重构：
作为应用程序开发人员，我希望将所有数据类放在一个模块中，以便我可以非常快速地将新字段添加到应用程序中。
- 谁受益
- 你想做什么
- 有什么好处
理想情况下，您不希望所有故事都有 1 位开发人员，但有一些是有意义的（磨砺您的斧头而不是砍伐树木等等）。
于 2015-02-19T04:35:05.073 回答