1) Create a program:
2) Capture some proposals:
A) command line parameters
A copy of each file is postated to the --to email address. The proposals are e-mail to the --emailproposals address, which adds them to the blog. The --to email address is used to cature the case, i.e. source file, estimation mistakes and bug information for personal reference.
B) blog proposals
This can be posted using an alias if desired. The "001 L1047" and time and date is a unique reference to the source file that prompted the proposal.
C) private measurements sent to your
e-mail
This allows the measurements to be removed from the source file and
yet
allow the developer to keep a record of the measurements.
3) Hide the measurements:
This removes all the measurement comments from the source or text
file.
This first e-mails the proposals and measurement comments and
then removes them from the source or text file.
4) Feasable gradual progress:
In 1992 this company started to use
measurements
to guide proposal capture. In 1996 the developers started to share
information about their proposals with each other. See Ferguson 1999
"Software Process Improvement Works" and other metrics related process
improvement books
and papers .
Rather than one improvement
proposal suddenly producing big improvements, it takes many small
imperfect improvement proposals to have this kind of impact. Each
proposal prevents a small percentage of problems and they combine to
produce big gains in time, quality and predictability. Estimates are
needed to allow projects to be compared. Each project is unique, unless
project differences are factored out little will be learned and few
problems will be caught early.
Last updated 2005/Dec/28