对敏捷开发常见的抱怨
1、敏捷开发只看到眼前，看不到下一步
成熟敏捷团队能持续规划后续2~3个版本的大致范围，给团队明确的方向。
2、一堆零散的故事，缺少需求全景图
产品或方案作为一个整体，应提供所有相关故事的全景及其结构关系。
3、要进入迭代了，还没准备好设计
提前规划，从而能够对需要较大工作量进行原型和技术预研或设计的需求更早提前开始工作。
4、总是紧急需求很多，容量难以控制
明确的产品规划，消除业务对自己关心功能上线时间点的焦虑，有利于合理容量的工作分到各个迭代。
版本规划的不同形式——滚动版本地图
什么是用户故事地图
故事地图帮助团队更加清晰地规划并展示出系统/产品的全景图，而不至于迷失在零散的故事中；
运用故事地图及逆行持续地版本规划，帮助多团队结构下建立有效的协作，并作为在跨团队层面耿总进展和管理风险的工具。
用户地图-第一步：建立骨架
建立故事地图的两种方式：
- 以业务活动的阶段/步骤为骨架（从业务角度对故事进行组织，适合新系统）
- 以现有的子系统/模块为骨架（从系统角度对故事进行组织，适合遗留系统）
用户故事地图-第二步：拆分需求（特性/故事）
- 在每个骨架二级结构下列出需求中所有的功能特性/故事；
- 每一列，自上而下按交付的优先级排序；
用户故事地图-第三步：规划版本范围
- 画出2
3条横线，划分出34个版本区域； - 在每一列上下移动卡片，将其移动到规划的版本范围内（不做有移动）
注意：该过程同时考虑：
- 价值高低/紧迫性
- 需求确定性
- 依赖关系
- 团队容量
用户故事地图-第四步：跟踪风险与依赖
- 分析识别由跨团队依赖的特性，标识出来，持续重点关注跟踪；
- 分析识别有风险（技术、不可控依赖、方案问题、按去啊逆行等）的特性，标示出来，持续重点关注。
MVP及版本规划的原则
什么时候作版本规划？
新产品、新项目
- 在初期产品设计结束前（Inception工作坊最后一两天）
- PO与DM、DA一同参与进行，综合各种因素；
- 通常新产品建议一次性将MVP范围的全部规划出来，进展中可能调整；
产品演进
- 滚动开展，建议每1~2迭代滚动进行一次；
- PO与DM、DA一同参与及逆行，规划新浮现的需求；
- 通常建议规划未来2个月（或3~4迭代）以内的，越远的规划越不确定，可能调整。
典型问题：从0到1与1到100的版本规划、迭代管理、故事拆分的区别
鲸舟——数智化精益敏捷研发管理工具平台。
适合互联网创业团队的敏捷研发管理平台，现在注册使用，30人以下团队，永久免费。
可爱的你记得点个赞再走哦！！
