如何在敏捷用户故事中提供/获取必要的实现细节？

Question

我有一个关于用户故事和敏捷的问题。我读了几篇关于用户故事的文章，有一件事，我不太清楚。例如，在这个文章中有以下一句话：

用户故事是简单语言中的几个句子，勾勒出想要的结果。他们不会详细说明。

但是，通常情况下，如果没有详细信息，就无法实现功能。

让我举几个例子。

后端

应在当前后端中使用外部服务。后端应该调用外部服务的多个端点。

有一些重要的事情，比如应该调用什么端点，请求的内容应该是什么，应该按什么顺序调用端点。因此，这些都是我承认的技术细节，而且很可能是为了获取有关外部服务的信息而需要的交流/研究。谁要对此负责？

前端

添加到应用程序中的新页。这里还有一些重要的细节，比如按钮的标题、颜色代码、给用户的消息(信息、警告、错误)。

谁应该定义它，故事作者还是开发者？这应该是用户故事的一部分吗？

我还读了一个关于用户故事的语句，

“用户故事是敏捷方法的一部分，它有助于将重点从关于需求的写作转移到讨论需求。所有敏捷用户故事都包括一句或两句，更重要的是，一系列关于所需功能的对话。”

我真的不反对交流，但最终结果应该写在我看来的某个地方，因为口头交流不是永久性的，信息可能会丢失。

总之，根据我所读到的，用户故事是关于应该实现的，而不是关于如何实现的。我认为怎样做也很重要，因为事情可以是好的，也可以是坏的，后来发现一些事情是不好的，纠正它的代价就越高，但我找不到如何分享信息。

Answer 1

我要一杯牛奶。

什么样的牛奶？

别在意。只喝牛奶。

温暖还是寒冷？

随便给我牛奶。

2%或..。

牛奶!

好的，这是您的牛奶。

给我一些还没过期的牛奶按日期出售。

用户故事是简单语言中的几个句子，勾勒出想要的结果。他们故意不讲细节，因为那是设计。不要要求用户故事是设计的。许多设计可以实现一个用户故事。用户故事是关于所需的体验。不是解决办法。

当用户感受到体验时，如果用户的故事随着时间的推移而改变，不要感到惊讶。不要浪费大量的时间试图避免获得这种经验。好吧，只要它不会杀人。

实施细节应该由谁来定义，故事作者还是开发人员？

开发人员处理细节。实现细节不属于用户故事、需求或测试。它们属于密码。

Answer 2

用户和其他涉众不应该关心您如何实现系统。他们应该关心的是它做什么，而不是它如何做。

您非常正确地认为，许多特性和用户故事需要更多的细节才能正确地实现。但是，从利益相关者的角度来看，这些细节总是体现行为，而不是实现。

这取决于涉众提供关于系统行为的足够详细信息，以便您能够制定出一个适当的实现。这取决于您要想出一个满足利益相关者对行为的期望的实现。

涉众既没有资格，也没有兴趣提供关于您打算如何将您的系统组合在一起的技术细节。如果你的利益相关者说“我认为你应该用Java写这个”，或者“我认为你应该使用微服务”，你应该是第一个说，“让我担心技术细节，这就是你雇佣我的原因。”

要了解您是否确实需要使用(例如)微服务，请询问您的涉众有关非功能性需求。的问题

• 有多少用户将使用该软件(而不是“我们应该使用什么架构”)？
• 系统的预期响应时间是多少(而不是“我应该使用什么语言、框架和数据库”)？
• 需要什么样的计算(而不是“我需要一个OLAP多维数据集”)？
• 将存储多少数据(而不是“我需要多少磁盘”)？

这些都是可以从商业角度回答的问题，而不是技术问题。

如果你的问题仅仅是“我应该把这些细节写在哪里”，答案就是“在你写下用户故事的同一个地方”。

Answer 3

一个简单的答案是让“自组织”团队决定它需要多少细节。作为sprint (或单独的全队整容会议)的一部分，团队与PO讨论这个故事，并最终决定故事是否准备好进入Sprint。为了重复其他评论者的主题，这个讨论集中在“什么”，而不是“如何”，这是留给工作人员的故事。也就是说，可以讨论一些如何确保什么是可行的或提供架构的方向。在方便的时候，我会温和的警告不要太多的“解决”，然而。

基于大量关于团队合作的研究文献，我建议将讨论中的所有协议记录在故事卡上(无论是纸还是数字)，这样人们就不会浪费时间去回忆决定了什么！这也防止了由于误解而浪费的时间，要求每个人在卡片上的语言上签字--用户故事、接受标准和协议列表--然后再继续。