On a team level (as opposed to an individual developer level), what metrics do you like to use to measure and improve software development speed, quality, and efficiency?
Those are terribly hard things to measure with metrics. Please for the love of all things beautiful may no one list out "number of bugs" as something they measure.
A lot of this gets covered in retrospectives. Making sure that you don't repeat similar mistakes over and over again and that the team is evolving rather than becoming static. I tend to focus more on how well we hit our goals (including business goals) so that will include things like, "Are we getting better at estimates?" It could also informally include, are Dev1 and Dev2 arguing less and communicating better?
I usually leave metrics to the product side. Find your version of Facebook's "7 friends in 10 days"
Your comment about bugs reminds me of my first job. One day the senior guy sitting next to me starting cursing. The program manager emailed him and asked him, before he even started coding, to estimate how many bugs there will be in the software in one year.
At my job, where I am a tester, "number of bugs" is one of the most prominent metrics in our evaluation.
I have tried to talk 3 of my bosses out of that (2 of which are engineers, one of them has a masters degree in some area of computing), but to no avail.
Sigh...
Total lines of code added (starting at total lines removed, then counting upwards). We want to see +150 per developer/week otherwise the TL has to explain it to the GM. We also have a manager who run a code consistency checker and flag any submits which don't conform to the standards (e.g. {} not on their own line, variables named incorrectly, etc). There are also reports that come out of the CS ticket system against each part of the system which are meant to be bug reports (most aren't) which we need to fix and close, teams are ranked against each other on fewest reports and most closed/month.
8 comments
[ 3.0 ms ] story [ 21.4 ms ] threadA lot of this gets covered in retrospectives. Making sure that you don't repeat similar mistakes over and over again and that the team is evolving rather than becoming static. I tend to focus more on how well we hit our goals (including business goals) so that will include things like, "Are we getting better at estimates?" It could also informally include, are Dev1 and Dev2 arguing less and communicating better?
I usually leave metrics to the product side. Find your version of Facebook's "7 friends in 10 days"
OP: Do NOT use bug count, for all that is holy.
Yes, it can be gamed, but if you're incentivizing developers to game your system, then you're probably using it wrong.
Total lines of code added (starting at total lines removed, then counting upwards). We want to see +150 per developer/week otherwise the TL has to explain it to the GM. We also have a manager who run a code consistency checker and flag any submits which don't conform to the standards (e.g. {} not on their own line, variables named incorrectly, etc). There are also reports that come out of the CS ticket system against each part of the system which are meant to be bug reports (most aren't) which we need to fix and close, teams are ranked against each other on fewest reports and most closed/month.
Why don't you do this during build time using build plugins or using commit hooks instead of a manager doing it?
My joke is that the code base should be getting smaller every week because we are all getting better.