I couldn't agree more with his perspective that increasing productivity and metrics are not exactly coupled and that it is more important to adapt what you inspect to the problems you are trying to address. In other words, the metrics that you are watching now are probably different from the metrics you’ll watch for next iteration. That is, of course, if you fixed the problem.
What brings up the question, should we put monitors on metrics that we collect? In other words, if we decided that the number of hours spent on supporting deployments is too high, should we continuously monitor it to prevent it from ever being a problem again? If the metric in question is derived from some automated process, I’m absolutely in favor of it.
Be aware though that metrics should not hinder productivity. In other words, don’t bring down your team velocity so that you can collect . Whatever you decide to measure should be derived from some automated process you run (your build process preferably).
If you are in a Java shop, take a look at Maven and Sonar. These will provide you a lot of information in a single web page.
0 comments:
Post a Comment