敏捷开发中的「史诗」到底是什么?
当我们开始了解和采用「敏捷开发」的时候,时常会看到一个略显陌生的概念「史诗」。或许因为翻译的问题,这个概念在中文语境里有些难懂,在实际应用中更是五花八门。为此,小编找到了这篇详细介绍“何为「史诗」”的文章,推荐给大家。
开始之前,我们先看看「史诗」的定义。
「史诗」是与「用户故事/需求」密切相关的。简单地说,「史诗」是一个更大的「用户故事」,或者说是一个「需求集」。它们通常表示了与产出物相关的原始想法。
「用户故事」,或称为需求,代表着需要交付的解决方案的具体工作项。而「史诗」则是用于跟踪、管理这些待办事项中,工作量较大的事务的一种「工具」。一个「史诗」通常包含多个「用户故事/需求」。
在实际工作中,如何编写用户故事,并将其拆分为有意义的「史诗」?第一步,可能是先写好「用户故事」。
Good user stories
好的用户故事遵循 INVEST 规则:
Independent -独立的
Negotiable -可协商的
Valuable -有价值的
Estimable -可估计的
Small – 小颗粒的(指工作量)
Testable -可测试的
“小颗粒的”和“有价值的”是用户故事中最关键也最难做好的要素。其中「有价值的」关系到另一个 V,Vertical 垂直切分。
所谓垂直切分,是指将产品依照其对用户提供的功能点或价值场景,切为不同的模块进行研发进度的跟踪与管理。在很多团队实践中,或许将其称为「产品模块/功能组」。而这,正是「史诗」的雏形。
Epic Today
早在 2004 年,Mike Cohn 就在他的开创性著作《用户故事应用》中介绍了史诗-epic. 在《用户故事、史诗和主题》中,他描述史诗为:用于描述「大故事」的一个标签。彼时,史诗和用户故事的区别主要在于工作量的大小。
然而,当我们在说“这个需求太大了”,“这条用户故事需要 13 点工作量”等问题时,根本上,我们是希望对这类故事作进一步细分的。因此,在后来的实践中,人们逐渐选择将「用户故事」和「史诗」分别使用。
如今,出于汇报工作的目的,产品负责人通常会将「用户故事」归纳为「史诗」,来做工作汇报。如此一来,我们很可能过度扩展了「史诗」的概念。
例如,我们可能会把故事归纳为以职能来区分的「史诗」。例如:服务端、前端、后端、测试等……但这种以横向职能为维度归纳法,只会让我们写出很糟糕的「史诗」。
如前文提到的,「史诗」应当是对用户故事的垂直切分:一个史诗中包含的众多用户故事都服务于同一个功能点或场景。这才是我们建议的使用史诗的方法。
事半功倍的「史诗」用法
我们来举个具体的例子:用户需要通过邮箱重置密码。
那么我们按照上述两种不同使用方法,会出现什么样的「史诗」呢?
A:预设 & 归纳
最常出现的情景是:
-
团队开始预设「史诗」,很可能是按照设计、前端、后端、安全等维度切片;
-
具体到“重置密码的页面”“更改密码的权限控制”之类的需求,更接近一项具体的任务,而无需用到史诗概念;
-
整个“重置密码”的任务工作量太大,于是团队分解出了一个“与邮件服务集成”的「史诗」;
-
截止到交付时,我们并没有能够完成整个功能,但在汇报中,我们似乎完成了一个「史诗」。
B:用于描述大型用户故事
最常出现的情景是:
-
团队并不预先设置「史诗」;
-
「用户故事」不会受到「史诗」的影响,它们依然保留了原定的编写逻辑和验收标准。
-
团队在快速识别出“规模过大”的故事后,将其列为史诗,并对它们作细分提取为新的故事。
-
即时交付时,我们未能完成整个功能,但此时已经拥有了依据功能要素切分的「故事集」,并可以重新决定优先级,以尽快处理积压。
结论
1. 「史诗」并非敏捷开发的基本概念,应该按团队实际需求,决定是否使用「史诗」。
2. 最好不要预设「史诗」。即使对用户故事有较清晰的理解,也很难预测「史诗」会否对需求描述及用户故事的编写产生影响。
3. 通过用户故事的工作量大小发现史诗。当一个用户故事过于庞大时,通过「史诗」可以快速区分其与其他用户故事的不同,便于沟通和工作。
4. 识别积压项目的大小。当「史诗」被用来帮助管理一个积压事项时,可以快速识别出该积压项可否被分割成更小的组块。
5. 如果由于某种原因,需要对故事进行分组,是否可以采用更准确的术语来称呼,例如:模块、主题、里程碑。
6. 如果「史诗」被用于汇报工作,需要更关注报告的理想状态,避免过分关注「史诗」概念,本末倒置。
7. 选择更好的软件工具,帮助管理「史诗」或「用户故事」,以提升团队协作能力。
— by Matt Riley
LigaAI 新一代智能研发协作平台 专注灵感 回归价值 享受成果
关注LigaAI@infoq,或点击上方官网链接,与众多开发者一起,共同学习,共同进步!
本文文字及图片出自 InfoQ
你也许感兴趣的:
- 【外评】电脑从哪里获取时间?
- 【外评】为什么 Stack Overflow 正在消失?
- Android 全力押注 Rust,Linux 却在原地踏步?谷歌:用 Rust 重写固件太简单了!
- 【外评】哪些开源项目被广泛使用,但仅由少数人维护?
- 【外评】好的重构与不好的重构
- C 语言老将从中作梗,Rust for Linux 项目内讧升级!核心维护者愤然离职:不受尊重、热情被消耗光
- 【外评】代码审查反模式
- 我受够了维护 AI 生成的代码
- 【外评】Linux 桌面市场份额升至 4.45
- 【外评】作为全栈开发人员如何跟上 AI/ML 的发展?
你对本文的反应是: