1

真的有可能在 2 周的 sprint 中编写包含所有边缘案例、场景和所有操作的用户故事吗？如果在特定场景中需要解决一些小变化，这可能会使故事延续到该冲刺，该怎么办？

在我们的团队中，经常会出现设计、PO、BA、Dev、QA、PM 相互指责的冲突局面。

PO、Design、BA 说这些都是非常小的细节，本身就会变成一个冗长的文档，很难说每一个吹毛求疵的东西，QA/DEV 在规划时应该考虑这些情况。但是 QA/DEV 反击说这不是他们的工作，如果没有说明他们不负责任，他们只会做明确说明的事情。

PM 指责并向 BA、Dev、QA 施加压力，说他只关心速度，而没有真正帮助任何人。点，点，点，这就是他所说的全部。他甚至不帮助团队专注于产品、管理冲突、提供/促进可以改进的培训或流程。他甚至不明白如果构建失败、环境关闭、QA 和开发工作将被延迟。

开发人员/质量保证人员应该关注什么？是获得故事点还是让产品质量好？

谁真的应该为这些点而烦恼？PM 可以在没有真正了解现实的情况下对 Dev、QA、BA 施加压力吗？

谁真正负责错过更精细的细节？设计，PO，BA？或者 QA/Dev 应该在估算之前考虑一下吗？

情况一天比一天严重，我们整个关系中有很多政治和分裂！

可能是这个问题的后续：在敏捷/scrum 用户故事中，多少细节才足够？

4

3 回答 3

3

好吧，很多人“忘记”了“用户故事”的主要目的。用户故事非常小，可以写在索引卡上。这么多用户故事并不是开发人员可以实现的真正“熟需求”。这就是用户故事的“要点”：所以开发人员在实现时应该提出问题并与客户-产品负责人保持联系。

用户故事应该引起团队和客户更多的讨论。

但这对于您的情况可能不现实。您可能没有内部客户或难以定期联系。您可能处于“合同或外包开发”的情况下，您应该根据文件进行对话。我知道这一点情况并不好，但毕竟我们只是开发人员，有时我们无法改变工作环境和风格。[当然离开项目始终是一种选择:-)]。

但是在那种情况下，在项目开始之前获得所有需求细节是不现实的。您仍然应该在迭代开发中使用进化需求。 *而不是用户故事，您可以使用用例来分割您的需求，以便您可以在一次迭代中“咬”它*。那么如何在迭代方法中使用用例呢？

对于这个检查 Craig Larman 的免费书籍章节：他在第 6.21 部分解释它 [基于 RUP]。应用进化用例。并且 Ivar Jacopson 引入了新的“用例切片”。查看免费用例 2.0 电子书

以及对您问题的一些具体答案：

-是获得故事点还是让产品质量好？

我认为您也给出了新的答案：以质量生产产品是我们的重点。

谁真正负责错过更精细的细节？

看起来你的公司参与了敏捷炒作，但他们真的不理解。如果你有像单独的 QA、BA 或设计团队这样的“孤岛”，你将继续玩“指责游戏”。

你们都要为失败负责。失败是好的。软件开发是实验活动。重要的是快速、早期和廉价地失败。让你们所有人负责的一种方法是创建功能团队而不是孤岛。http://featureteamprimer.org/

要更多地了解敏捷的基础知识和这种“指责游戏”的根源，请观看 Larman 在 YouTube 上的视频Scaling Agile & Scrum with Offshore Development。PS：虽然演讲是关于离岸开发和 Scrum 的，但它对基础知识提供了非常深刻的见解敏捷。我想它会让你也“微笑”。:-)

于 2013-05-04T10:33:16.023 回答
1

这可能是可能的，但我不建议编写一个定义了所有边缘案例和场景的用户故事。考虑一下“用户故事”和“场景”之间的区别（如果有的话）。似乎您有一个复杂的故事，如果将其分解为多个故事，也许每个场景都有一个故事会受益。您对从 sprint 中“继承”的故事的担忧也表明需要分解故事。

当然有一个收益递减点，但似乎你在这里的故事定义范围太大了。对于那些真正细粒度到属于单个故事的边缘案例，将它们捕获为验收标准。

您帖子中的另一个危险信号（那里有很多问题）是将故事点视为保持交付价值的一种手段。故事点应仅用作估算工具。典型的（斐波那契）比例是故意不精确的，并且作为估计，它们应该被认为是不准确的。此外，规模是主观的，因此会因 Scrum 团队而异。除了团队估计他们的故事之外，没有人应该为这些点而烦恼。他们关心的应该是它是否是衡量故事大小的有效工具，从而使他们能够有效地确定他们将接受多少冲刺。

整个组织都必须明白，故事点不是用来记分的，它只是一种估算工具，这一点非常重要。广泛而清晰地传达这一点。此外，将估计数据保留在团队计划内部以帮助中断组织中的这种反模式可能是值得的。

于 2013-05-02T00:54:11.357 回答
0

如果您（团队）完全熟悉该领域，每个人都完全理解需求并且所有故事都是独立的（不相互关联），那么是的，这实际上是可能的。

这通常在项目开始时或在简单项目或培训中是可能的！

于 2013-05-07T01:20:00.930 回答