DevOps系列之 —— DevOps概览（一）软件产业和交付模式发展趋势
DevOps系列之 —— DevOps概览（二）新型软件技术及交付模式
DevOps系列之 —— DevOps概览（三）DevCloud HE2E DevOps 框架及其主要服务
DevOps系列之 —— 持续规划与设计（一）敏捷项目管理理念与方法实践
DevOps系列之 —— 持续规划与设计（二）规划与设计
DevOps系列之 —— 持续规划与设计（三）敏捷项目管理的方法【Kanban 与 Scrum】
DevOps 系列文章，持续更新中 ~~~
- 敏捷需求管理
- 1. 用户故事
- 什么是用户故事
- 描述用户故事
- 用户故事 —— 角色类型的创建
- 角色类型的创建 —— 头脑风暴
- 角色类型的创建 —— 整理角色类型集合
- 角色类型的创建 —— 整合角色类型
- 角色类型的创建 —— 提炼角色类型
- 用户故事 —— 搜集故事
- 用户故事 —— INVEST原则
- 用户故事的层级关系
- 用户故事的优先级
- 用户故事的优先级 - 考虑因素
- 用户故事的优先级 - 渴望度 kano 模型
- 用户故事的优先级 - MoSCow 原则
- 用户故事的优势
- 用户故事的问题
- 2. 敏捷估算
- 故事点
- 故事点可以引导对整个故事的思考
- 故事点的优点
- 对大小的纯粹估计
- 我的理想人天不等于你的
- 理想人天的优点
- 估算方法
- 估算方法 - 原则
- 估算方法 - 如何确定估算值
- 估算扑克
- 分解用户故事
- 何时分解
- 分解方法 - 数据边界分解
- 分解方法 - 操作边界分解
- 估算速度
- 使用历史指
- 预测
- DoR 与 DoD
- 案例模拟 - 项目流程
- 用户故事描述了对用户，系统或软件购买者有价值的功能，由以下三方面组成
- 一份书面的故事描述卡片，用来做计划和作为提示
- 有关故事的交流，用于具体化故事环节
- 测试，用于记录和确认故事细节且可用于确定故事何时完成
As who, I want what so that why
- 作为X【什么用户角色】
- 我希望Y【系统提供什么功能】
- 以便Z【达到什么目的或实现什么价值】
- 或者是：
- 为了X【达到什么目的或实现什么价值】
- 作为Y【什么用户角色】
- 我希望Z【系统提供什么功能】
用户故事 —— 角色类型的创建相对于编写好的用户故事，产生和讨论的过程更加重要！
角色类型的创建 —— 头脑风暴我们以一个招聘网站的例子来描述角色类型的创建
- 只创造角色
- 不讨论角色
- 比如有哪些角色：求职者、猎头、招聘者等等
- 我们将不同类型的角色进行分组，分组之后再进一步整合和浓缩
- 如果有两个重叠的卡片对我们的意义是相同的，就可以保留一个，舍弃另外一个，或者将其变为一个新的
- 角色特征考虑方面：
- 操作计算机的熟练程度
- 专业技术水平
- …
- 用户模型创建好后，我们就可以开始收集我们的用户故事
用户故事的优先级 - 渴望度 kano 模型要根据业务价值确定优先级
- 当我们购买一件产品时，有那些功能是我们觉得理所应当应该有的？
- 哪些是我们觉得越多越好的？
- 哪些功能如果有的话是会令我们觉得兴奋的？
- 强调口头沟通
- 便于理解
- 大小适中
- 适合迭代开发
- 鼓励延迟细节
- 适应变化
- 参与性设计
- 传播隐形知识
- 故事太小
- 很难排优先级
- 想得太远
- 过早考虑界面细节
- 故事相互依赖
- 不愿排优先级
- 细节太多
- 什么是相对估算？
- 当我们根据户型图来预估粉刷每个房间工作量时，是否能准确说出每个房间会耗费多少时间？
- 当我们根据户型图来预估粉刷每个房间工作量时，是否能准确说出每个房间会耗费多少时间？
- 当我们用理想人天开来估算整个故事的工作量时，很难避免团队中不同岗位的人员以自身的工作量进行分别估算
- 项目开始时，5个故事点的故事耗费团队3天完成
- 项目尾声时，同样5个故事点的故事是什么情况？
- 如果此时用来估算工作量的是理想人天，那么又将发生什么情况？
- 更容易跟团队外的人解释
- 估算更容易开始
- 便于测试速度
- 通常是团队人员聚在一起，去比较待估算的用户故事，每个人写下自己认为的故事点数，进行展示，交换意见
- 用户故事的规模
- 受以下因素影响
- 工作量
- 复杂程度
- 不确定性
- 扑克牌的数值是斐波那契数列
- 当我们成功编写了一个用户故事以后，由于各种原因，我们往往需要把一个用户故事分解成多个更小的部分
- 用户故事过大
- 迭代时间不够
- 估算不准
- 按照用户故事所支持的数据边界来分解大型用户故事
- 按照大型用户故事中进行的操作对其进行分解
- 比如图书管理系统管理员权限部分
- 增加
- 删除
- 查询
- 修改
- 使用的技术是否一样？
- 针对的领域是否一样？
- 开发团队是否一样？
- 产品负责人是否一样？
- …
- 估算个人可用小时数
- 估算迭代可用时长
- 选择故事填充可用时长
- DoR（Definition of Ready）
- 敏捷开发发展后，发现进入迭代开发应当满足一定条件，否则过于模糊的需求会导致迭代失败，在迭代内花费过多的时间去做需求澄清，因此给进入迭代设立门槛，称为 Definition of Ready，简称为 “DoR”
- 常见的 DoR
- 用户故事澄清
- 用户故事的故事点估算
- 用户故事的验收条件
- DoD（Definition of Done）
- 在敏捷软件开发中，常用 Definition of Done “完成的定义” 来表示工作是否已完成，不同的活动有不同的完成定义
- DoD 类型及常见规则
| DoD类型 | 常见规则 |
|---|---|
| 用户故事 DoD | 用户故事最终的描述符合 INVEST；用户故事得到测试用例的对应覆盖；用户故事得到对应的自动化测试用理；用户故事得到 PO 试用并初步认可 |
| 迭代 DoD | 所有代码迭代通过静态检测，严重问题已修改；所有新增代码得到人工评审；测试用例都已执行 |
| 发布 DoD | 完成发布规划所要求的重点需求；至少通过一次全量回归测试；修复所有等级为1、2的缺陷，3、4级缺陷不超过20个 |
| 版本 DoD | 产品文档已全部更新；代码已部署到产品服务器上；运维在验收测试环境上冒烟通过；原始需求提交人对功能已经验收通过；对运维、市场、客服的新功能培训已完成 |
| 每日 DoD | 下班前检入当天编写的代码；当天的代码在当天或者第2天邀请同伴进行代码评审；检入的功能代码要有对应的单元测试；每天晚上触发静态代码检查、自动化回归测试；当天持续集成、构建环境中的问题当天解决 |
最后，欢迎大家关注我的个人微信公众号 『小小猿若尘』，获取更多IT技术、干货知识、热点资讯。同时，我在公众号中分享了精心整理的一些视频资料（包括 Python全栈教程、AI教程、前端、数据库等），大家回复相应关键词即可获取网盘视频链接，感谢大家的关注
