More info on it here: http://en.wikipedia.org/wiki/Team_Software_Process
What has your experience been?
More info on it here: http://en.wikipedia.org/wiki/Team_Software_Process
What has your experience been?
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or specific expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, see the FAQ for guidance.
I took a class on PSP once, but never really used it. My short elevator ride description of PSP is that it's like SCRUM with more measurements. I worry, however, that some of the extra metrics can be used to inappropriately evaluate people - e.g. to reward or punish someone for their defect density.
I do like the discipline of estimation PSP pushes - I think estimation is a software development activity that has a lot of room for improvement, and I was able to measurably improve my estimation abilities throughout the course.
I’ve taken the PSP course and have been involved in creating on-line training for it. I’ve seen a number of successful implementations of TSP/PSP in companies – e.g. Intuit, Adobe, HP. The premise is strong: use accurate historical data of your own performance as a developer (in terms of time and, possibly more importantly, defects), analyse it (you’re given tools to do this), and base future predictions of your performance on this (that’s the PSP), and then roll this up with the data of your team members to create projections for your team’s performance (that’s the TSP). Where teams "buy it", it’s remarkably effective at improving scheduling and reducing defect rates – there’s a lot of case studies and reports published.
Data privacy is a concern that is considered at some point by everyone who looks at the PSP. The principle of the PSP is that your personal data is never shared. When it’s rolled up with others' in your team, then the team can access the rolled-up data. If you work for a company that violates this principle, then you’re likely to have put privacy concerns behind you.
Developers often buck at the prospect of logging time against their activities. The key to this is an effective demonstration of the advantage of keeping a log, learning to analyse the data, and applying the lessons learnt to write less-defective code in the time you said you would. Experiencing this is quite interesting.
Have a look at:
http://www.innerworkings.com/process I'm only allowed 1 hyperlink in my post, so It'll be my own ;-)
Look also at the Web sites for the Software Engineering Institiute's TSP pages, their annual Symposium proceedings, and the Wikipedia entry for PSP (it's more comprehensive than the TSP page).
Horrible. Absolutely hated it.
They brought it in at my old workplace (arguably the best known software company in the world) and had varying success with it.
One section of the company (IT app dev) was the guinea pig (where I was), the other section (product dev) just kicked it out, out of hand.
For me, at a developer level, all it did was introduce too much process.
Every "higher level" meeting, managers would present all these charts talking about low bug counts, reducing over time etc etc, when in reality, the projects were just as buggy/delayed as any other normal project, it was just being dressed up nicely by the Dev leads.
I guess you can say that is a failure of the teams rather than the system, but it was more the teams trying to get around a system they did not like that they felt actually hindered their project.
It's been a number of years now, but the 2 things that reallt stuck out were the incredibly awful Excel spreadsheet tool you had to use, and the lame "building a house" analogy from the training courses.
With PSP, your supposed to track metrics on the small, medium, large functions you write, and track it over time etc etc.
My problem with that and the house analogy is that I am always moving from technology to technology, version to version, so I didn't see how the metrics around how long it take me to do something would work.
TSP only gives you some beautiful charts and artificial data to do nice presentation and boggs down the project big time. It can be sold just becuase management is not a developer and doesn't know how developers do thier work. If, fortunately, a company has managment who knows something about development, the company will never uses TSP at all or will drop the process like trash.
TSP was basically introduced and pitched to management by consultants as a means of helping to achieve the goal of CMMI level 3 certification. I could go on and on about the ensuing disaster that happened once this process began being forced upon a development staff of agilists who were actually producing high value software for the customer on a regular basis, but instead I'll talk about the TSP methodology.
TSP is waterfall process incognito... period. The system itself is designed for repeatable process and nowhere does it advocate any value in the software that is being delivered. Its chief concern is making sure that a process is being captured, recorded, followed and measured. The development of TSP came about because organizations were struggling to meet the rigorous demands of CMMI. It was seen as a bridge to get to CMMI. It was founded in academia and in my experience it struggles in the domain of business application development.
Do you enjoy programming with a log book and a stop watch? That is how you measure your work. The data is supposed to be protected so that it can't be used against individual developers by management. It took about 2 months before management started asking the Team Leads for the individual metrics. You can just imagine how awesome people's metrics started looking after they learned that management was reviewing them.
TSP was presented as a load-balanced type of 3 month iterative process. By this I mean that a stack of work is presented and agreed to up front with the customer. There is a series of ceremonial meetings where requirements are drawn in blood and work is planned out. Each developer will get handed a stack of that work. It's basically a micro push system. Once a developer runs out of work, they can take over the load of other developers that may be falling behind. Priority of requirements are not considered or racked and stacked. Everything is just considered work that must be done and from that you derive a Work Breakdown Structure. Let's be clear - work doesn't mean programming. You might spend the majority of your time writing up design documents and cross referencing that design to your software requirements specification. Oh, and recording in your workbook every step of the way... remember to click that stop watch.
Within that 3 month iteration work proceeds strictly according to a waterfall system. There are no concepts of Test Driven Development or Emergent (simple) design. TSP follows a Requirements document, design document, coding, test and deployment phased approach. All of these phases must be well documented as part of the process and followed strictly with checklists. All of these phases are linear in nature and a series of metrics are recorded for each phase. I once visited another site where TSP was being implemented and I was adamantly told that people don't do testing before or during coding. These people were basically operating in the stone age and had no concept of test driven development.
There are various roles that each developer also has to play besides the reason that they were hired in the first place. These roles are essentially a way to enforce process capitulation upon the development staff. Like having a friendly North Korean neighbor that likes to check up on you once a week just to see how your doing. The developers on my team absolutely hated having these additional roles such as process enforcer, planning enforcer, meeting enforcer, etc. As for developer collaboration... virtually non existent. Remember you've been handed your work for the next 3 months. Its boils down to a group of individuals masquerading as a team.
Once a week the "team" gets together to review metrics that have been recorded in the workbooks. Earned Value charts are reviewed, risk analysis diagrams are mined closely, but more importantly it is a good once a week session to vent frustration with having to follow the process when all people want to do is build great software.
We lost a lot of talented developers during this experiment. I mean some really talented people. TSP is Scientific Management and Taylorism wrapped up in a nice package that upper management types seem to love. I have since left the organization and moved on to other headaches however I will never work with TSP again in my career. I think its safe to say many of my former coworkers have the same view.
|show 2 more comments|
What none of you developers realise is that through TSP and PSP you as a developer can write your own resume with evidence (data) to back it up. Also your data is your personal data and as a TSP Coach we may not discuss your data with anyone except the owner of that data... Yes, there is a process that needs to be adhered to and certainly each developer needs to be disciplined to capture the data.
TSP has assisted our organization in getting our estimations more accurate but in order to do that you need to be disciplined as developers to capture accurate data; garbage in garbage out. TSP/PSP doesn't bring anything new to the table, only the fact that there is a process which most of us learned during our courses.
Since the advent of 4GL Languages these disciplines all flew out the window and the compiler became the way of testing your code. TSP brings back the old ways of doing things by producing a design (program specification) and then a personal review as well as a peer review. Then you code it and once done you review your code and then get your peers to review; all this is timed and defects logged.
So for people who like to work in chaos this is not the way to go.
You have to be be willing to change and learn as you will see from your own data where you can improve.