选一些该路径上的独有特征。比如” 测试覆盖率的增长”就算一个独特的特征，它是”反复测试”或者”增加测试人员”这些路径做不到的。
所有的参数组合起来，作为一个结果评审，而不是checklist式的逐个评审。
度量参数组合，它会产出类似以下的报表：
从这张报表上，除了能够读出我们将bug限制在规定数目之外，还能反映出以下数据：
当自动化测试覆盖率超过一定百分比后，继续保持它的增长， 对降低bug数量，和测试人员工作效率的提高起到的作用有限。这就是度量过程的意义，让你”看见”过程里发生了什么。
那么问题来了，【看见】有神马用？？
通过看见，我们能知道以下问题的答案：
增加自动化测试覆盖率是否能够帮助完成KPI？
答案：能
我们的自动化测试，做的够好了麽？
答案：做的是不是够好，不重要，重要的是够了，图中可以看出，超过60%以后，覆盖率的继续增长对于控制bug数量和提高测试人员生产力的贡献不大。
下一步应该怎么办？
答案：应该保持自动化测试覆盖率在当前水平， 并且尝试其他路径继续提升质量。
综上所述，通过对过程的度量，让我们可以清晰的了解现状，做出未来的决策，或者提供有力的证据帮助公司和客户做决策。
再举个例子，如果你想通过引入敏捷方法中控制WIP来提高生产效率，加速交付速度，一样可以制定类似的组合度量参数，它可能类似于：
-每个月(迭代)交付的功能点数(度量目标)
-每天WIP的数量(度量路径)
-每个功能点的cycle time(度量路径)。
常常有人问，WIP多少算合适？那么通过度量上面的组合， 当你发现过了某一点之后， WIP的继续减少不能对迭代交付的功能点数的增长，和Cycle time的减少有帮助时， 那个WIP就是合适你团队的WIP。
同样的你还可以通过设置其他的组合度量参数，来了解『user story 多小合适』，『是否还要继续推行某敏捷实践』等等因团队而异，没有统一答案的东西。
相比单纯的度量结果，这种度量结果+过程的式能带来的好处有：
既照顾了公司的整体目标，又能考虑到团队之间的差异，提供个性化考核。
可以帮助清晰的了解现状，而不是对现状停留在”感觉”的状态 并且基于分析，形成对未来的洞见。
帮助追踪路径的工作方法的的有效性。 不至于盲目的推行某种工作方法；或者过度驱动某种工作方式；辅助做决策。
有人可能觉得，度量就是为了提供一个标准，比优劣，定赏罚，度量就是竞争。如果抱着这样的想法，恐怕看完这三篇文章，会觉得，这家伙说了很多，但是并没有什么实际用处。最后的结果就是行成了个洞见，还是比较不出好坏来。
确实是这样的。因为我对度量的理解并不是比较的手段，而是【看见】的手段。相比传统的"只对结果进行度量"的方式， 这种度量"结果+过程"的方式，能让我看见三个事情：
看见到底是哪些工作方法（Path）在起作用.
看见这些方法在起什么样的作用.
看见我们什么时候应该停止对某种方法的投入，转而尝试新的方法。
而且这种【看见】是基于客观数据积累的，并不是基于【感觉】，它有更高的准确性和更强大的说服力。
自己能够【看见】,并且帮助组织和客户【看见】，就实现了自身价值的提升，并为公司或客户提供了更大的价值。从而获取更高层次的认可和收获。在激烈的竞争中做到弯道超车。
度量，可以用来提升自己的价值，为客户带来更多价值。也可以用来跟周围的
