| 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. |