Insanity is defined as
"doing the same things
over and over and
expecting a different
result". As a
developer, it is easy to
get into a rut of doing
the same thing over and
over again but never
really improving your
development process or
identifying things that
can aid in bringing real
success to your job.
To improve, we need to
understand our goals and
measure our progress
towards them. This
article discusses how to
develop metrics that aid
you in achieving
specific goals.
What are
Powerful Metrics?
Metrics are simply a way
to measure specific
things you are doing,
but you could create
hundreds of irrelevant
metrics that really
don't move you any
closer to solving your
everyday problems.
Powerful metrics
are a small set of
indicators that are
targeted to help you
accomplish a specific
set of goals.
Metrics Driven
by Specific Goals
Before defining your
metrics, ask yourself "What
goal(s) am I trying to
accomplish?",
then write your goals
down. For example,
typical goals for a
developer might be to:
Improve my
estimating skills
Reduce defect
re-work
Ensure that my code
is tight and
re-usable
Now that we have our
goals defined, let's
figure out how we can
create a set of metrics
to help us accomplish
them.
“Improve my
estimating skills"
To do
this, you first need to
record the actual time
you work on assigned
tasks as compared to the
original estimates.
The difference between
the estimate and actual
is the "variance".
At the end of a project,
determine your overall
variances to determine
how well you track
against estimated hours.
If you find that your
variances are over 10%,
consider buffering your
estimates on the next
project by the variance
amount. For
example, take the
example below:
Release Tasks |
Estimated Hours |
Actual
Hours |
Variance |
Variance
Percent |
Comments |
Release 1.0
(Tasks assigned
to me) |
360 |
450 |
90 |
25% overage |
In Release 2.0,
buffer your
estimates by 25% |
Release 2.0
(Tasks assigned
to me) |
500 |
460 |
40 |
8% underage |
Because of the
buffer, you came
in under
estimate |
In the example above,
buffering your estimates
allow you to become a
better estimator.
After tracking this for
a few releases and
buffering your
estimates, you will
begin providing more
accurate estimates.
If your team is using
Software Planner, you
can run variance reports
that automatically
calculate the
information above, below
is an example report:
“Reduce defect
re-work”
Software releases
often take much longer
than needed because
defects are not resolved
on the first round and
it adds time to the
release timeline when
developers have to fix
the same issue multiple
times and testers have
to regress those changes
over and over again.
Many times defects are
re-worked 5 or more
times before they are
correctly fixed.
To resolve this issue,
you must first have an
appreciation for how
often this is happening.
One strategy for this is
to add a field to your
defect tracking solution
that indicates that a
defect is being
re-worked. If your
defect tracking solution
has auditing
capabilities, it should
be easy to produce a
report or dashboard that
counts the number of
times defects are
re-worked. Below
is a dashboard generated
from
Software Planner
that shows defect
re-work:
By knowing this, you can
work on reducing re-work
by employing these
techniques:
Better
steps-to-reproduce
- Many times re-work
happens because the
tester has not
provided enough
steps to reproduce
the issue
consistently.
Work with your QA
team on providing
really great
reproducible steps.
Even better, have
them record the
steps into a movie
that show how to
reproduce the issue.
This can quickly be
done by using Jing (http://www.jingproject.com),
a free utility that
allows you to record
an issue and it
creates a link so
that the developer
can see it in
action.
Better Unit
Testing -
Sometimes developers
rush through the
development and do
not fully test it
before sending it
back to QA.
This takes
discipline, but if
you take the time to
fully test it before
sending it back to
your QA team, it
will save you time
in the long run.
Peer Code
Review -
Another set of eyes
on your code can
help you reduce
re-work.
Consider asking a
peer to review your
code before
compiling it and
sending it to your
QA team. You
can speed up code
reviews by using
tools like
Code Collaborator.
“Ensure that
my code is tight and
reusable”
To do
this, you must do peer
code reviews. By
having others inspect
your code, you will
begin to write tighter
and more reusable code.
To measure the
effectiveness of this,
measure the number of
defects found during
code review versus
defects found during
quality assurance. This
will quickly identify
how code review leads to
a reduction in defects
found during QA, which
is more costly to fix
than during development.
Keep track of code
reviews and defect
statistics, below is an
example:
Developer |
Release |
# Code
Reviews |
#
Defects from
Code Review |
#
Defects in QA |
# Defect
Total |
Jacob Holly |
Release 1.0 |
10 |
50 |
50 |
100 |
Bill Stuart |
Release 1.0 |
0 |
0 |
125 |
125 |
Cindy Mullis |
Release 1.0 |
20 |
60 |
20 |
80 |
Bill Baxley |
Release 1.0 |
5 |
75 |
20 |
95 |
You can speed up code
reviews by using tools
like
Code Collaborator.
Summary
Dedicate yourself to
improving your job by
identifying your goals
and tracking metrics
that help you determine
how you are trending
towards your goals.
The metrics listed above
work fine for my team
but I would like to hear
what metrics you find
are helpful in your
organization. To
communicate that to me,
please fill out this
survey.
If we get great feedback
from this, we will
publish the results in
our next month's article
so that we can all learn
from each other.
Sign Up Today
Start improving your
project efficiency and
success by
signing up for our
monthly newsletters
today.
| 
