初学者敏捷产品经理用例图完全手册

理解用户如何与您的产品互动，是成功开发的基础。对于敏捷产品经理而言，在编写任何代码之前，清晰地可视化这些互动至关重要。本指南涵盖了您需要了解的关于用例图的一切。我们将探讨其核心组件、关系，以及如何将此技术整合到您的敏捷工作流程中，而不会增加不必要的负担。

无论您是在优化待办事项列表，还是为冲刺阶段明确需求，一个结构清晰的图表都能弥合业务目标与技术实现之间的差距。本手册旨在帮助您在团队中建立清晰度和一致性。

🎯 什么是用例图？

用例图是用户（参与者）与系统之间互动的视觉化表示。它关注系统提供的功能，而非内部逻辑或实现细节。在敏捷环境中，这些图表充当用户需求的高层次地图。

与详细的流程图不同，用例图不展示步骤的顺序。相反，它们从使用者的角度回答问题：“系统能做什么？”

主要特征包括：

• 关注功能： 它突出显示功能和操作。
• 以参与者为中心： 它聚焦于执行动作的主体。
• 系统边界： 它明确界定系统内部和外部的内容。
• 高层次视图： 它避免使用技术术语和实现细节。

🧩 用例图的核心组件

要创建一个有效的图表，您必须理解标准符号及其含义。无论您使用何种工具绘制，这些元素都保持一致。

1. 参与者 👤

参与者代表用户或与主系统交互的外部系统所扮演的角色。参与者通常以小人形象表示。

• 主要参与者： 这些是互动的发起者。例如，“客户”开始购买。
• 次要参与者： 这些支持主要参与者或系统。例如，“支付网关”验证交易。
• 内部参与者： 有时，一个子系统会作为另一个子系统的参与者。

2. 用例 ⚙️

用例代表系统执行的特定目标或功能。它们通常绘制在系统边界内的椭圆形中。

• 示例： “下单”或“登录”。
• 描述性名称： 始终使用动词-名词短语（例如，“管理库存”而不是“库存”）。

3. 系统边界 📦

系统边界是一个包围所有用例的矩形。此框内的所有内容都属于系统，框外的所有内容都是外部的。

• 清晰性： 这可以防止对系统负责的内容产生混淆。
• 范围界定： 它有助于利益相关者理解当前版本的范围。

4. 关系 🔗

线条将参与者连接到用例，也将用例连接到其他用例。这些线条定义了各个元素之间的交互方式。

• 关联： 一条实线，将参与者连接到用例。
• 包含： 另一个用例所必需的用例。
• 扩展： 在特定条件下添加可选行为的用例。
• 泛化： 一个参与者或用例是另一个的特化版本的关系。

🛠️ 如何创建用例图：逐步指南

创建图表需要协作和对问题领域的清晰理解。遵循此流程以确保准确性和团队一致性。

步骤 1：识别参与者 🕵️

首先列出所有与系统交互的人。可以提出以下问题：

• 谁直接使用该系统？
• 谁间接受到该系统的影响？
• 是否有外部系统参与（例如，邮件服务器、支付处理器）？

将这些内容写在白板或便利贴上。将相似的角色归为一组。

步骤 2：定义目标 🎯

针对每个参与者，询问他们希望实现什么目标。这些目标将成为用例。

• 参与者： 客户
• 目标： 购买产品
• 用例：下单

步骤3：绘制系统边界 📐

绘制一个大矩形。用系统或应用程序的名称对其进行标注。将所有已识别的用例放置在此矩形内。

步骤4：将参与者与用例连接 🔌

从参与者绘制实线连接到他们交互的用例。确保每条线都代表一次直接交互。

步骤5：添加关系（包含/扩展） 🔗

在必要时通过增加复杂性来完善图表。

• 包含：当一个用例始终需要另一个用例时使用。例如，“结账”始终包含“登录”。
• 扩展：用于可选行为。例如，“应用折扣”仅在输入代码时才会扩展“下单”。

📊 用例 vs. 用户故事 vs. 活动图

敏捷团队经常混淆这三种工具。理解它们之间的区别有助于你为正确的工作选择合适的工具。

工具	关注点	最适合用于	详细程度
用例图	系统功能	高层次的需求和范围	中等（概览）
用户故事	用户价值	待办事项和冲刺规划	高（具体标准）
活动图	流程流	复杂逻辑和决策路径	非常高（逐步进行）

用例图： 在探索阶段使用此图来定义系统功能。它非常适合新团队成员的入职培训。

用户故事： 在冲刺计划阶段使用此图来定义具体要完成的工作。格式为：“作为一个[角色]，我想要[功能]，以便[好处]。”

活动图： 当逻辑复杂时使用此图。如果一个流程包含许多决策点、循环或并行路径，则使用展示流程的图比简单的用例更合适。

🔗 详细理解关系

