de_DEen_USes_ESfa_IRfr_FRhi_INid_IDjapl_PLpt_PTru_RUvizh_CNzh_TW

引言

在软件开发快速演变的背景下,敏捷性与结构之间的张力长期以来一直是核心挑战。数十年来,团队在冗长的文档(确保完整性但抑制速度)与轻量级用户故事(促进速度但常牺牲上下文)之间来回摇摆。随着系统复杂性增加,对快速交付的需求日益迫切,仅靠任一极端都无法满足需求。

登场用例2.0:一种现代的需求工程演进,弥合了这一鸿沟。它源于传统用例的基本原则,但通过敏捷方法(如Scrum和Kanban)的视角重新构想,用例2.0提供了一种轻量但可扩展的方式来捕捉用户需求。它融合了用户故事的简洁性与用例的全面结构,为团队提供了从高层目标到详细实现的清晰路线图。

Use-Case 2.0: Agile Evolution of Requirements

本案例研究探讨了用例2.0如何变革需求收集、设计与开发。通过分析其核心原则、实际应用以及与新兴AI辅助开发工具的协同作用,我们展示了该方法如何使团队高效构建出正确的系统,确保每个增量都能交付价值。


需求工程的演进

近三十年来,用例一直是需求工程的基石,帮助团队理解用户如何与系统交互以实现目标。它们启发了许多现代技术,包括用户故事。但近年来,一件非凡的事情发生了——灵感的方向发生了逆转。

用例2.0是新一代的用例驱动开发——轻量、敏捷且精益,受用户故事及敏捷方法(如Scrum和Kanban)启发。它标志着传统用例实践的重大演进,将用户故事的简洁性与聚焦性,与用例一贯具备的全面结构和可扩展性相结合。

“用例2.0继承了过去所有受欢迎的价值——不仅支持需求,还涵盖架构、设计、测试和用户体验,并在业务建模与软件复用中发挥关键作用。”

用例2.0有何不同?

传统的用例方法论涉及创建详细用例文档,以记录系统行为,包括简要描述、前置条件、后置条件以及参与者交互。虽然有效,但这种方法往往文档繁重,难以适应敏捷开发的快速迭代节奏。

用例2.0在这一基础上进行了创新,引入了多项改进:

  • 敏捷对齐:与敏捷方法无缝集成,使开发团队更容易与利益相关者协作、分解需求并快速迭代

  • 用户故事整合:将用户故事作为轻量级方式来捕捉用户需求并建立共同理解

  • 用例切片:将复杂的用例拆分为更小、可管理的单元,可独立实现与测试

  • 可视化模型:强调使用流程图、活动图和序列图,以全面理解系统

  • 迭代开发:在构建每个组件时即进行测试,实现问题的早期发现

其核心在于,用例2.0引入了一个关键的新概念:用例切片。一个切片是用例中经过精心挑选、可独立工作的部分——它不仅贯穿需求,还贯穿设计、实现、测试用例和测试结果。

Visual representation of Use-Case 2.0 structure showing the relationship between actors, use cases, and slices.

图1:Use-Case 2.0结构的可视化表示,展示了参与者、用例和切片之间的关系。


Use-Case 2.0的六大原则

Ivar Jacobson、Ian Spence和Kurt Bittner确定了六个基本原则,这些原则构成了成功采用用例的基础:

1. 通过讲故事保持简单

讲故事是传达系统应如何工作的最简单且最有效的方式。用例捕捉系统的目标,而故事则涵盖如何实现这些目标以及如何处理过程中出现的问题。这使得需求能够被轻松地捕获、共享和理解。

2. 理解整体图景

无论你的系统是大是小,理解整体图景都是至关重要的。没有这个概览,团队就无法就范围、成本或价值做出正确决策。用例图提供了一种简单的方式来展示系统需求的概览——显示系统所有可能的使用方式、谁启动交互,以及任何其他参与方。

A sample use-case diagram illustrating actors and their interactions with the system.

图2:一个示例用例图,展示了参与者及其与系统的交互。

3. 聚焦价值

只有当系统真正被使用时,价值才会产生。与其关注冗长的功能或特性列表,不如将用例的重点放在系统如何被特定用户使用以实现具体目标。基本流程描述了实现目标的最简单方式,而替代流程则增加了选项和错误处理。团队可以先发布基本流程,再后续添加替代方案——这是设计上的累加方式。

4. 按切片构建系统

大多数系统在变得可用之前都需要大量工作。试图一次性构建整个系统是一个错误。相反,系统应按切片构建,每个切片都为用户带来明确的价值。

方法很简单:

  1. 确定系统必须完成的最有用的功能

  2. 将其切分为更薄、更易管理的切片

  3. 定义代表这些切片被接受的测试用例

  4. 选择贯穿整个概念的最核心切片

  5. 团队共同估算并开始构建

5. 分阶段交付系统

软件系统通过多个版本和发布逐步演进。每个增量都应提供一个可演示或可用的系统版本。Use-Case 2.0通过将用例切分为可组装成增量,最终形成发布的任务项,来支持这一过程。

6. 根据团队需求进行调整

软件开发中没有放之四海而皆准的解决方案。不同的团队和情境需要不同的风格和详细程度。Use-Case 2.0可以根据需要做到尽可能轻量——小型协作团队可以在简单的索引卡上使用轻量级的用例叙述,而大型分布式团队则可以使用更详细的文档。


Use-Case 2.0的结构:切片、场景和任务

三个关键概念定义了Use-Case 2.0在实践中的运作方式:

用例切片是用例的更小、更易管理的组成部分。与其在一个文档中定义整个用例,不如将Use-Case 2.0将其拆分为更易设计、开发和测试的切片。每个切片代表系统为支持特定用户任务或目标而必须执行的特定功能。

