我正在尝试更好地管理我的项目，所以我正在尝试应用scrum的一些（最终所有）功能。
具体看user stories高级格式似乎是：
作为用户，我可以功能描述
或
神器是做某事
我如何撰写“升级数据库”？
只是升级数据库吗？
我认为我被抛弃了，因为没有特定的演员/客户，而且客户是IT部门。
答案 0 :(得分：34)
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
答案 1 :(得分：15)
Scrum不是很规范，Scrum中有 nothing 强制您将用户故事用于产品Backlog项目（PBI）。您绝对可以在不将捕获需求/功能作为用户故事的情况下执行Scrum，用户故事只是一种方法。实际上，故事确实适用于许多团队，尤其是Web开发团队，但这并不意味着它们适用于所有情况和每个项目（很多项目都是Web开发但不是全部，就像您的情况一样）。关于使用故事没有达成共识。
也就是说，用户故事的推荐模板实际上是 作为＆lt; role＆gt;，我想＆lt; action＆gt;这样＆lt; benefits＆gt; 。我并不是说挑剔但是，如果你选择使用故事，我会热烈地建议你按原样使用它，而不是删除任何部分。首先，使用角色帮助（同一个用户/个人可以拥有多个角色）来发现故事。然后指定好处对于揭示故事的商业价值以确定其优先级非常重要。关于价值，您应该将其视为最终用户/客户（“戴上客户眼镜”--Mary Poppendieck）。表达好处并不总是那么容易，但有些工具可能会有所帮助，我首选的工具是5 whys（用于根本原因分析）。
在您的情况下，这可能导致类似：作为IT部门，我希望升级数据库，以便用户可以从应用程序的最新功能中受益，并[做得更好|拥有更好的用户体验]（不是很满意，但使用5个为什么）。
但我个人并不认为用户故事是技术任务的最佳媒介，即使明显possible使用它们，如果它们有自己的优势。从理论上讲，故事捕捉的是本质，而不是细节，应该是对讨论的支持。我可能错了，但我没有发现技术任务为讨论和创造提供了很大的空间。所以，根据谁会阅读它们，应该传达什么，我可能会使用或不使用它们。另一种选择可能是将故事与另一种形式主义混合在一起用于您的PBI。正如我所说，关键是不要使用故事，重点是列出优先级和估计项。
答案 2 :(得分：6)
升级数据库可能是实现另一个为用户带来直接价值的故事所涉及的任务之一，例如我作为用户可以向我的栏添加新的foo < / em>的
如果将 foo 添加到栏需要在幕后进行数据库升级，那么您将在实现该用户素材时加入该工作。
用户故事以这种方式措辞，以帮助确保任何工作以某种方式直接使最终用户受益。
答案 3 :(得分：4)
这就是用户故事如此之大的原因。
升级数据库给最终用户带来了哪些好处？没有？然后不要花时间和金钱去做。花费时间和金钱提供能够为最终用户带来价值的东西。
如果有的话？然后从另一个角度考虑一下。也许只有在拥有数据库软件的x版本时才能实现新功能？在故事的依赖关系中，您可以提到提供此功能所需的数据库升级。
;唐博士为了它而升级。确保升级为您的客户增加实际价值。
答案 4 :(得分：3)
通常，PB中的技术任务不受欢迎，因为它们很少直接为客户提供业务价值。这就是为什么用户故事很受欢迎，因为它们迫使你去思考故事的商业价值，以及它被传递给谁。
那么，为什么要升级数据库？您能否在升级时确定业务价值，为什么产品负责人同意让您升级数据库而不是构建新功能？
是否因为一项新功能可以使您的应用程序中的某些内容成为可能或更容易？在这种情况下，某些东西应该是PB项目，数据库升级应该是该故事中的任务。如果您已经在PB上有可以从升级中受益的故事，那么您应该增加一个或多个故事的估计值，并将升级作为技术任务添加到故事中。
是否因为数据库的供应商正在切断旧版本的支持？在这种情况下，您可以升级为故事;类似于“作为部门经理，我希望确保我们能够支持所有软件，以便在出现问题时业务的连续性不会受到影响”。尽管如此，即便如此。一般来说，这种原因并不是项目的一部分，除非项目已经持续了很长时间，系统软件才会失去支持。
是为了表现吗？然后，故事应该是关于应用程序性能的某些方面，需要改进以提供业务价值。有点像“作为CSR我需要能够在合理的时间内检索客户信息，以便电话上的客户对我们的服务感到满意”。然后升级成为该故事下的任务。
是出于某种完全技术原因吗？如果您无法确定升级将如何提供业务价值，那么您为什么要这样做呢？为什么产品负责人会为Sprint选择它？
答案 5 :(得分：1)
它只是“升级数据库”或者“当安装新版本时，必须有一种方法来迁移现有数据库”。如果您已经了解有关此步骤的更多详细信息，请将其包含在内。但这个故事主要是为了确保某些东西不被遗忘;这不是详细的。
稍后，当你开始实现这个故事时，你可以充实它（哪些表，我们需要一个或多个备份，是否有后退场景等）。
OTOH，如果项目更复杂，这可能会成为一个“标签”，就像一个必须附加到许多故事的便利贴。这意味着您必须将此作为“子故事”包含在所有更改数据库的故事中。正如您所看到的，这些“项目跨越的故事”使用敏捷方法有点难以跟踪。
答案 6 :(得分：0)
基础设施故事不需要遵循规定的故事模板。只需写下需要做的事情并据此估算
答案 7 :(得分：0)
怎么样：
作为应用程序支持人员，我希望使用最新版本的数据库，因为它更可靠/更安全/无论。
你甚至可以像这样表达重构：
作为应用程序开发人员，我希望所有数据类都在一个模块中，这样我就可以非常快速地向应用添加新字段。
理想情况下，你不希望所有的故事都有1个是开发者，但有一些是有道理的（锐化你的斧头而不是削减树木等等。）