敏捷开发 | 张三与需求管理
最近朋友张三问我:“ 史诗、特性、用户故事,它们一定要关联到一起使用吗? ”
我的答案是:当然不用。但是要真正解释清楚这个答案,我还需要对一些概念进行说明。
产品待办事项
在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官方博客」,转载请注明出处。
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
FastAPI 作为集大成者,它的灵感来自哪里?
人生苦短,我用 Python。 在看到 FastAPI 在首期「OSC 开源软件趋势榜」名列前茅,作为一个 Pythoner,顿时对它产生了浓厚的兴趣,于是立即开始了 FastAPI 体验之旅。 何为 FastAPI ? FastAPI 是一种现代的、快速(高性能)的 Web 框架,用于构建 API 服务。它使用 Python 3.6+ 开发,用到了 Python 的新特性——标准的 Python 类型提示。 主要特性概览 FastAPI 主要特性如下: 速度快:非常高的性能,可与 NodeJS 和 Golang 相媲美(这要感谢 Starlette 和 Pydantic)。 快速编码:将功能开发速度提高约200%至300%。 更少的错误:减少开发人员约40%的人为错误。 直观:强大的编辑器支持,自动补全无处不在,更少的调试时间。 简单:易于学习、易于使用,更少的文档阅读时间。 简短:更少的代码重复,每个参数声明有多个功能,更少的 bug。 健壮:可用于生产环境的代码。具有自动交互式文档。 基于标准:基于(并完全兼容)API 的开放标准:OpenAPI(以前称为 Swagger)和 J...
- 下一篇
爱奇艺移动端网络优化实践分享:网络请求成功率优化篇
本文原始内容由爱奇艺技术产品团队原创分享,本次有修订和改动。 1、引言 由于移动网络的复杂性特点,编写高质量、体验好的具备网络通信能力的移动端应用(尤其是即时通讯这类网络质量高度敏感的应用)有很大的挑战性。 我们平时看到的移动网络主要有如下三个典型特点: 1)移动状态网络信号不稳定,高时延、易抖动丢包、通道狭窄; 2)移动状态网络接入类型和接入点变化频繁; 3)移动状态用户使用高频化、碎片化、非WIFI流量敏感。 (▲ 上述文字,引用自《移动端IM开发者必读(一):通俗易懂,理解移动网络的“弱”和“慢”》) 正是由于上述特点,移动端应用在进行网络数据通信时会面临各种复杂多变的问题。 无论后面的技术有多复杂,但对于普通用户使用APP来说,能顺畅的完成网络请求,是理所当然的事。换句话说,APP网络请求成功率,重要性直接体现在它能直接决定APP服务的可用性,直接影响到数据通信、视频播放、广告展现、支付便捷等服务质量。 本文将以爱奇艺的iOS端APP为例,分享对移动网络请求成功率优化方面的技术实践之路。 本文已同步发布于我的“即时通讯技术圈”公众号。 2、导致移动端网络请求失败的因素 想要优化...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- Eclipse初始化配置,告别卡顿、闪退、编译时间过长
- Red5直播服务器,属于Java语言的直播服务器
- CentOS7编译安装Cmake3.16.3,解决mysql等软件编译问题
- Windows10,CentOS7,CentOS8安装MongoDB4.0.16
- Windows10,CentOS7,CentOS8安装Nodejs环境
- SpringBoot2整合Thymeleaf,官方推荐html解决方案
- Jdk安装(Linux,MacOS,Windows),包含三大操作系统的最全安装
- SpringBoot2编写第一个Controller,响应你的http请求并返回结果
- CentOS7,8上快速安装Gitea,搭建Git服务器
- SpringBoot2更换Tomcat为Jetty,小型站点的福音