我知道产品负责人应该在Scrum中撰写用户故事。

用户故事正在描述最终用户的功能。

但是谁描述了需要在技术上开发什么以及如何实现它

以及与scrum有关的信息存储在哪里？

我真的很感兴趣！

当开发人员开始实施该故事时，我发现我们公司非常缺乏知识，但他们不知道如何执行该故事！

例如，他们不得不处理传统的COM API，却不知道如何处理它，或者他们对WPF / WEB或其他技术不熟练。

Scrum如何帮助人们从用户故事入手？

非敏捷者在这里。充实实施细节并确定需要完成的任务会在sprint计划会议期间进行，这会将用户案例转变为sprint的实际任务/需求。许多敏捷过程的失败之处在于，实际上应该由开发人员来完成sprint计划会议...如果仅仅是产品所有者，他们将决定获得成功。这是您想出（而不是模糊的）用户故事的地方：

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

在产品所有者定义哪些用户故事是最高优先级的同时，程序员将这些优先级转换为任务列表（称为sprint待办事项）。在这里，您可以了解如何实现事物……sprint待办事项可以按您的喜好进行技术处理。这也是您将发现“要实现一个简单的API，我们将不得不重构疯狂的COM API。有人知道如何使用它吗？”。当答案是“ Hell No”时，您将开始看到该用户故事的范围可能比看起来更大。鉴于此，您应该将用户故事分解为任务：

• 记录并了解当前的API
• 设计新的API
• 实施新的API
• 随你...

鉴于此，可以协商用户故事以将其分解为较小的更改。敏捷方法论意味着您要逐步实现人们想要的东西。因此，您可能会说：“嘿，看。我们无法在一次迭代中对API进行大修。让我们将其划分为“作为非技术客户，我需要一个有据可查的API”之类的东西。

简短答案

开发团队编写技术性的东西。Scrum在技术故障响应方面可以为您提供一点帮助，但帮助不大。用户故事入门。Scrum几乎仅是What-World。技术故障是How-World。

Scrum提供的细分为：

• 用户故事->接受条件

人们经常在此之上使用的细分是：

• 史诗->用户故事
• 用户故事->子任务
• 验收标准->验收测试

另外，团队可能会为他们知道需要完成的事情（例如，在项目开始时为每个人安装IntelliJ IDEA）编写技术任务，但没有业务价值。

有关如何分解工作的进一步指导，请注意XP（极端编程），简洁代码，实用编程，软件工程，CRC卡，OOP / OOA / OOD，设计模式，重构，有效使用旧版代码，TDD（测试驱动开发），BDD（行为驱动开发），ATDD（验收测试驱动开发）。

长答案

Scrum的想法

什么世界和如何世界

有一个“世界”和“ 如何”世界。如您所知，“ 用户故事”是针对用户的，它在What-World中产生了业务价值，也就是次要价值。Scrum大多仅是What-World。它对How-World几乎一无所获，而基本上只是“ How-World是开发团队的责任”。

用户故事与任务

通常，用于How-World的待办事项不是“用户故事”，而是“ 技术任务”或“ 子任务”。许多工具允许打破了用户故事从什么世成子任务中如何-世界。

Scrum如何提供帮助以及在何处结束

Scrum for How-World的帮助在Sprint计划会议中的几点结束：

• [Sprint计划会议]如果在计划扑克 ->讨论期间不同的队友提出不同的Story Point估算值，则团队会发现对故事的误解。
• [就绪的定义]团队不接受太大的用户故事（故事点太高）。许多“准备就绪”定义中都有一个经验法则，即“故事点”必须小于团队速度的一半。
• [就绪的定义]如果没有足够的接受标准描述，团队将不接受用户案例。如果团队对如何开始编写验收测试有足够的信心，那么验收标准就足够了。

有关Scrum级别的一些技巧

我发现在积压细化会议或至少Sprint Planning会议的第二部分（对于某些团队Sprint Planning 2会议）中，将用户故事分解为子任务很有帮助。

在经验不足的团队中，我发现在积压细化和Sprint计划期间争取原子用户故事很有帮助。原子用户故事是一个用户故事，在不完全丧失其业务价值的情况下，无法将其细分为更小的用户故事。通常，“用户故事”不需要一定是“原子的”，我只是发现它对经验不足的团队有帮助。

