Scrum Master 若只是从单一或表面的度量数据, 评定团队敏捷执行的现况, 往往会将团队导入更没效率, 更没质量的道路上。
“数据管理”, 这听起来高大上的名词, 然而只要执行上稍一不慎, 却往往会打击团队的士气与产品开发的效率与质量。
例如, 有的 Scrum Master ,
一看到单元测试覆盖率低,
便要开发人员写单元测试代码,
而完全忽略了从开发过程数据中所透露的, 测试人员设计测试用例效率低落的信息。更不顾从开发效率数据中所透露的,
工作量过载的信息。其结果往往是单元测试代码都是事后补上的。而流于形式的单元测试,
最终还得背上没效率, 没有用的恶名。
Scrum Master 只根据表面的数据（答案）,
便推动团队敏捷持续改善的方案（活动）,
这样的行为, 宛如是医生看到个病人发高烧到 39度,
便立马打退烧针,
其结果是可想而知。（我小时候,
就因为一剂退烧针, 而差点死在医院。）
Scrum Master 的 “数据管理”
一定要和团队的现况与行为相结合。依团队的现况与行为制定出多面向,
多纬度的度量模型。如此,
不管度量数据是来自于系统, 或是来自于人工,
不管是真实数据,
还是美化数据, Scrum Master
都能从多面向, 多纬度的度量数据中,
挖掘出数据背后,
团队执行敏捷的真正故事……
原文：http://blog.csdn.net/featuresoft/article/details/44152081