Fourteen tips
to better your PSPSM
Tip #1
Daniel M. Roy
(President STPP, Inc.
SEI visiting scientist and
transition partner)
Abstract: Fourteen tips are proposed to better use the PSP framework so that
improvement is made easier and PSP is routinely used on the job. Tips for PSP
support tools and about expanding the PSP to small teams are added to make the
transition to Team Software Process (TSP-SM[1])
even smoother.
The Personal Software Process is quickly becoming the new standard for software process improvement, particularly in organizations seeking to accelerate their progress toward higher levels of maturity [Ferguson-00] [Griffin-00] [Silver-00]. With over two hundred instructors qualified by SEI and an estimated five thousand PSP trained engineers world wide, PSP is getting into the mainstream. With the next wave of Team Software Process (TSP) raising from Pittsburgh, engineers already PSP trained or soon to be, should hone their skills and sharpen their tools to prepare for the time when PSP is where CMM is today (three to five years from now).
To this end, fourteen highly practical tips are
offered to foster the continuing use of PSP on the job, facilitate data driven
improvement, and prepare for your first Team Software Process project. Tips to use
existing tools and develop advanced PSP support toolsets are offered along the
way.
1. Better your time log
The PSP time log is a remarkably simple but powerful tool that clearly shows where your time is really going. It shows you in particular that even if you start work at 9am, get a short lunch break and go home by 6pm, you will not have put 8+ hours of work that day.
Any PSP trained engineer know to the minute how much activities such as E-mail, snail mail, phone interrupts and Dilbertian meetings cost. Their data show that on a typical day, only 3 to 4 hours are spent working on the project proper.
This knowledge is deemed so important for planning (and resist unreasonable commitment pressure) that most classes I have taught have developed quick and dirty tools to automate the time log, typically in Java, VB or C++. I personally routinely use Bill Gates’ notepad to track time in my practice.
Here is the trick: any notepad file starting with “.LOG” automatically enters a time stamp when the file is open (fig. 1-1). A post processor can easily extract the activities keyword and export data to a spreadsheet for statistical processing and graph reports. Any OS allows you to do this kind of thing from scripts (VMS show time, UNIX date command for instance). There is no excuse for not doing this.
Figure 1-1: a poor man’s time log
If you use the SEI spreadsheet (make sure you have version 19990610 or higher) you can keep very accurate track of your time such as prototypes, reviews, etc. while respecting all PSP rules (fig 1-2). Note that the time spent prototyping integrators (row49) is logged but not “charged” to the plan phase of program 5A (which would bias the stats).
Here is the trick: enter the start time as usual. When you are done doing whatever it is that should not be “charged” to the PSP, enter the stop time. The spreadsheet computes the elapsed (delta) time automatically. Then simply enter this delta time as interrupt. The same trick can be used to track the time spent developing reports (including R4/R5 process definition) since SEI spreadsheet unfortunately does not support this.
Figure 1-2: Using SEI workbook
Also note that the time spent reviewing the design of the generic integrator (Row 52) can be logged under the DLDR phase and automatically “charged” to the design phase on plan summary up to PSP 1.1 thanks to the good design of SEI’s VBA macros. This is great since DLDR and CR phases are not part of PSP 1.X since they are introduced in the second week of the class with PSP 2.0.
Again, a poor man to easily log time if you did not go trough the formal SEI training (and therefore do not have the SEI support spreadsheet), is to write your own macro:
Sub TimeStamp()
ActiveCell.Value = Now()
End Sub ‘TimeStamp
I also associate a keyboard shortcut (Control-T sounds logical) to the macro. Then, a time stamp is automatically entered in any cell you point to when you press Control-T. However, you better format the cell as a custom date (format tab) since Bill Gates’ internal time format is gibberish. Now, you have no excuse not to log your time! Start today, you’ll be glad you did.
Another thing that bother some students is the PSP “time machine”. If you are in test and you have to redesign, recode and recompile a module, the whole time is “charged” to the test phase. There are excellent reasons for this (cost of quality, A/FR metrics in particular) but it may shock your sense of fairness. Then, make separate entries in the time log for each activity (redesign, recode and so on) as I did in row 56 to 59 on Fig. 1-2.
On the job, adding a “REWORK” button to any phase on a time log tool would be a good way to better gauge progress by measuring the decrease in rework as the process improves. In this case, the A/FR should be redefined as reviews/REWORK instead of reviews/(compile+test time). Incidentally, this would have the advantage of rehabilitating unit test as a useful quality activity. Right now, because of the need to keep A/FR above a lower limit (2.0 for SEI data, 3 to 5 for my classes so far), students end up considering time in test as bad. I try to compensate for this in class by quoting Boris Beizer:
“There is a myth that if we were really good at programming, there would be no bugs to catch. If only we could really concentrate, if only everyone used structured programming, top-down design, decision tables, if programs were written in SQUISH, if we had the right silver bullets, then there would be no bugs. So goes the myth. There are bugs, the myth says, because we are bad at what we do; and if we are bad at it, we should feel guilty about it. Therefore, testing and test case design is an admission of failure, which instills a goodly dose of guilt. And the tedium of testing is just punishment for our errors. Punishment for what? For being Human? Guilt for what? For failing to achieve inhuman perfection? For not distinguishing between what another programmer thinks and what he says? For failing to be telepathic? For not solving human communication problems that have been kicked around... for forty centuries?” Beizer, 1990, quoted in [Pressman-01].
By the way, I use this quote in class to justify reviews and formal inspections as well.