我们目前使用JIRA来跟踪我们的开发工作。我的管理层希望将所有内容格式化并归类为“用户故事”，包括与非软件开发相关的任务。例如：

“作为测试经理，我可以仅使用自动测试而不进行手动测试来对应用程序进行测试，以便可以尽可能高效地测试应用程序吗？

验收标准：1.将50个现有的手动测试转换为全自动测试。2.测试必须在不到1小时的时间内执行”

如果要在支持软件开发过程的工作中使用“用户故事”，而不是由程序员来做，并且不会直接产生可交付的代码，那么我想从社区中了解。还是应该对它进行不同的处理/分类（例如，在JIRA中）？

2011年6月7日更新-措辞更正的问题集中在“用户故事”一词。

是

任何利益相关者，任何改进系统的功能

[让纯粹主义者降票开始！]

“我的管理层希望对所有事情都使用敏捷，包括与非软件开发相关的任务。”

但这并不意味着编写用户故事的所有功能。

如果您想为每个功能编写用户案例，则不一定要敏捷。您只是在为每个功能编写用户案例。

用户故事！=敏捷。

用户故事是一种收集和理解需求的方法。如果需要，它们可以以完美的瀑布方式使用。有人这样做。

敏捷是一种管理项目的方式。您可以在敏捷项目中使用或不使用用户故事。

同样，用于管理技术债务和内部任务的用户故事与敏捷无关。

许多人都非常乐于在冲刺中添加“技术”或“支持”功能，而不会浪费时间为纯粹内部的，有限增值的，非涉众的用户编写虚假的“用户故事”。

如果质量检查人员不了解他们的故事，那么会有多少实际业务损失？

如果真正的利益相关者不了解他们的故事，那么企业将蒙受巨大损失。

这对我来说没有意义。本质上，“用户故事”就是用户故事，不是项目经理故事，不是开发人员故事，也不是质量保证工程师故事。

在这一点上，软件是：

1. 可定义的
2. 可测

流程改进是开放式的，通常是主观的。

验收标准：1.对测试1的改进（按x / y）

您如何衡量测试的改进？没有可定义的合同。

在不相关的注释上，我真诚地希望上面给出的示例，

作为测试经理，我可以仅使用自动测试而不进行手动测试来执行应用程序测试，以便可以尽可能高效地测试应用程序吗？

……只是一个例子，因为它有太多错误，我什至无法开始描述。

可以用类似于用户故事的方式来处理技术债务，但这有时会变得很丑陋。例如，如果有一个这样的故事：“作为开发人员，我想进行工作单元测试，以便我对测试有信心，以验证其他更改是否会破坏某些东西”，这对产品所有者没有太多价值。但是对于团队来说，将其作为自己的重构工作（这是冲刺工作的一部分）来做可能是一个好主意。

我喜欢将任务与用户故事分开的想法，因为这些任务不会像要显示给系统的最终用户那样显示，但是可以帮助改善维护和维护时间开发一些新功能。根据总的任务数量，某些任务可能需要2分钟，而其他任务可能需要2周，因此总积分的高低决定了团队是否需要冲刺并且不添加新功能但可以工作我去过几次工作，负责清理工作。

以我的愚见，是的，您可以将用户案例用于非软件开发项目，而不仅仅是过程改进任务。例如，三年前，我是朋友婚礼上的伴郎，我使用敏捷方法论和用户故事来计划婚礼。我们必须完成的所有任务都以用户故事的形式编写，并包含每个用户故事的角色，意图，理由和成功标准。参与的各方都参加了我们的日常讨论会，讨论我们前一天的工作以及当天的工作。每个人的地理位置都很分散，因此我们召开了电话会议，以进行日常的Scrum会议，Sprint计划，回顾，故事写作和评估会议...。我们总共进行了6次冲刺（3个月），婚礼取得了惊人的成功，没有留下任何石头。

当您将内部“用户故事”与实际用户故事组合在一起时，您将遇到一个严重的问题。

请重读尽可能多的“利益相关者”定义。

http://en.wikipedia.org/wiki/Scrum_（开发）

http://wiki.openbravo.com/wiki/Scrum/Pigs_and_Chicken

http://www.testertroubles.com/2009/04/scrum-pigs-and-chickens.html

非常非常仔细地阅读它们，以便您可以看到鸡和猪之间的区别。

内部的“用户故事”是鸡写的。

实际的用户故事是由猪写的。

您的“面向鸡”的用户故事不是很重要。无论有多少管理层希望对其进行跟踪，就像它们是具有真实价值的真实用户故事一样，它们也不是真实的用户故事，并且它们不会以相同的方式创造价值。

质量保证问题是争论的模糊边缘。质量检查很重要，没有质量检查就无济于事。

但这并不能使QA突然变成猪。这使他们仍然是非利益相关者。它们为其余工作提供支持，基础设施和重要基础。但是它们的“用户故事”与真实用户的真实用户故事本质上有所不同。

如果质量检查没有显示出测试的改进，那么没有人会倒闭。钱没有丢失。

如果用户一开始无法开展业务，那么您就倒闭了。钱丢了。整个操作完全失败。

不要将内部（“鸡”）和真实（“猪”）的利益相关者混合在一起。

“鸡和猪”的评论没有讲到重点。对于产品的开发，内部利益相关者是鸡（除非是为他们开发产品），但是对于开发过程，它们是猪。

您要问的问题是句子公式“是否为 ，我希望能够 _，这样我就可以__ “对于定义和改进不需要编写新软件代码的业务流程很有用。之所以出现此线程，是因为我正在考虑做同一件事，并且正在寻找最佳实践，但是我的直觉很强烈，就是您的问题的答案是“是”。句子结构的目的实际上是迫使作者抽象化他/她可能已经想到的解决方案，并专注于用户的内容。在这种情况下，流程用户很想做，我看不出为什么用户故事在应用于流程时不会有用。

关于接受标准的观点是一个很好的观点，但不必太拘泥于此（无论如何都是敏捷的）。当设计任何业务流程时，这是一个很好的练习，它问：“我怎么知道流程的变更是否实现了我的目标？” 的确，您不能总是运行自动化测试来回答该问题，但这并不是取消用户故事工具的理由。