如何数据化评价「迭代质量」
2021-12-09 本文已影响0人
天行者YANG
为什么要数据化
用事实说话
通过数据的客观事实反应团队的协同效果和成果的产出质量,是从另外一个客观视角去挖掘问题的一种方式。尽量不要用「我觉得」、「我认为」这些主观臆断方式,进行复杂问题的评价。
角色多样、配合复杂
一个迭代,往往涉及到很多角色。所以,这些角色的行为和成果,对于「迭代质量」都会产生各种变化,这些变化往往是复杂的。所以,也需要从数据的层面,收集各个维度的客观事实,综合地评价「迭代质量」。
迭代也要迭代
产品的优化、迭代,是不断持续完善的。企业和产品的不同阶段,针对质量的要求其实也是完全不一样的。著名的项目管理三角形,其实就是权衡的过程,时间、成本、范围,最终都会影响质量的高低,只不过看某些阶段,我们更看重什么。在企业、产品不断的发展过程中,我们需要从各个方面收集数据,从不同维度持续分析「迭代质量」,以便于帮助我们在当前环境下,进行取舍,从而达到我们的产品目标。
如何数据化
在我们团队内部,采用了一个标准来评价迭代的质量,即「迭代质量评价标准」,其组成如下
迭代质量评价标准组成
4个维度 + 1个分值
- 4个维度
- PM改动需求(30%)
- User Story交付延期情况(10%)
- User Story冒烟测试情况(20%)
- Bug(40%)
- 1个分值
-
迭代质量分值
-
维度 | 占比 | 分值 | 计算规则 | 例子 |
---|---|---|---|---|
PM改动需求(PRD定稿后) | 30% | 10 | Delay 0.5天,减1分,该项得分为:(10 - 1) * 0.3 = 2.7 | |
User Story交付测试延期 | 10% | 10 | Delay 1天,减2分,该项得分为:(10 - 2) * 0.1 = 0.8 | |
User Story冒烟测试通过情况 | 20% | 10 | 通过测试的故事数 / 故事总数 * 2 | 共5个User Story,通过了3个,3 / 5 = 0.6 * 2 = 1.2 |
Bug(n = Bug总数 / 总故事点) | 40% | 10 | 共30个Bug,6个User Story,30 / 6 = 5,在5<=n<6区间内,得5分,再乘以40%,5 * 0.4 = 2 |
举个栗子
上面是我的团队,近期的一组迭代数据,背景交代
- 故事点:1个故事点 = 1人天
- 迭代流程:按故事开发和测试 → 整体回顾测试 → PM&UI验收 → 发布 → 复盘
迭代数据化能带给团队什么
- 团队为迭代负责
- 通过数据化呈现迭代质量,让团队以一种理性的方式,审视迭代问题,从而找到解决方案,伙伴的目标是一致的:让迭代更好
- 让「问题」透明化
- 为改进团队迭代效能提供了坚实的数据基础(任何改变都能从数据层面找到体现)
想做还没做的事情
通过打通我们使用的各个敏捷工具,自动化收集迭代数据,产生「迭代质量分值」,并可以针对历史数据进行各自维度对比,从而更好的提高效率。