[nwjsmith]

I'm interested to know if anyone here has used this over an extended period of time. Does it work for you? Have you become better at estimating? Have you lowered your defect rate? Have you increased your pace?

I'm skeptical that something this prescriptive could be effective, but it'd be great if there was evidence (anecdotal or a study) that shows this is effective.

[ci5er]

I went through a personal anti six-sigma period in the early 90s. And adopted a slimmed down version of this for myself. Rather: it had the same name and came from CMU, but I don't recall it being quite so cumbersome looking, and I adopted a slimmed down "personal-only" version of it for myself. I didn't work that hard at it, and I was able to bring alternative data to a larger meta-drama I was somehow participating in.

Later - I spun out of there and started a company and we did that slimmed down version, based on the this Y2K document's predecessor. It didn't seem to cumbersome because it was inline with a lot of things we were already doing. And we had were using this light-weight measurement practice embedded in a modified dev-team wide process based on the spiral (we were all from waterfall-world, and this fit us well).

I've gotta say: it worked very very well. Especially after a few iterations through a few spirals. Skeptics came around pretty quickly. (Well, except one guy - but he hated everything)

I can't imagine doing 100% of what's written in this document, as a dedicated, in parallel, side-car type activity - but it might still be well worth it.

[HeyLaughingBoy]

Yes.

The organization I used to work for used PSP and its accompanying TSP (Team Software Process). I'm trained as an Advanced PSP Developer and a TSP Team Leader.

In short: it works and it works well. The downside is that it is a very expensive process. For some types of software development (we developed medical devices) the Cost of Quality comes down in favor of PSP/TSP. For others, you may never recover the ROI.

The entire team and its accompanying management must buy into the process for it to work. SEI enforces this by requiring that a TSP organization licence materials from them and train management. An SEI-certified coach must be assigned to the team to ensure they follow process and support them, etc.

We got very good at estimating tasks. I have data spanning many years that show what my average development rate is and that is crucial to making proper time estimates. The defect estimation is based on shaky statistics (according to a statistics-expert friend of mine who has used the process), but it does help to know how many defects to expect in a given body of code and if your inspection processes are removing them at an acceptable rate.

The defect management borrows from manufacturing process theory in terms of defect monitoring and feeding back data into the development process to extrapolate quality, but obviously software is very different in some aspects, so it doesn't work as well.

If you need supporting data, the SEI has lots of it. TSP practice is based on recorded data (development rates; amount of time spent doing development work per week; defect injection and defect removal rates, etc...) from thousands of software teams worldwide that use PSP/TSP and the SEI holds an annual symposium where many of them get together to discuss how it works for them, modifications that improved it and so on.

tl;dr: It's an expensive process that works. Whether its suitable for your organization depends on a number of factors.