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

敏捷需求管理

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 类型及常见规则

案例模拟 - 项目流程

最后，欢迎大家关注我的个人微信公众号 『小小猿若尘』，获取更多IT技术、干货知识、热点资讯。同时，我在公众号中分享了精心整理的一些视频资料（包括 Python全栈教程、AI教程、前端、数据库等），大家回复相应关键词即可获取网盘视频链接，感谢大家的关注😊