关系为你的图表增添了深度。它们明确了功能之间的依赖关系。

包含关系（<>)

此关系表示一个用例必须包含另一个用例。这是强制性的。

• 场景： 用户想要“预订航班”。
• 约束： 他们无法在没有“选择座位”的情况下完成此操作。
• 图形： “预订航班” <> “选择座位”。

这有助于开发人员了解某些步骤是更大流程中不可协商的组成部分。

扩展关系（<>)

此关系表示仅在特定条件下才会发生的可选行为。

• 场景： 用户想要“查看账户”。
• 条件： 如果账户被锁定，系统必须“显示锁定警告”。
• 图形： “查看账户” <> “显示锁定警告”。

谨慎使用扩展关系。过度使用会使图表变得混乱。

泛化（继承）

当一个参与者或用例是另一个的特殊版本时使用。

• 参与者：“管理员”和“用户”都可能继承自“人员”。
• 用例：“通过信用卡支付”可能继承自“支付”。

通过展示共享行为，减少了图表中的冗余。

🔄 将用例融入敏捷工作流程

敏捷强调迭代和反馈。静态图表很容易变得过时。以下是保持其相关性的方法。

1. 需求清单细化 🧹

在细化会议期间，使用图表确保没有遗漏任何功能。如果提出新功能，检查它是否在现有系统边界内。如果不在，可能需要构建一个全新的系统。

2. 冲刺计划 🗓️

在为冲刺选择故事时，参考图表了解故事之间的关联。如果某个故事依赖于特定用例，确保参与者和交互关系清晰明确。

3. 完成定义 ✅

使用图表来验证完整性。如果图表中的某个用例在冲刺中未被处理，则不应标记为完成。

4. 利益相关者沟通 🗣️

用例非常适合与非技术利益相关者沟通。它们以可视化方式总结产品功能，而不会用技术细节让他们感到困惑。

⚠️ 需要避免的常见错误

即使是经验丰富的产品经理在创建这些图表时也会犯错。请注意这些陷阱。

• 细节过多：不要绘制每一个点击操作。保持高层次。如果需要展示点击，应使用其他类型的图表。
• 内部逻辑：不要包含数据库查询或API调用。这些是实现细节，而非用户功能。
• 混淆的参与者：不要使用具体的人（例如“约翰”）作为参与者。应使用角色（例如“客户”）。
• 边界缺失：始终明确界定系统边界。此处的模糊会导致范围蔓延。
• 忽略扩展关系：如果存在大量错误状态或可选功能，应考虑使用扩展关系，而不是让主流程变得杂乱。

📝 示例：电子商务平台

让我们来看一个实际的例子来巩固这些概念。想象一个在线商店。

参与者

• 访客： 不登录即可浏览。
• 注册用户： 拥有一个账户。
• 管理员： 管理商店。

用例

• 浏览目录
• 搜索产品
• 添加到购物车
• 结账
• 管理库存

关系

• 访客 和 注册用户 都可以 浏览目录.
• 结账 包含 输入配送信息.
• 结账 扩展为 应用优惠码（可选）。
• 管理员仅与管理库存.

🛡️ 维护的最佳实践

软件在不断演进，你的图表也必须随之演进。如果图表不能反映现实，静态的图表就会成为负担。

• 定期审查：将图表视为一份动态文档，在冲刺评审期间及时更新。
• 版本控制：跟踪变更记录。如果系统发生重大变化，应为图表创建版本。
• 协作：不要独自绘制这些图表。应让开发人员和测试人员参与，以确保技术可行性。
• 简洁优先：如果图表过于复杂难以阅读，应将其拆分为多个视图（例如按模块或参与者划分）。

🔍 何时跳过用例图

尽管功能强大，但这些图表并不总是最佳选择。要知道何时应该跳过它们。

• 简单项目：如果系统只有三个功能，列表可能就足够了。
• 复杂逻辑：如果流程涉及复杂的有限状态机，状态图或活动图会更合适。
• 快速原型设计：如果你正在以极快的速度推进并需要验证一个假设，白板草图比正式图表更合适。

📈 衡量成功

你如何判断用例图是否有效？

• 更清晰的需求：冲刺期间开发团队提出的问题更少。
• 减少返工：花在修复与预期流程不符的功能上的时间更少。
• 更好的对齐：利益相关者无需技术解释即可理解产品愿景。

🚀 前进

将用例图融入你的敏捷实践需要时间。从小处着手。选择一个功能并将其绘制出来。与团队分享。收集反馈。对图表本身进行迭代。

记住，目标不是完美，而是沟通。一个能阐明复杂概念的简单图表，比一个无人理解的完美图表更有价值。

通过掌握参与者、用例和关系的基本知识，你为产品建立了更坚实的基础。这个基础支持你的待办事项列表，指导你的冲刺，确保你的团队在构建正确的东西。

让您的图表保持可见。保持更新。并始终聚焦于用户。