基于量化的工程效能管理

• 从感觉到量化
• 工程效能下的度量指标
• 量化质量构建持续交付

工程效能下的度量指标

• 体系化指标
• 如果是瀑布模型下的是确定需求是否被完全完成，按标准模式计算回报
• 如果是敏捷模式是按照动态实现最小价值，是需要进行动态调整的实现方式

研发（工程）效能度量

• 流动效率
  1.需要最短时间发现价值
  2.需要在系统流动中发现价值
  3.持续发布的能力，比如引用Jenkins，实现CICD
  4.响应的周期，比如需要等待的时间，完成的时间，将需要等待的时间降低，比如提前准备好一些前期的工作

• 资源效率
  1.单件流，多件流，并行多任务执行
  2.交付能力

• 质量
  1.影响高速交付的问题，质量是影响的关键
  2.需要对交付质量有一定的流程，比如开发语言的选择，开发工具的选择等

来源课程.png

过程分解及监控

• 足够小的需求目标，是单件流走向。能够关注单个任务的完成
• 响应周期
• 交付周期
• 开发周期

来源课程.png

交付的能力

• 阿里的211
• 研发过程中的打包发布规范化:Maven
• 将打包好的发布到指定机器上面
• 如果整个流程都是流程化，而且是规范化的完成，才能有效减少错误，可以很快找到问题的关键

来源课程.png

基于Sprint的燃尽图

• 时间周期，工作量，使用时间
• 如果燃尽图高于理想的燃尽路线，说明完成进度慢，相反在理想线之下，就是完成进度快
• 斜率越大，说明完成速度越快，相反则越慢

来源网络.png

从燃尽图找问题

• 如果斜线直接下降，主要原因是需求被减少，甚至将需求砍掉
• 如果在理论线上下浮动，如果是在理想线下面，说明完成的工作速度快
• 如果在理论线之上，说明完成进度慢，是不是有其他工作影响，或者对store分析有出错

来源网络.png

交付吞吐量

• 如果坡度陡，说明交付速度快
• 如果坡度平，说明交付速度慢
• 价值流失，需要提前完成的情况是通过加班来完成
• 如果要完成预期的交付内容，就会有些内容被提前完成，比如通过加班来完成，这样就会存在技术债累积

来源课程.png

稳定的交付速率

• 如果通过正常的分析完成需求
• 将需求进行合理的分析，并且可以稳定的交付速度
• 不能通过加班，累积技术债来完成当下的交付任务
• 如果出现人员能力下降，团队成员流失的情况是无法达到稳定交付的速度

来源课程.png

累积流图

• 线的宽度表示交付的时间，如果宽度大，说明交付周期长
• 尽量保证每个不同颜色的区域相同，保证每个需求交付周期相同或者相近
• 优化以后的颜色，斜率都是相近的
• 在制品需要离底部越接近越好，表示完成的在制品越来越多
• 交付速度快，在制品少，斜率高，表示完成的工作达标快

来源网络.png

缺陷变化图

• 如果是瀑布模型的开始阶段bug比较少，但是测试一段时间后就会出现多数量的bug
• 如果是敏捷模型是bug数量是均匀的，不会出现上线高，也不会出现一时间无法可控的问题
• 敏捷过程中bug数量是稳定均匀的，是由于对交付需求及bug修复都是按照能交付完成后才进行下个阶段

来源网络.png

量化质量构建持续交付

• 持续测试中台

持续的测试反馈

• 探索性测试的价值反馈
• 更多的质量反馈，比如覆盖更多的测试覆盖
• 不仅仅完成基本的功能，还能完成超过的潜在质量交付
• 容量：比如工作量增加，需求增加，用户数量压力增加，这些都是需要做出预测反馈

来源课程.png

专业测试监控什么

(有超过8-10人数，中台的情况下需要做到如下的优化办法。如果是少团队的话就不需要做如下的工作)

• 测试设计
• 测试准备
• 测试执行

来源课程.png

DevOps平台与测试中台

(职业规划-测试效能)

• 环境管理
• 分层的测试
• 扫描，单测，手工测试
• 探索，冒烟测试

来源课程.png