用户故事范围管理的验收标准和 MoSCoW 方法
Posted: Mon Feb 17, 2025 9:04 am
不幸的是，我见过许多项目和人都低估了需求定义以及大创意的短期和长期范围管理的重要性，尽管这些是软件开发中最重要的阶段。有许多系统可以执行需求的定义，有些比较简单，比如用户故事，还有一些带有Gherkin 语法的验收标准，可能更完整，但最重要的是，任何像这样的敏捷框架都能促进团队的共同理解，是质量控制的核心。在本文中，我将解释它们是什么，以及哪种技术可以有效地使用 MoSCoW 方法控制项目的用户故事范围。
Agile 如何定义需求？
在进入正题之前，我需要解释一些基本的敏捷概念。
产品待办事项
产品待办事项列表是一个核心工件，它整合了与产品相关的所有信息， 99 英亩数据库 例如需求、估计、沟通、进度状态等。在瀑布管理中，它被称为票证、问题或任务。产品待办事项列表由四层层次组成：主题、史诗、用户故事和任务。
主题代表了跨越数月或数年的长期产品战略。
Epic 具有巨大的价值，影响商业投资，并且需要几个月的冲刺才能完成。
用户故事是每个 Sprint 中必须交付的小价值。
任务是可以在几天内完成的用户故事的细分。
用户故事
用户故事应该包含三个基本元素来阐明需求：用户故事（句子）、验收标准和视觉图像。用户故事（短语）描述了用户希望通过产品实现什么目标，包括谁、什么和为什么。下面是一个示例。
作为用户（谁），我希望通过邮箱地址和密码（什么）登录平台，以便可以安全地使用平台（为什么）。
视觉图像可以是草图、原型或支持共同理解和激发对话的复杂设计。由于用户故事和验收标准是基于文本的表达，视觉图像可以帮助人们想象软件应该如何运行。
接受标准是什么？
验收标准是敏捷实践之一，用于有效地编写完成之前必须满足的需求，简而言之，它就是定义需求和功能的用户故事。
由于需求定义是软件开发中最困难和最耗时的过程，因此 Agile 创建了一种有效且高效的编写需求的方法。验收标准不仅用于需求，也用于验收测试，因此开发团队不必分别编写两者。
虽然编写验收标准有多种格式，但由 Cucumber 创始人 Aslak Hellesøy 创建的 Gherkin Syntax 可能是理想的选择之一，因为它是最全面的格式之一。 Gherkin 的语法由四个简单元素组成：场景、给定、何时和然后，它们描述了软件应如何运行。该框架全面涵盖了软件行为的所有必要方面，适合定义详细需求。您可以在下面看到每个元素的解释和示例。
用户故事范围管理的上下文
用户故事应该足够小以便在一个 Sprint 内完成，从而实现一致的、迭代的交付。因此，管理用户故事的范围至关重要，因为范围对估算有很大影响。依据不确定性锥，研究开发阶段与估算精度的关系，得出明确的需求与范围对估算精度的提高最为显著。 “范围蔓延”现象（也称为需求蔓延或厨房水槽综合症）也表明，如果开发团队在编码之前没有明确需求和范围，范围就会随着开发的进展而扩大。
Construx：不确定性锥体
另一个考虑因素是项目管理三角，它描述了影响决策过程的三个约束（范围、成本和时间）。由于项目资源总是有限的，因此我们必须做出明智的决策。
项目管理三角
这里的关键点是，范围管理在敏捷中比在瀑布中更为重要。在敏捷中，资源和时间是固定的，而范围是灵活的。由于 Agile 旨在实现快速、迭代交付，因此产品经理会考虑如何在有限的时间和资源下最大化产品的价值。如果范围太大而无法在计划时间内完成，则应通过优先排序来缩小范围。相比之下，瀑布模型的范围是固定的，而资源和时间是灵活的。
Agile 如何定义需求？
在进入正题之前，我需要解释一些基本的敏捷概念。
产品待办事项
产品待办事项列表是一个核心工件，它整合了与产品相关的所有信息， 99 英亩数据库 例如需求、估计、沟通、进度状态等。在瀑布管理中，它被称为票证、问题或任务。产品待办事项列表由四层层次组成：主题、史诗、用户故事和任务。
主题代表了跨越数月或数年的长期产品战略。
Epic 具有巨大的价值，影响商业投资，并且需要几个月的冲刺才能完成。
用户故事是每个 Sprint 中必须交付的小价值。
任务是可以在几天内完成的用户故事的细分。
用户故事
用户故事应该包含三个基本元素来阐明需求：用户故事（句子）、验收标准和视觉图像。用户故事（短语）描述了用户希望通过产品实现什么目标，包括谁、什么和为什么。下面是一个示例。
作为用户（谁），我希望通过邮箱地址和密码（什么）登录平台，以便可以安全地使用平台（为什么）。
视觉图像可以是草图、原型或支持共同理解和激发对话的复杂设计。由于用户故事和验收标准是基于文本的表达，视觉图像可以帮助人们想象软件应该如何运行。
接受标准是什么？
验收标准是敏捷实践之一，用于有效地编写完成之前必须满足的需求，简而言之，它就是定义需求和功能的用户故事。
由于需求定义是软件开发中最困难和最耗时的过程，因此 Agile 创建了一种有效且高效的编写需求的方法。验收标准不仅用于需求，也用于验收测试，因此开发团队不必分别编写两者。
虽然编写验收标准有多种格式，但由 Cucumber 创始人 Aslak Hellesøy 创建的 Gherkin Syntax 可能是理想的选择之一，因为它是最全面的格式之一。 Gherkin 的语法由四个简单元素组成：场景、给定、何时和然后，它们描述了软件应如何运行。该框架全面涵盖了软件行为的所有必要方面，适合定义详细需求。您可以在下面看到每个元素的解释和示例。
用户故事范围管理的上下文
用户故事应该足够小以便在一个 Sprint 内完成，从而实现一致的、迭代的交付。因此，管理用户故事的范围至关重要，因为范围对估算有很大影响。依据不确定性锥，研究开发阶段与估算精度的关系，得出明确的需求与范围对估算精度的提高最为显著。 “范围蔓延”现象（也称为需求蔓延或厨房水槽综合症）也表明，如果开发团队在编码之前没有明确需求和范围，范围就会随着开发的进展而扩大。
Construx：不确定性锥体
另一个考虑因素是项目管理三角，它描述了影响决策过程的三个约束（范围、成本和时间）。由于项目资源总是有限的，因此我们必须做出明智的决策。
项目管理三角
这里的关键点是，范围管理在敏捷中比在瀑布中更为重要。在敏捷中，资源和时间是固定的，而范围是灵活的。由于 Agile 旨在实现快速、迭代交付，因此产品经理会考虑如何在有限的时间和资源下最大化产品的价值。如果范围太大而无法在计划时间内完成，则应通过优先排序来缩小范围。相比之下，瀑布模型的范围是固定的，而资源和时间是灵活的。