谁在scrum中写技术“用户故事”？

Question

我知道产品负责人应该用scrum写一个用户故事。

用户故事是为最终用户描述一个功能。

但是，世卫组织描述了哪些需要在技术上开发，以及需要如何实现。

关于scrum的信息存储在哪里？

那会让我很感兴趣的！

当开发人员开始执行这个故事时，我看到我们公司的知识严重缺乏，但是他们不知道如何实现它！

例如，他们必须处理遗留的COM，并且不知道如何处理它，或者他们在技术上对WPF/WEB或其他方面没有那么熟练。

scrum如何帮助人们从用户故事开始？

Answer 1

非敏捷仇人在这里。在sprint计划会议期间，充实实现的细节并确定需要完成的任务，这将将用户故事转化为sprint的实际任务/需求。许多敏捷过程的失败之处在于，sprint计划会议实际上应该主要由developers...if来完成--只有产品所有者，他们才会决定获得成功。这就是您想出一个(相当模糊的)用户故事的地方，比如：

As a non-technical user, I need to have a simpler interface with the API

当产品负责人定义哪些用户故事是最高优先级时，程序员就会将这些优先级转换为任务列表(称为sprint backlog)。这就是您了解如何实现things...the sprint待办事项的方法，您可以根据自己的意愿来实现。这也是你会发现“为了实现一个更简单的API，我们必须重构那个疯狂的COM API，有人知道如何使用吗？”当答案是“地狱不”，你会开始看到，用户故事的范围可能比它看起来更大。考虑到这一点，您应该将用户故事分解为以下任务：

• 记录和理解当前API
• 设计新API
• 实现新的API
• 不管什么..。

考虑到这一点，可以协商用户故事，将其分解为更小的更改。敏捷方法意味着您想要在渐进的步骤中接近人想要的东西。所以你可能会说：“嘿，你看，我们不能在一次迭代中彻底修改API，让我们把它分成‘作为非技术客户，我需要一个有良好文档的API’等‘。”

Answer 2

无论谁是团队中最有资格的人，都需要将产品所有者的需求分解为可操作的用户故事。根据我的经验，我们使用了以下方法：

• 开发人员一直是根据与产品所有者的讨论来编写故事的。
• 然后由开发人员(根据点或时间)估计这些故事。
• 然后，产品所有者决定如何对事情进行排序。

如果开发人员不知道如何实现一个故事，那么其中一个案例可能是正确的：

• 任务可能不够清楚(添加更多细节/屏幕截图/模型)
• 它需要进一步细分，以使具体任务更加明确。
• 它需要更多的时间，以便开发人员能够进行研究，并学习如何实现它。(在估计此任务时，增加更多的时间来解释这一点)
• 开发人员没有足够的资格来实现它，它可能需要分配给其他人，或者开发人员需要得到其他人的帮助。

您可以在Udemy免费学习这个关于SCRUM的课程，并了解SCRUM过程的各个方面-- https://www.udemy.com/scrum-methodology/。

Answer 3

简单的回答是:产品负责人负责创建团队必须提供的故事。是团队决定了如何传递这些故事。如果交付的一部分涉及到一些技术故事，则是团队编写这些故事。然后，团队与产品所有者一起决定优先级。

同样，PO决定构建什么，团队决定如何实现这些故事。