AI实践哪家强?来 AICon, 解锁技术前沿,探寻产业新机! 了解详情
写点什么

用例还是用户故事?

  • 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:555737
用户头像

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

关注

评论

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

【干货】Vue3 组件通信方式详解

不在线第一只蜗牛

JavaScript vue.js 前端

又是鸿蒙!业界智能终端整机操作系统领域首个EAL5+认证诞生

最新动态

河北平泉:信息化管理开创食用菌产业新篇章

人称T客

alien skin eye candy 7 mac中文版 眼睛糖果滤镜PS插件下载

Rose

打破生态「孤岛」,Catizen将开启Telegram小游戏2.0时代?

区块链软件开发推广运营

dapp开发 区块链开发 链游开发 NFT开发 公链开发

FCPX插件:直线图形矩形线条路径动画预设

Rose

mac菜单栏应用管理软件:Bartender 4 for Mac 中文激活版

你的猪会飞吗

mac软件下载 mac破解软件下载

10个明亮通透粉色调摄影滤镜Lightroom预设

Rose

PS滤镜插件套装Nik Collection 6 for mac中文破解版

Rose

鸿蒙生态逐光者图谱

最新动态

FCPX插件:视频去闪烁消除频闪工具Remove Flicker 中文英文版

Rose

“所得”如何超越“所见”?合合信息扫描全能王发布扫描“黑科技”

合合技术团队

图像识别 OCR 合合信息 扫描全能王

ps磨皮插件Portraiture 3 for Mac汉化版

Rose

Forester for Cinema4D(植物树木花草生长动画) v1.5.4激活版

Rose

亚马逊商品详情的 API 接口获取与分析:挖掘商业价值的关键技术

Noah

全球首部 Sora 生成宣传片《玩具反斗城的起源》亮相;钉钉全新 AI 小时搜索对所有大模型开放丨 RTE 开发者日报

声网

营销一体化如何精准构建智能营销生态,驱动生意持续增长

赛博威科技

人工智能 营销费用管理 赛博威

软件测试学习笔记丨JUnit4测试框架

测试人

软件测试

公平发售平台开发

区块链技术

GifGun for Mac:在After Effects上的快速输出GIF动图格式插件

Rose

适用于FUJIFILM X和GFX富士相机的LUTS调色预设包 Earth LUT Pack

Rose

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