并且不要将“（功能X的（体系结构|设计|实施|测试）”）做为用户案例。我建议您甚至尝试避免将此作为子任务。

如果我有“原子用户故事”，并且除了要实施的“接受标准”之外，它们似乎还需要进一步细分，这对我来说意味着某些事情无法达到最佳水平。架构错了/太复杂了，即技术而不是面向业务。或团队经验不足。或两者。无论如何，都需要采取行动，通过培训和传播知识来改善这种状况。

超越Scrum

超越Scrum的Scrum Master

如今，Scrum Master大多被理解为管理角色，这就是胡说八道。最初，Scrum Master的是，我提倡这个，一个技术角色，而不是一个管理角色，就像教练在XP。

依靠Scrum和Scrum Master太容易了，因此陷入了巨大的鸿沟，因为Scrum几乎没有提到How-World。

旋转Scrum Master

理想情况下，Scrum Master在经验丰富的开发人员中轮换，这些开发人员也具有足够的管理和沟通技巧，直到团队中的每个人都过着非常深刻的“检查和适应”生活，以至于Scrum Master变得多余。没有人和每个人都会同时成为Scrum Master。

但是请注意，Scrum Mastery更像是烹饪，而不是清洁桌子和洗碗。您可能希望轮流由谁来清洁桌子和洗碗，因为每个人都可以这样做。但是，您不希望将烹饪方法转嫁给所有人，因为有些人会不会做饭或不喜欢做饭，并且您想吃好食物。

在专家开发人员之间轮换Scrum Master的好处是，团队更有可能了解更多方法。

自组织团队

从Scrum的角度来看，团队必须找出自己，最好是在Scrum Master的帮助下。

Scrum还和开发团队谈过。Scrum中不存在诸如架构师或首席工程师之类的角色。这并不意味着他们被禁止，仅意味着Scrum没有对他们说任何话。Scrum宣布了一个自组织团队，这意味着如果团队宣布了一名架构师，则该团队将拥有一名架构师。这不是Scrum定义的，但是与Scrum兼容。我并没有宣布专门的建筑师（我曾担任指定建筑师多年，尽管我很喜欢，但从根本上说，我反对指定建筑师的想法），只是举一个例子。

验收测试

用户故事具有接受标准。这些验收标准变成了验收测试

其他的东西

有关更多细分内容的列表，请参见如何将编程项目分解为其他开发人员的任务？

希望这可以帮助。

团队中最有资格的人需要将产品所有者的要求分解为可行的用户案例。以我的经验，我们使用以下方法：

• 一直是开发人员根据与产品所有者的讨论来编写故事。
• 然后由开发人员估算这些故事（基于时间点或时间）
• 然后，产品负责人决定如何确定事物的优先级。

如果开发人员不知道如何实现故事，那么以下情况之一可能是正确的：

• 任务可能不够清晰（添加更多详细信息/屏幕截图/样机）
• 它需要进一步细分，以便更清晰地执行特定任务
• 它需要更多时间，因此开发人员可以进行研究，并学习如何实现它。（估计此任务时，请花更多时间解决此问题）
• 开发人员没有足够的资格实施它，因此可能需要将其分配给其他人，或者开发人员需要其他人的帮助。

您可以在Udemy免费取SCRUM这门课程，了解Scrum过程的各个方面- https://www.udemy.com/scrum-methodology/

简短的答案是：产品负责人负责创建团队必须交付的故事。由团队来决定如何传递故事。如果交付的一部分涉及一些技术故事，则由团队来撰写这些故事。然后，团队与产品负责人一起确定优先级。

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

这不是敏捷问题。问题是团队没有足够的技术知识来完成用户故事（敏捷）或需求（传统）。敏捷可以在这种情况下提供帮助吗？不可以，如果没有仔细选择团队，并且团队中没有人有足够的技术经验来执行任务。是的，如果某些团队成员具有良好的技术知识，他们可以帮助其他团队成员执行任务。因为该团队需要自我组织，并且应该知道它的强项和弱项。

请记住以下敏捷原则。

“最佳的体系结构，需求和设计来自自组织团队”

发生这种情况的原因是，在敏捷环境中，团队信任度很高，他们相互之间委派工作。