为什么要数据化
用事实说话
通过数据的客观事实反应团队的协同效果和成果的产出质量，是从另外一个客观视角去挖掘问题的一种方式。尽量不要用「我觉得」、「我认为」这些主观臆断方式，进行复杂问题的评价。
角色多样、配合复杂
一个迭代，往往涉及到很多角色。所以，这些角色的行为和成果，对于「迭代质量」都会产生各种变化，这些变化往往是复杂的。所以，也需要从数据的层面，收集各个维度的客观事实，综合地评价「迭代质量」。
迭代也要迭代
产品的优化、迭代，是不断持续完善的。企业和产品的不同阶段，针对质量的要求其实也是完全不一样的。著名的项目管理三角形，其实就是权衡的过程，时间、成本、范围，最终都会影响质量的高低，只不过看某些阶段，我们更看重什么。在企业、产品不断的发展过程中，我们需要从各个方面收集数据，从不同维度持续分析「迭代质量」，以便于帮助我们在当前环境下，进行取舍，从而达到我们的产品目标。
如何数据化
在我们团队内部，采用了一个标准来评价迭代的质量，即「迭代质量评价标准」，其组成如下
迭代质量评价标准组成
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验收 → 发布 → 复盘
迭代数据化能带给团队什么
- 团队为迭代负责
- 通过数据化呈现迭代质量，让团队以一种理性的方式，审视迭代问题，从而找到解决方案，伙伴的目标是一致的：让迭代更好
- 让「问题」透明化
- 为改进团队迭代效能提供了坚实的数据基础（任何改变都能从数据层面找到体现）
想做还没做的事情
通过打通我们使用的各个敏捷工具，自动化收集迭代数据，产生「迭代质量分值」，并可以针对历史数据进行各自维度对比，从而更好的提高效率。
