基于图1-12，你得出什么结论？大概是Instore Pickup Kiosk代码的图形很完美，因此你会在其他地方寻找问题。
同时，依赖少量的度量元也是危险的。在图1-13中，同一轴上添加了代码波动（增加、修改、删除的代码行数）和测试的代码覆盖率（已测试的代码行或块的百分比）。
突然间，图形就被颠倒了。在Instore Pickup Kiosk构件中有很高的代码波动，而测试对代码覆盖没有达到所预想的程度。图1-13揭示出我们的测试已丧失了时效性，不能测试新功能。这可能就是为什么此构件虽然通过了测试，却没有覆盖实际代码。
图1-13 增加了构件的代码覆盖率和代码波动后，数据所展示的景象就完全不同了
多维度的度量元和味道
能够看到项目数据的更多维度是度量元数据库的一个直接的好处，度量元数据库从日常活动中收集和关联数据。它提供了一个用于追踪味道的量化、可视化的工具。采用这种方法，你能够达到在以敏捷方式工作时最严格的一致性报告所要求的可见性水平，对于远程项目，甚至离岸软件项目，你也可以得到与本地项目能得到的一样的可见性。
