我可以使用“用户故事”来执行过程改进任务吗？

Question

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

“作为一个测试管理器，我能否仅使用自动化测试而不使用手动测试来执行应用程序的测试，以便尽可能高效地测试应用程序？”

验收标准: 1.将50种现有的手动测试转换为完全自动化的测试2.测试必须在1小时内执行“

如果将“用户故事”用于支持软件开发过程的工作，而不是由程序员完成，并且不直接生成可交付代码，我想从社区中获得一些意义。还是应该以不同的方式处理/分类(例如，在JIRA中)？

更新的6/7/2011 -重新措辞的问题，重点是“用户故事”术语。

Answer 1

是

任何涉众，任何改进系统的功能

让纯粹主义者开始投票吧！

Answer 2

“我的管理层希望将敏捷用于一切，包括与非软件开发相关的任务。”

这并不意味着为每个功能编写用户故事。

如果您想为每个特性编写用户故事，那么您不一定是敏捷的。你只是在为每个功能写用户故事。

用户故事!=敏捷。

用户故事是收集和理解需求的一种方式。如果你愿意的话，它们可以被完美地用在瀑布上。有些人这么做。

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

管理技术债务和内部任务的用户故事--再说一次--与敏捷无关。

许多人非常乐意在sprint中添加“技术”或“支持”功能，而不浪费时间为纯粹的内部用户、有限的增值用户和非利益攸关者编写假的“用户故事”。

如果QA不了解他们的情况，那么实际的业务损失有多大？

如果真正的利益相关者没有得到他们的故事，企业真的会受到影响。

Answer 3

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

在这方面，软件是：

1. 可定义
2. 可测性

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

验收标准: 1.改进测试1( x/y)

你如何衡量测试的改进？这方面没有明确的合同。

关于一个无关的问题，我真诚地希望你上面举的例子，

作为一个测试管理器，我能否仅使用自动化测试而不使用手动测试来执行应用程序的测试，以便尽可能高效地测试应用程序？

..。只是一个例子，因为这有太多的错误，我甚至无法开始描述。