DevOps系列之 —— 持续规划与设计（四）敏捷需求管理【用户故事 & 敏捷估算】

DevOps系列之 —— 持续规划与设计（四）敏捷需求管理【用户故事 & 敏捷估算】

​​DevOps系列之 —— DevOps概览（一）软件产业和交付模式发展趋势​​​​DevOps系列之 —— DevOps概览（二）新型软件技术及交付模式​​​​DevOps系列之 —— DevOps概览（三）DevCloud HE2E DevOps 框架及其主要服务​​​​DevOps系列之 —— 持续规划与设计（一）敏捷项目管理理念与方法实践​​​​DevOps系列之 —— 持续规划与设计（二）规划与设计​​​​DevOps系列之 —— 持续规划与设计（三）敏捷项目管理的方法【Kanban 与 Scrum】​​   DevOps 系列文章，持续更新中 ~~~

​​敏捷需求管理​​

​​1. 用户故事​​

​​什么是用户故事​​​​描述用户故事​​​​用户故事 —— 角色类型的创建​​

​​角色类型的创建 —— 头脑风暴​​​​角色类型的创建 —— 整理角色类型集合​​​​角色类型的创建 —— 整合角色类型​​​​角色类型的创建 —— 提炼角色类型​​

​​用户故事 —— 搜集故事​​​​用户故事 —— INVEST原则​​​​用户故事的层级关系​​​​用户故事的优先级​​

​​用户故事的优先级 - 考虑因素​​​​用户故事的优先级 - 渴望度 kano 模型​​​​用户故事的优先级 - MoSCow 原则​​

​​用户故事的优势​​​​用户故事的问题​​

​​2. 敏捷估算​​

​​故事点​​​​故事点可以引导对整个故事的思考​​

​​故事点的优点​​

​​对大小的纯粹估计​​​​我的理想人天不等于你的​​

​​理想人天的优点​​​​估算方法​​

​​估算方法 - 原则​​​​估算方法 - 如何确定估算值​​

​​估算扑克​​​​分解用户故事​​

​​何时分解​​​​分解方法 - 数据边界分解​​​​分解方法 - 操作边界分解​​

​​估算速度​​

​​使用历史指​​​​预测​​

​​DoR 与 DoD​​​​案例模拟 - 项目流程​​

敏捷需求管理

1. 用户故事

什么是用户故事

用户故事描述了对用户，系统或软件购买者有价值的功能，由以下三方面组成

描述用户故事

As who, I want what so that why

作为X【什么用户角色】我希望Y【系统提供什么功能】以便Z【达到什么目的或实现什么价值】或者是：

为了X【达到什么目的或实现什么价值】作为Y【什么用户角色】我希望Z【系统提供什么功能】

相对于编写好的用户故事，产生和讨论的过程更加重要！

用户故事 —— 角色类型的创建

我们以一个招聘网站的例子来描述角色类型的创建

角色类型的创建 —— 头脑风暴

只创造角色不讨论角色比如有哪些角色：求职者、猎头、招聘者等等

角色类型的创建 —— 整理角色类型集合

角色类型的创建 —— 整合角色类型

角色类型的创建 —— 提炼角色类型

角色特征考虑方面：

用户故事 —— 搜集故事

用户故事 —— INVEST原则

用户故事的层级关系

用户故事的优先级

用户故事的优先级 - 考虑因素

要根据业务价值确定优先级

用户故事的优先级 - 渴望度 kano 模型

用户故事的优先级 - MoSCow 原则

用户故事的优势

强调口头沟通便于理解大小适中适合迭代开发鼓励延迟细节适应变化参与性设计传播隐形知识

用户故事的问题

故事太小很难排优先级想得太远过早考虑界面细节故事相互依赖不愿排优先级细节太多

2. 敏捷估算

故事点

什么是相对估算？

故事点可以引导对整个故事的思考

故事点的优点

对大小的纯粹估计

项目开始时，5个故事点的故事耗费团队3天完成项目尾声时，同样5个故事点的故事是什么情况？如果此时用来估算工作量的是理想人天，那么又将发生什么情况？

我的理想人天不等于你的

理想人天的优点

更容易跟团队外的人解释估算更容易开始便于测试速度

估算方法

估算方法 - 原则

估算方法 - 如何确定估算值

估算扑克

用户故事的规模受以下因素影响

工作量复杂程度不确定性

扑克牌的数值是斐波那契数列

分解用户故事

何时分解

当我们成功编写了一个用户故事以后，由于各种原因，我们往往需要把一个用户故事分解成多个更小的部分

用户故事过大迭代时间不够估算不准

分解方法 - 数据边界分解

分解方法 - 操作边界分解

按照大型用户故事中进行的操作对其进行分解比如图书管理系统管理员权限部分

增加删除查询修改

估算速度

使用历史指

预测

估算个人可用小时数估算迭代可用时长选择故事填充可用时长

DoR 与 DoD

DoR（Definition of Ready）

敏捷开发发展后，发现进入迭代开发应当满足一定条件，否则过于模糊的需求会导致迭代失败，在迭代内花费过多的时间去做需求澄清，因此给进入迭代设立门槛，称为 Definition of Ready，简称为 “DoR”

常见的 DoR

用户故事澄清用户故事的故事点估算用户故事的验收条件

DoD（Definition of Done）

在敏捷软件开发中，常用 Definition of Done “完成的定义” 来表示工作是否已完成，不同的活动有不同的完成定义

DoD 类型及常见规则

案例模拟 - 项目流程

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。