12

足够的细节就足够了，这是通常的反应。

在我们目前正忙于的项目中（它是不完整的并且在没有任何类型的 brs/文档/用户故事的情况下移交给我们，我们得到的故事如下：

作为产品负责人，我需要开发人员测试 XXX 工作流程以使其正常工作。

和

作为产品负责人，我需要开发人员测试 YYY 工作流程以使其正常工作。

没有说明“正确”是什么意思。

当要求更多细节时，会被告知你要求的细节太多，因为这是敏捷的，所以在 sprint（2 周 sprint）的后期，需求会变得更加清晰，你不应该担心当时的细节，而是只是让故事在“娃娃毛”中占有一席之地，不再困难。做一个大人物。不要担心细节。

这就是敏捷应该是什么样的吗？

4

7 回答 7

16

当要求更多细节时，会被告知你要求的细节太多，因为这是敏捷的，所以在 sprint（2 周 sprint）的后期，需求会变得更加清晰，你不应该担心当时的细节，而是只是让故事在“娃娃毛”中占有一席之地，不再困难。做一个大人物。不要担心细节。

并不真地。用户故事抓住了本质，但这并不意味着没有细节。细节是在对话过程中传递的，并且对于很好地理解必须做什么是绝对必要的（更不用说如果你不知道做什么和期望什么，似乎很难估计任何事情）。

传达故事的细节实际上是产品负责人 (PO) 工作的一部分。这应该发生在 Sprint 计划会议的第一部分，PO 向团队解释每个故事，在计划扑克之前和/或任何需要澄清的时候。换句话说，请随时向 PO 询问详细信息（也向 PO 询问接受标准）。如果不确定性太大，请在故事前面放一个大估计，并解释为什么你不能做出“更好”的估计。

对我来说，您的 PO/客户/利益相关者似乎并没有非常积极地参与，这是一个非常非常大的障碍。你的 ScrumMaster 需要解决这个问题，没有神奇的解决方案。

于 2009-11-20T17:30:40.553 回答
8

您应该尽可能多地询问细节，以便对故事进行评估。

您可以在故事卡的背面添加一些验收测试标准（这些不必详细说明）。

作为客户，我想用信用卡付款...

使用 Visa、MasterCard 进行测试

顺便说一句，你的故事似乎有点奇怪。他们应该以客户/功能为中心。

于 2009-11-20T17:29:10.447 回答
3

Scrum 待办事项/用户故事不需要非常具体即可添加到待办事项中。

需要更多细节才能使它们可冲刺（可在 Sprint 中调度）。那时需要足够的细节以便进行估算，并且应该有一个明确定义的完成标准。

用户故事是与产品负责人就其涵盖的场景进行对话的承诺。

过早的细节是浪费。

于 2009-11-21T17:25:14.937 回答
2

It looks like you're using user stories here to define the process, rather than features in the system. But I don't think there is sufficient detail here for the developer to know whether the test is passed.

Also, what you've listed here are acceptance criteria, the user story is usually more descriptive and is underpinned by one or more acceptance criteria to define the essence of the functionality.

Questions I would immediately go back to the PO with are: What is the logic for Workflow XXX? At each step what are the options? What (if any) actions are logged? What email/notifications are sent? How? to whom?

If the Product Owner can't articulate the Product AND is telling a Scrum Master how Agile works, perhaps he needs 'training'.

Try providing a blank screen and ask him what's missing.

于 2009-11-23T14:32:02.360 回答
1

多少细节是“足够的”取决于很多事情。您的环境似乎表明需要更多细节。

首先，您可能需要在故事定义中提供更多详细信息，如果

  • 您的产品负责人无法实时回答问题（您团队的问题）
  • 您的团队分布在多个时区
  • 你的团队成员抱怨他们在拿起故事时不知道该怎么做
  • 您的团队对领域和/或应用程序的理解需要更多细节
  • 故事有一个高度可视化的组件（比如一个新的 UI 屏幕），图片将提供一种有效的机制来传达 UI 布局
于 2009-11-22T13:35:09.337 回答
1

通常，公司会采用混合流程策略。话虽这么说，这似乎是 rad（快速应用程序开发）+ scrum。如果这只是第一个 sprint，那么是的，这已经足够详细了。在第一个 sprint 的这一点上，我建议团队继续前进，确保工作流可以从头到尾执行，而不管它产生的结果如何。这通常意味着进行一些 Pokemon 异常处理（捕获异常而不是特定异常），记录错误并将信息带入下一个 sprint。

于 2009-11-20T17:24:26.530 回答
1

它需要从头到尾描述最简单的路径。它不需要描述所有的例外或变化。当您遇到这些例外和变化时，您需要与客户进行对话并在需要时更新故事。

于 2009-11-20T17:26:39.020 回答