写点什么

用例还是用户故事?

  • 2008-08-03
  • 本文字数:2427 字

    阅读完需:约 8 分钟

Murali Krishna 告诉我们:

未能彻底明白用户故事的性质往往都是未能有效地转变到敏捷开发的重大问题。用户故事最重要的特点在於每一 个用户故事都是一个“可独立分配”的需求(特徵)单位。要达到“可独立分配”,就要从“用户”如何使用系统来表达用户故事。这样才让你实现到一个能让用户 交流,端到端(用户界面到后端)的功能单位。

Murali 想的跟众多敏捷社区的人仕一样——用户故事是最好的选择,并引用 Mike Cohn 写的一篇文章 Advantages of User Stories for Requirements 。文中指出:

每一个用户故事都包括三方面:

  1. 写下故事描述,用作计划和提示
  2. 故事的对话为故事细节
  3. 以测试作为细节的记录,用来判断故事是否完成实现

然后比较了用户故事和另一个出名的需求收集技巧——用例:

因为故事中有一些跟用例或传统需求语句相同的特征,所以弄清故事和这些早期的需求技术之间的差异是很重要的。这些分别特显出用户故事的好处。用户故事强调说话沟通,文书语言往往很不仔细,亦不能保客户和开发人员所理解的都一样。例如,餐牌上这样写:“前菜有餐汤或者沙拉和面包”这应该不难理解,但到底我可以选的是

  • 餐汤或者 (沙拉和面包)
  • (餐汤或者沙拉) 和面包

我们都按著貌似准确的文字去办事,但实情往往不是如此。试比较一下餐牌上写的和侍应生亲口说:「先生想点餐汤还是沙拉?」更好的应该是,在点菜之前送一篮面包过来。

如此看来使用用户故事比较好。但又是否如此呢? Alistair Cockburn,另一位敏捷社区内的名家,仍然使用用例,并从他过往使用用户故事的经验中指出所遇到的问题:

  1. 用户故事和 Backlog 上的项目不能提供设计师工作所需要的内容脉络——用户在做什么时候情况下做这事情,这行动的内容前文后理,以及在这一刻的高层目标。
  2. 用户故事和 Backlog 上的项目不能提供项目团队所需要的“完整性”——我发现开发队伍对项目估算的故事点随著工作开始以后不断增加,犹如无止境的一样。开发人员及项目赞助人也为此感到同样的沮丧。到底项目确确实实有多大呢?
  3. 跟 完整性有关的是,用户故事和 Backlog 上的项目不能提供一个合适的机制来考虑到未来工作的困难程度(原则上他们可以, 只是实际上他们不行)——我不断收到这样的投诉,「我们问客户 (产品负责人) 一条问题,他 / 她用上两星期时间才回覆我们。我们找错了人吗?」不是,他们没找错人,他们是过程出问题——有些问题需要长时间研究,因为不 同部门和用户组要找出什么是正确,平衡各方需要的答案。分析员看著用例中一系列的伸延的形势可以找出那一个较容易,那一个较困难,再进一步进行相关的研 究。用户故事和 Backlog 项目未能及时达到适合作出来那考虑的粒度——伸延的形势通常要在 Sprint 中才能观察到,这已经太迟。

Alistair 说了「为何不使用用户故事」后,进一步集中讨论「为什么使用用例」。

  1. 目标名称列表将系统对业务和用户的贡献进行了最简短的概括,提供给行政人员。这也提供了一个项目计划框架,可用作建立初始优先次序、估计、团队分配,以及时间的选择。这也是“完整性”的第一部份。
  2. 每个用例的主要成功场景能提供各参与者有关系统基本功能的协议,有时候更为重要的是,它可以告诉人们,哪些事情它不能做。给每一项需求提供脉络,这是其他工具很难办到的。
  3. 每 个用例的扩展条件可以给需求分析员提供一个框架,可以找出那些可能会用上 80% 的开发时间成本的烦琐细微之处。它提供一个考虑未来的机制,从而客户、产品负责人、业务分析员可以察觉到一些可能用上时间研究的问题。这些问题应优先处 理,让开发团队开始工作时这些资料也同时准备好。这用例伸延形势分析就是 “完整性” 的第二部份。
  4. 用例 扩展场景提供一些仔细而然往往也是难处理的细节,像编程员常常问到:「你想我如何处理这情况?」(通常回覆却是:「我不知道, 我未想过会有这情况。」)换言之,这是一个思考、文档纪录的框架,跟“如果……那么……否则”的情况作配对,帮助编程员思考不同的问题。分别在於这是在研 究阶段进行,不是到要开始编程时才进行。
  5. 整套用例系列反映出研究人员有详细思考不同用户需要,不同用户在 这系统上使用目的,以及一些业务上的差异。这是“完整性”的最后部份。(的确如是,我曾跟客户详细讨论长达 240 个用例,到最后,我去问她:「这是全部了吗?」她确认了。我们架建这系统,付运,收到应得的费用,而十年后这系统仍在使用。)

一如很多人所料,这回事不是黑白分明。我们该如何做好?我们现时在做的到底有用么?只有一个正确方法呢,还是有两个不同的 正确方法呢?或者视乎实际情况而定?会不会是有些情况下用用例较好,而有些情况下用用户故事较好呢?还是其实没太大分别呢——像用例中(或许)包含多个用 户故事而该用例因为一个用户情节内外都貌似用户故事呢)