场景代表用户在切片内完成任务时可能采取的各种路径:

  • 正常路径:预期或标准的操作序列(“愉快路径”)

  • 替代路径: 实现相同目标的变体或不同方式

  • 异常路径: 可能发生的错误或异常情况

任务是用户在特定场景中为实现目标必须执行的具体操作。它们代表构成场景的各个独立步骤。

例如,在电子商务平台的“浏览产品”用例片段中:

  • 正常路径: 用户搜索、查看结果、选择产品、加入购物车,进入结账流程

  • 替代路径: 用户选择不同的支付方式(使用PayPal而非信用卡)

  • 异常路径: 由于资金不足或账单地址错误导致支付被拒绝

 

Detailed breakdown of a use-case slice showing normal, alternative, and exception paths.

图3:用例片段的详细分解图,展示了正常路径、替代路径和异常路径。


用例与用户故事:为何两者都重要

这正是Use-Case 2.0为解决常见的敏捷挑战提供有力方案的地方。

用户故事是一个独立的条目——它与其他故事之间没有内置关联。如果没有史诗或主题等额外的分组机制,200个用户故事的产品待办事项列表将难以管理。故事容易失去上下文,团队也常常在后期才编写验收测试。

用例则不同。它将所有相关的故事归入一个共同目标之下,包含:

  • 明确的目标(用例本身)

  • 逐步流程(基本流程)

  • 定义好的变体(替代流程)

  • 验收标准(测试用例)

当你查看一个用例时,看到的是用户实现特定目标的完整图景,而不仅仅是一个孤立的片段。

User Stories vs Use Cases
图4:对比图表,突出用户故事与用例之间的差异及其互补性。


Use-Case 2.0在敏捷实践中的真实案例

Use-Case 2.0为面临常见挑战的敏捷团队提供了结构支持:

电子商务平台: 在线购物系统的用例包括浏览产品、搜索产品、添加到购物车、进入结账流程和完成支付。早期的用例图揭示了缺失的流程——如“游客结账”——这些可以在冲刺承诺前添加,从而避免生产环境中出现购物车放弃的问题。

移动银行应用: 记录如“无效凭证 → 多因素备用”之类的替代流程,能及早发现安全漏洞,避免昂贵的上线后补丁,并建立用户信任。

拼车服务: 用例切片驱动MVP开发——从请求、接受和支付开始;后续迭代再添加评分和投诉功能。这能够实现快速交付价值,并具备明确的优先级。

医疗预约平台: 利益相关者对用例流程的评审揭示了“未到诊处理”需求。可加入自动重新安排功能,有望减少未到诊情况。

Example of an Agile team using use-case slices to plan sprints.

图5:敏捷团队使用用例切片规划迭代的示例。


AI的连接:用例2.0与AI辅助开发的结合

用例2.0最初于2011年开发,远早于AI编程助手出现的时代。但其原则被证明与AI辅助开发完美契合。

AI编程助手在清晰、结构化的规范下表现最佳。一个用例提供:

  • AI可理解的明确目标

  • AI可执行的逐步流程

  • AI需处理的明确变体

  • AI需满足的验收标准

AI辅助开发的四个阶段自然对应用例2.0的原则:

  • 启动 → “理解整体图景”——创建业务需求和初始用例图

  • 细化 → “聚焦价值”——编写包含基本流程和备选流程的规范

  • 构建 → “以切片方式构建系统”——借助AI,工作单元可以是完整的用例规范,而不仅仅是切片

  • 过渡 → “以增量方式交付系统”——用户验收测试确认用例满足利益相关者需求

Illustration of how AI assistants integrate with Use-Case 2.0 workflows.

图6:AI助手如何与用例2.0工作流程集成的示意图。


开始使用用例2.0

你无需一次性采纳完整的用例2.0实践。可以从三件事开始:

  1. 绘制用例图 — 确定系统的参与者和用例。这只需30分钟,即可让你掌握整体情况。

  2. 编写一个用例叙述 — 选择最重要的用例。将基本流程以项目符号形式列出。初始阶段仅列出备选流程的名称。

  3. 实现你的第一个用例 — 无论你采用手动开发还是AI辅助,都让用例指导你的实现过程。

你可以使用简单的电子表格或便利贴来跟踪用例。开始使用用例2.0时,无需特殊工具。


结论

用例2.0并不是用户故事的替代品——而是对它的补充。用例为你提供整体视图和结构。测试用例为你提供明确的完成标准。对于手动开发,切片能为你提供合适规模的工作项。

关键的洞察是,用例包含了用户故事所提供的技术,同时为更大规模的系统、更大规模的团队以及更复杂的开发提供了显著更多的支持。它们与用户故事一样轻量,但可以以平滑、结构化的方式扩展,以包含所需的所有细节。最重要的是,它们推动并连接了软件开发的诸多其他方面。

The Integration of AI and Use Case 2.0

在人工智能正在改变我们构建软件方式的时代,用例2.0提供了结构化且以用户为中心的基础,确保我们构建的是正确的系统,而不仅仅是一个能运行的系统。通过采用这一演进的方法论,团队可以在其敏捷旅程中实现更高的清晰度、效率和价值交付。


参考文献

  1. 用例2.0:需求工程的敏捷演进:用例2.0原则与实践的全面概述。

  2. 将用例与敏捷方法论结合:将用例与Scrum和Kanban结合的指南。

  3. 用例切片的力量:用例2.0中切片技术的详细说明。

  4. AI辅助开发与结构化需求:探讨AI工具如何从结构化用例中获益。

  5. 敏捷项目中的可视化建模:在敏捷环境中使用图表的最佳实践。