ScrumMaster 与数据管理

ScrumMaster 若只是从单一或表面的度量数据,评定团队敏捷执行的现况, 往往会将团队导入更没效率, 更没质量的道路上。

“数据管理”,这听起来高大上的名词, 然而只要执行上稍一不慎, 却往往会打击团队的士气与产品开发的效率与质量。

例如, 有的 ScrumMaster ,一看到单元测试覆盖率低, 便要开发人员写单元测试代码, 而完全忽略了从开发过程数据中所透露的, 测试人员设计测试用例效率低落的信息。更不顾从开发效率数据中所透露的, 工作量过载的信息。其结果往往是单元测试代码都是事后补上的。而流于形式的单元测试, 最终还得背上没效率, 没有用的恶名。

ScrumMaster 只根据表面的数据（答案）,便推动团队敏捷持续改善的方案（活动）,这样的行为, 宛如是医生看到个病人发高烧到 39度,便立马打退烧针, 其结果是可想而知。（我小时候, 就因为一剂退烧针, 而差点死在医院。）

ScrumMaster 的 “数据管理”一定要和团队的现况与行为相结合。依团队的现况与行为制定出多面向,多纬度的度量模型。如此, 不管度量数据是来自于系统, 或是来自于人工,不管是真实数据, 还是美化数据, Scrum Master 都能从多面向, 多纬度的度量数据中,挖掘出数据背后, 团队执行敏捷的真正故事……