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