全局用户价值
- 不局部看待问题
- 构建全局用户价值视角
- 构建MVP的渐进用户价值交付
想法
1.用最短的时间做最重要，最有价值的事情
2.当业务量数量增加的时候不应该用增加人员，而是要做最有价值的事情
局部视角带来的问题
- 局部价值被体现
- 实现的价值未必是真正的价值
- 需要全局思考问题
构建用户故事地图
- 全局观察用户价值
1.对所有团队成员建立概念，如果建立用户价值
2.针对每个功能点进行开发，而不是关注整个面
3.开发的开发工作往往关注点，关注功能点实现
4.架构师和测试人员更关注面，更关注细节
如何构建用户故事地图
- 骨架图 or 骨骼图
- 用户实现价值需要的行走路线
-
根据用户使用的步骤来完成整体的路线，比如购物线路是登陆-搜素-选购商品数量-购买
来源课程.png
构建用户故事地图
- 构建用户行走路线，比如从下载APP到收到商品一整个线路
- 主要按照用户从最初到最后的行走路线
-
所有的必要步骤都给写出来，然后形成用户故事地图
来源课程.png
MoSCoW法则
- 用户故事排优先级
莫斯科法则，就是Must or Should， Could or Would not。在排用户故事优先级的时候，把用户故事按以下4种类别排优先级。
Must：这个迭代一定要做的。比如前面提到的“必需”的功能。
Should：应该做，但若没时间就算了。比如前面提到的“不太需要的”功能。
Could：不太需要的，但有了更好。比如前面提到的“几乎早期版本中不要”的功能。
Would Not：明确说明这个功能不需要做，切勿把功能放到Must，Should or Could里。
用户故事地图为测试提供了什么
1.证明价值，比如使用探索性测试
2.根据优先级，针对我们的需求优先级来完成目标
3.将能够实现的最小需求，目标先实现出来
4.将目标交付限定在交付范围内
用户故事卡片规模
- Epics
- Feature
- User store
- 规模的大小，Epics是最大的目标，Userstore是最小的实现单元
- 完成的时间节点
-
实现目标的顺序
来源网络.png
实现故事卡片的方法 - 计划扑克估算
- 属于亲和算法。
- 使用的方式就是每人取出一张带有编号的扑克，最后进行投票，当持有最小数跟最大数的两个人就是表明2人对同样的user store有不同的看法，主要是实现的难易程度有不同看法，这样2人就要针对这个user store进行分析。
- 分析以后将user store的分析结果进行责任共担，将评估进行平衡化。
MVP的构建策略
- 团队的交付速度决定了MVP的度量大小
- 比如团队能力强的可以快速的产出目标，这样MVP就足够小
- Store point
- 需要理解point的多少及交付时间需要进行估算，因为交付时间固定的情况下，需要将point尽量缩小
- 将一个sprint里面计算好可以实现的point，这样才能快速的交付目标
基于MVP的迭代交付
- 将最有价值的目标进入首先的迭代
- 如果在第一次迭代中没有交付的内容，是否需要安排到第二次迭代交付中？这样就是将第一次没有交付的跟第二次迭代交付的内容重新进行MVP划分，重新排优先级进行交付的排序
- 时间有限，做出最有价值的目标内容
全局的探索性测试
- 将每次交付的过程中对测试重新划分测试重点
- 从业务的思路来开展测试工作，而不是仅仅针对测试这个面开展工作
探索什么
- 通过用户故事地图的路径来确定MVP
- 传统价值是使用的自动化测试(Regression Testing)
- 新增的价值是使用的手工测试(Smoke Testing)
- 时间控制，减少不必要的分支路径，将新增的需求或者内容进行测试
- 路径染色是需求的染色，还有代码的染色
- 通过自动化测试将增量的代码进行测试
总结
- 从用户故事到用户故事地图
从点到面
1.1 让团队所有人都能够全视角看到用户价值
1.2 每个人看待问题的视角不同构建用户故事地图
2.1 需要全视角的看待用户价值
2.2 根据骨干图和优先级来构建用户故事地图排列用户故事优先级构建迭代计划
3.1 MVP中的影响因素，团队的实力
3.2 团队的交付能力，能力强，交付速度快，MVP划分的尽量小
3.3 交付范围，根据优先级和sprint时间来划分交付范围探索性测试是由故事地图影响
4.1 测试范围是由故事地图影响的
4.2 通过地图价值来开展手工，自动化测试
