为什么要数据化

用事实说话

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

角色多样、配合复杂

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

迭代也要迭代

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

如何数据化

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

迭代质量评价标准组成

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验收 → 发布 → 复盘

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

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

想做还没做的事情

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

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