查看英文原文 Use Cases or User Stories?

译者附注:

用户故事好还是用例好的问题,其实不像作者前面提到用户故事为大多数偏爱使用的工具,像 ICONIX、FDD、OpenUP 都很依赖或者支持用例的使用,不过明白两者分别极为重要。知道分别才可以作出合适的决定。 Scott Ambler 曾经在 < Artifacts for Agile Modeling > 指出两者的分别:

工具 通常应用 什么时候保存 用例 1. 主要使用需求综述
2. 分析现有系统使用需求 使用需求综述 用户故事 1. 探索用户需求
2. 与项目参与者对话的提示 功能实现后扔掉

很明显两者的使用情况和目的都很不同。甚至有需要下,两者可共同使用及存在。这就不存在到底是那个比较好的问题,亦不应该单靠一些报告说那个比那个好就麻木 跟从。重要的是如何更适合当前的情况,这包括项目上的需要,也包括团队的能力。长远来说,是让团队更敏捷。(有别於前文 Murali 中 「敏捷」和「不敏捷」的二元分辨)


译者简介:麦天志(Steven Mak),现职系统工程经理,工馀时间除了游水、观赏足球赛事、看电影以外则喜欢钻研有关软件开发过程、另类编程语言、美学、道德、创意、和预测市场等问 题。从小对编程产生兴趣,毕业於香港大学,主修计算机科学,并於伦敦帝国学院获取工商管理学项士学位。

2008-08-03 23:555814
用户头像

发布了 21 篇内容, 共 62805 次阅读, 收获喜欢 3 次。

关注

评论

发布
暂无评论
发现更多内容

阿里云 Elasticsearch Serverless 检索增强型 8.17 版来袭!

阿里云大数据AI技术

大数据 elasticsearch 阿里云 Serverless 向量检索

全面了解如何删除Mac启动台(Launchpad)的无效图标,Mac软件卸载后残留图标无法卸载的解决方法

阿拉灯神丁

mac系统清理优化软件 应用程序卸载 程序坞图标删除软件 CleanMyMac X中文版 卸载清理软件

凌晨3点的程序员,都在偷偷用这个神器续命…

测试人

人工智能

MES助力电线电缆行业生产:从质量管控到追溯管理

万界星空科技

mes 电线电缆行业 制造业工厂 电线电缆mes 生产管理MES系统

汽车上云的不可逆之路

脑洞汽车

AI

坐标上海,20~40K的面试强度

王中阳Go

Go 面经 上海

关税冲击下,全球AI向何处去?

脑极体

AI

“当月免费时长已达上限”怎么办?ToDesk:给钱

科技热闻

AI智上 | 用友凭借AI之力,绘财务数智化新蓝图

用友智能财务

勒索软件介绍

天翼云开发者社区

勒索攻击

GreatSQL启动崩溃:jemalloc依赖缺失问题排查

GreatSQL

出版社资源管理系统的运营

北京木奇移动技术有限公司

软件外包公司 出版社 资源管理系统

同济大学胡维老师分享大模型如何助力经管高效科研

ModelWhale

大模型 科研 同济大学 经济管理

做Docx预览,一定要做这个神库!!

Immerse

Vue 前端 docx 文件预览

超实用指南:应届生如何三步高效拿下理想实习机会

安全乐谷

面试 找工作 转行 笔试 找实习

Apache Cloudberry™ PAX 行列混存方案技术解析

酷克数据HashData

AI 时代,为什么编程能力≠ 开发门槛

阿里巴巴云原生

阿里云 云原生 通义灵码

生成式 AI 在电商评论场景的应用 : 场景分析和技术选型

亚马逊云科技 (Amazon Web Services)

出版社资源管理系统的技术难点

北京木奇移动技术有限公司

软件外包公司 教学资源网 资源管理系统

远程访问自建私有云、Docker服务只需3步,贝锐花生壳DDNS解析

贝锐

Docker 内网穿透

京东物流基于Flink & StarRocks的湖仓建设实践

Apache Flink

大数据 flink 实时计算

AI+代理IP手把手教你爬取某度

袁袁袁袁满

AI 代理IP 免费代理ip Python爬虫 爬虫实战

出版社资源管理系统的主要功能

北京木奇移动技术有限公司

软件外包公司 出版社 教学资源网

启信宝产业洞察:广东江苏领跑全国,动力电池回收形成“模式+标准”双标杆

合合技术团队

人工智能 #算法 #大数据

从 DB-Engines 排名攀升看 TiDB 全球突破之路

TiDB 社区干货传送门

云备份技术解析:备份删除&合并原理

天翼云开发者社区

云备份

出版社资源管理系统的开发

北京木奇移动技术有限公司

软件外包公司 教学资源网 资源管理系统

出版社资源管理系统的技术架构

北京木奇移动技术有限公司

出版社 教学资源网 资源管理系统

星闪,连接智能的「最短距离」

白洞计划

AI

在亚马逊云科技环境上基于 Dify Agent 快速部署 text2SQL 智能数据分析助手

亚马逊云科技 (Amazon Web Services)

三句话搞定周末出行攻略!我用 AI 生成一日游可视化页面,还能秒上线!

陈明勇

MCP

用例还是用户故事?_研发效能_Amr Elssamadisy_InfoQ精选文章