敏捷开发 | 张三与需求管理 原 荐

最近朋友张三问我:“ 史诗、特性、用户故事,它们一定要关联到一起使用吗?

我的答案是:当然不用。但是要真正解释清楚这个答案,我还需要对一些概念进行说明。

产品待办事项

在Scrum Guide中,产品待办事项(Product Backlog)是产品所需的所有内容的有序列表,它是对产品进行任何更改的唯一入口。只要产品还存在,那么产品待办事项就存在,它会不断的变化,以适应产品的发展。产品待办事项中包含特性(Feature)、功能(Function)、需求(Requirement)、增强功能(Enhancement)和修复功能(Fix),然而在实践Scrum时,很多团队更习惯把它们替换成史诗(Epic)、特性(Feature)、故事(User Story)、任务(Task)和缺陷(Bug)。这些事项构成了将来对于产品的一系列改动。

随着产品的价值的增长,产品待办事项也将变得更大、更详尽。需求永远不会停止,这些需求可能来自业务场景、市场要求、技术更新等等。产品负责人需要在开发团队的协助下对产品待办事项进行细化,细化的内容包括添加明细、预估和排序。很多历史经验证明,一个产品只有20%的功能是常用功能,有40%的功能从未被使用,因此通过对产品待办事项的管理,可以有效的让开发资源聚焦在收益最大的工作上。

Sprint和增量

Scrum的核心是Sprint,在一个固定的周期内,完成一个可以发布的产品增量。在Sprint开始时,首先要确定这个Sprint的待办事项,这些待办事项来源于产品待办事项,通常根据优先级而确定。在Sprint结束时,这个Sprint内完成的所有工作应该处于可用状态,这部分新增的产品特性、功能和缺陷修复是这个产品的一个增量,由产品负责人决定发布还是不发布。

增量是朝着目标又迈出了一步,它意味着产品待办列表中的一部分事项已经完成。一个Sprint接着另一个Sprint,一个增量接着另一个增量。

用户故事

严格来说,Scrum中是没有用户故事的。用户故事的说法来源于Scrum的联合创始人Mike Cohen的山羊软件,它的核心在于从渴望新功能的人的角度对功能进行简短的描述。它通常遵循这样的模板:

作为<用户类型>,我想要<一些目标>,以便<一些原因>。

用户故事通常写在便签或者卡片上,供所有人进行讨论。它将编写复杂的需求文档转移到讨论需求上,这样的讨论可以有效的避免理解不一致的问题。

另外,用户故事应该足够小,小到一个Sprint内能够完成,我个人建议是在0-3天的工作量(使用时间形容规模是不恰当的,这里只是方便说明大小,感兴趣的朋友可以看我的上一篇文章),这样可以保证团队速度。

史诗

史诗可以理解为是一个非常大的用户故事,可能需要数月才能完成,它无法放入一个Sprint中,却又是一个实实在在的需求。史诗就像是一个占位符,先放到产品代办事项中,在适当的时候,将它被拆分为很多小的用户故事,这些规模适当的用户故事将代替史诗放入Sprint中。

理解史诗有两个关键点:1. 它非常大, 2.还没想清楚里面的细节。

特性

特性的规模介于史诗和用户故事之间,它是一组相关用户故事的集合,这些用户故事组成了一个完整的功能。当创建一个特性时,通常已经对细节思考的比较清楚,通过一个特性将相关的用户故事关联起来。

一个迭代并不意味着一个版本,有很多的场景中多个迭代对应着一个版本,在产品对外发布时,往往更关注的是特性的完成情况。

理解特性也有两个关键点:1. 它比较大,2.已经想清楚里面的细节。

史诗 & 特性 & 用户故事

在复杂的业务场景中,史诗、特性和用户故事可以使产品待办事项更加的直观。它们可以建立一种树形的结构:

我回到张三的问题上。史诗、特性、用户故事,它们一定要关联到一起使用吗?当然不用。用户故事完全可以单独存在,史诗和特性的加入只是为了让需求管理更加的立体化。

最后,在Worktile Agile中,就是通过这样的方式来管理需求的,如果您正好需要这样一款敏捷研发的管理工具,不妨了解一下。

本文作者:Worktile高级系统架构师 孙敬云

Worktile 官网: worktile.com

文章首发于「 Worktile官方博客 」,转载请注明出处。

我来评几句
登录后评论

已发表评论数()

相关站点

热门文章