如何数据化评价「迭代质量」

date
Feb 16, 2021
slug
Iteration-quality
status
Published
tags
技术管理
敏捷
项目管理
summary
type
Post

为什么要数据化


用事实说话

通过数据的客观事实反应团队的协同效果和成果的产出质量,是从另外一个客观视角去挖掘问题的一种方式。尽量不要用「我觉得」、「我认为」这些主观臆断方式,进行复杂问题的评价。

角色多样、配合复杂

一个迭代,往往涉及到很多角色。所以,这些角色的行为和成果,对于「迭代质量」都会产生各种变化,这些变化往往是复杂的。所以,也需要从数据的层面,收集各个维度的客观事实,综合地评价「迭代质量」。

迭代也要迭代

产品的优化、迭代,是不断持续完善的。企业和产品的不同阶段,针对质量的要求其实也是完全不一样的。著名的项目管理三角形,其实就是权衡的过程,时间、成本、范围,最终都会影响质量的高低,只不过看某些阶段,我们更看重什么。在企业、产品不断的发展过程中,我们需要从各个方面收集数据,从不同维度持续分析「迭代质量」,以便于帮助我们在当前环境下,进行取舍,从而达到我们的产品目标。

如何数据化


在我们团队内部,采用了一个标准来评价迭代的质量,即「迭代质量评价标准」,其组成如下

迭代质量评价标准组成

4个维度 + 1个分值
  • 4个维度
    • PM改动需求(30%)
    • User Story交付延期情况(10%)
    • User Story冒烟测试情况(20%)
    • Bug(40%)
  • 1个分值
    • 迭代质量分值
notion image
迭代质量分值:满分10分,合格6分 (1)
维度
占比
分值
计算规则
例子
30%
10
天数 减分 0.5 -1 1 -2 1.5 -3 2 -4 2.5 -5 3 -6 大于3 -10
Delay 0.5天,减1分,该项得分为:(10 - 1) * 0.3 = 2.7
10%
10
天数 减分 0.5 -1 1 -2 1.5 -3 2 -4 2.5 -5 3 -6 大于3 -10
Delay 1天,减2分,该项得分为:(10 - 2) * 0.1 = 0.8
20%
10
通过测试的故事数 / 故事总数 * 2
共5个User Story,通过了3个,3 / 5 = 0.6 * 2 = 1.2
40%
10
n>10 0 9<=n<10 1 8<=n<9 2 7<=n<8 3 6<=n<7 4 5<=n<6 5 4<=n<5 6 3<=n<4 7 2<=n<3 8 1<=n<2 9 0<=n<1 10
共30个Bug,6个User Story,30 / 6 = 5,在5<=n<6区间内,得5分,再乘以40%,5 * 0.4 = 2

举个栗子


notion image
上面是我的团队,近期的一组迭代数据,背景交代
  • 故事点:1个故事点 = 1人天
  • 迭代流程:按故事开发和测试 → 整体回顾测试 → PM&UI验收 → 发布 → 复盘

迭代数据化能带给团队什么


  • 团队为迭代负责
    • 通过数据化呈现迭代质量,让团队以一种理性的方式,审视迭代问题,从而找到解决方案,伙伴的目标是一致的:让迭代更好
  • 让「问题」透明化
  • 为改进团队迭代效能提供了坚实的数据基础(任何改变都能从数据层面找到体现)

想做还没做的事情


通过打通我们使用的各个敏捷工具,自动化收集迭代数据,产生「迭代质量分值」,并可以针对历史数据进行各自维度对比,从而更好的提高效率。

© 天行者YANG 2020 - 2022