敏捷度量实践:十年磨一剑
如果无法正常显示,请先停止浏览器的去广告插件。
1. 十年磨一剑
敏捷度量实践
张晓洁
2. 讲师简介
•
•
•
•
张晓洁
Scrum Master
ee.msup.com.cn
2019 – 至今,担任Autodesk Revit的Scrum Master,
服务于多个团队;
2016 - 2019年,担任高级软件开发工程师并兼职Scrum
Master;
2005-2015年,担任软件开发工程师;
CSM、A-CSM、CSP、Scrum@Scale实践者、Team
Kanban实践者和PMP。
3. 摘要
在敏捷领域广泛讨论的度量问题上,Revit产品线积累了丰富的实践经验。不仅
建立起全面的度量框架,并且根据度量目的和对业务的影响,实时调整度量策
略,从而提升软件开发所交付的业务价值、协助团队持续改进。
今天,我将从以下三个维度的度量,结合Revit产品线实际经验,介绍关键指标
和确保目标达成的具体措施:
• 价值度量
• 交付度量
• 质量度量
ee.msup.com.cn
4. 目录
• 案例背景
• 度量关键指标和机制保障
• 价值度量
• 交付度量
• 质量度量
• 其他指标
• 案例总结
ee.msup.com.cn
5. 案例背景
Revit是BIM(建筑信息
建模)体系中最广泛使
用的软件之一,从概念
设计、可视化、分析到
制造和施工的整个项目
生命周期中帮助用户提
高效率和准确性。
• 近千万行级别代码
• 多专业混合业务复杂
• 月活用户总数200万
ee.msup.com.cn
6. 案例背景
• 三十个Scrum团队,分布在全球6个城市
• 功能特性团队
• 团队成员包括SM,PO 和 开发团队
ee.msup.com.cn
7. 案例背景
每日
站会
产品待办列表
梳理会议
2 星期
Sprint 回顾会议
Sprint 评审会议
Sprint 计划会议
ee.msup.com.cn
潜在可交付产品增量
8. 现状
• 用户对新功能和已有功能的增强都有很强烈的需要;
• 持续累计的复杂度降低了功能研发速度,用户抱怨声音没有真正被
产品研发部门重视;
• 在复杂度高并且持续功能开发的情况下,产品质量总是挑战;
ee.msup.com.cn
9. 度量什么?
哪些指标重要,如何选择它们?
ee.msup.com.cn
10. 目的和原则
价值 – 满足客
户需要的功能
质量 – 没有
缺陷和问题
的产品
ee.msup.com.cn
交付 - 持续
功能交付
• 度量最终成果而非中间结果
(outcome vs output);
• 从客户的角度衡量结果,度
量目标的达成对最终用户带
来直接好处;
• 指标的达成直接反映目标的
成功与否;
• 建立支持系统,持续调整,
促进目标的达成。
11. 价值度量
背景:用户对新功能和已
有功能的增强都有很强烈
的需要,大量的需求等待
团队实现;
目标:满足客户需要的功
能,从而推动达成期待的
业务成果
关键指标:易用性指标
ee.msup.com.cn
12. 易用性指标
• 用户满意度得分;
• 对功能/服务/产品的价值得分;
• 完成特定任务的成功率;
• 满意度和价值是主观数据,成
功率是客观行为数据;
ee.msup.com.cn
13. 具体案例
基准
• 满意度>4 & 价值>4 & 成功率>80%;
收集
• 功能发布前至少一次易用性测试获取数据;
分析
• 这些分数和数据告诉我们什么?
• 不只是着眼于分数,而是着眼于团队如何基于反馈去完善设计;
调整
• 提倡尽早开始,预留处理客户反馈的时间和灵活性;
• 推出一系列用户沟通的培训,指导如何做易用性测试;
• 从一两个团队试点,逐渐推广到整个部门,并作为部门OKR的一部分,使其成为部门DNA
的一部分;
ee.msup.com.cn
14. 交付度量
背景:用户迟迟等不到重
大功能的提升,抱怨声音
没有真正被产品研发部门
重视
目标:保持持续的功能交
付,在更小的块中有效交
付的同时,更快地学习
关键指标:Epic交付周期
(Epic Cycle Time)
ee.msup.com.cn
15. Epic交付周期 (Epic Cycle Time)
• Epic从开始(任何一个用户故事变
成进行中)到完成的时长;
• 当前季度开始的或预计将在当前季
度开始的Epic的平均交付周期。
• 持续时间是根据团队的速度和Epic
的大小、优先级来估计的。
ee.msup.com.cn
16. 具体案例
基准
• Epic交付周期 < 6周(一个半月)
收集
• 从Jira获取数据持续跟踪
分析
• 是什么原因让我们无法达成?
• 检查关于团队、工作流、过程等问题
调整
• 需要对“完成”有清晰的定义,明确的DoD;
• 每月一次的Preview Release发布;
• 每月一次的用户测试;
ee.msup.com.cn
17. 具体案例
• 什么样的挑战让我们无法达成?
• 我们是否意识到小块工作的价值
?
• 是否只是同时开始多个更小的部
分?
ee.msup.com.cn
18. 质量度量
背景:在复杂度高并且持续
功能开发的情况下,产品质
量总是挑战,bug总数只升
不降。
目标:发布给用户的产品保
证高质量
关键指标:逃逸缺陷趋势
ee.msup.com.cn
19. 逃逸缺陷趋势
• 产品交付给用户后发现的问题
为逃逸缺陷;
• 跟踪版本发布之后,随着时间
推移发现的bug的总数;
• 这个指标对客户满意度产生重
要影响;
ee.msup.com.cn
20. 缺陷发现时间提前
• 帮助理解在什么时候发现bug,
• 是在Epic完成之前?在发布之前?
发布之后?
• 在开发过程中尽早发现错误,
• 理想情况是在结束用户故事之
前——这样我们就不会重复地
重新访问代码;
ee.msup.com.cn
21. 具体案例
基准:
• 无逃逸缺陷
收集
• 客户支持获取用户问题
• 用户论坛反馈
• 程序崩溃报告
分析
• 追踪和复盘产品交付给用户后发现的问题
• 关注设计缺陷
调整
• 内部测试
• 常规测试
• 系统测试(System Testing)
• 质量日(Quality Day)
ee.msup.com.cn
• 外部测试
• 用户测试 (Inside the Factory)
• 每月Preview Release测试(
Quality Day)
22. 同时我们也关注
ee.msup.com.cn
23. 同时我们也关注
ee.msup.com.cn
24. 案例未提及
成长度量 – 持续的成长和学习;
团队健康度量 - 保持稳定;
效率度量 - 在相同的时间或资源下完成更多的工作;
ee.msup.com.cn
25. 案例总结
客户中心
的目标
• 用户价值
• 持续交付
• 高质量产品
• 易用性指标
指标
• Epic交付周期
• 逃逸缺陷
流程保障
• 用户深度参与
• 复盘调整形成闭环
• 无指责
文化基石
• 关注如何做
• 指标推动良性发展
ee.msup.com.cn
26. 没有衡量敏捷性能的银弹
敏捷软件开发宣言第一句:
我们一直在实践中探寻更好的软件开发方法,身体
力行的同时也帮助他人。
ee.msup.com.cn
27. 关注msup公众号
获取更多工程效能实践案例