问题
For more information - Personal Software Process on Wikipedia and Team Software Process on Wikipedia.
I have two questions:
- What benefits have you seen from these processes?
- What tools and/or methods do you use to follow these processes?
回答1:
I went through the training and then my company paid for me to go to Carnegie Mellon and go through the PSP instructor training course to get certified as an instructor. I think the goal was to use this as part of our company's CMM/CMMI effort. I met Watts Humphrey and found him to be a kind, gentle soul with some deeply held ideas about process. I read several of his books as well.
Here's my take on it in a nutshell - it is too structured for most people to follow, assuming you follow things to the letter. The idea of estimation based on historic info is OK, particularly in the classroom setting, but in the real world where estimates are undone in a day due to the changing tide of requirements and direction, it is far less useful. I've also done Wide Band Delphi estimation and that was OK but honestly wasn't necessarily any better than the 'best guess' I'd make.
My team was less than enthusiastic about PSP and that is part of the problem - developer buy-in. My company was doing it for the wrong reason - simply to say "hey, look we use PSP and have some certified instructors!".
In the end, I've found using a 'agile' approach to be better. I have a backlog of work to do and can generally estimate it pretty well. I've been doing it long enough that I can make pretty good rough estimates on time and frankly don't think that the time tracking really improves things much. Perhaps in some environments it would work well, but at my place, we'll keep pumping out quality software without all the process hoops that yield questionable benefits.
Just my two cents.
回答2:
I got into this once, even tried using PSP Dashboard.
It's just too hard to keep up with. Who wants to use a stop watch for all their activities? Follow Joel's advice on Painless Scheduling and Evidence Based Scheduling.
+1 this question, -1 to PSP.
回答3:
I have used the PSP and TSP process by heart for 4 years (though it was in the begining of my software career). As an idealist you will love what is being done by you and ofcourse Yes there are amazing results as well.
Though PSP advocates the recording of your defects to the core (such as ; or typo's), I was in a conversation with Mr. Watts Humphrey where lot of people asked him about the advancements of compilers and missing of object orientedness (which I felt, how is it missing, as I was an OO Programmer and was using it successfully). There was a very good answer provided by him. It went on like, "PSP, or as a matter of fact any process methodology, is not a concept thats stuck on a single idea. The core idea is to introduce people to the quality methods and analysis.
"Its always adaptive. You can tailor it to fit to your needs. If you feel like you will go with Function Point methodology, you are alright to go ahead with it. Same for any estimation techniques. But you should do it constantly and repetetively.
"Same with the advancement of compilers. If you feel like the WBS in the structure of PSP won't fit to your development, do modify it and use but again do it constinuously.
"As you do it continuously, you will have collected the historical data of yours and will be statistically do a predectable and accurate estimates on all the parameters"
May be I am giving this answer late but when I read all the replies, I felt I wanted to share this.
As per the tools, we have Process Dashboard, the PSP excel sheet and all.
回答4:
For the PSP, I have seen the Software Process Dashboard, but it seems awfully difficult to use.
回答5:
I have completed the PSP course, the next one is supposed to be TSP which is meant for team dynamics as others say. I have mixed feelings about PSP (mostly negative, but the results were interesting), I arrived to the following conclusions:
- First of all my main source of frustration is that the design templates are way too tedious and impractical. Change them for UML and BPMN, tell your instructors from the start, IMPOSE IF NECESSARY. The book itself says that the design templates are for people who don't know or want to learn UML.
- Secondly, estimations were the only valuable part for me. The book itself says that you can use other stuff appart from lines of code and it even tells you how to know how relevant they are statistically. My take on this (counting lines of code) is that a tool/plugin that connects with your VCS (git, mercurial) must exist and automate the building of your personal database, otherwise is too tedious to track base/added/reused parts.
- The process itself is nice, but not applicable to big projects, why?, because it just doesn't cope with iterations. In the real world, due to requirement changes you will always have to reiterate on a project. You can still apply the discipline to small programmatic tasks, this is: plan, design, review your design (have design standards and a small checklist that u can memorize), code, review your code (have clear coding standards and a small mental checklist you can memorize), test, ponder on your mistakes. Any experienced programmer will know these are eventually intuitive steps to follow. My recommendation in real practice: follow the process but don't document other stuff than your design, and if you do implement unit tests, document them well.
- This process might actually be worth to follow and practical... for real-time system programming where there is absolutely no room for mistakes, otherwise doesn't feel worth it.
- If you are seeking for a methodology to organize and improve focus, try GTD (Get Things Done) and Pomodoro first.
- If you have obsessive-compulsive disorder you might actually enjoy PSP =).
My final recommendation, learn from it as a reference, might lead to better and more practical stuff. This thing is just too academic.
P.S.: R.I.P. Watts Humphrey
回答6:
I've been using PSP for the last six months.
It is time consuming. For my estimations I had to spend 7% of my time filling forms. It is frustating to have to put the mistake "missing semicolon" over and over again.
But on the other hand as I get used to the process, it became important as I started to see which errors I was mainly doing and I started "naturally" avoiding them.
It also makes you "review" your code so you can see if there's any problem before hitting the compile button.
For tools I recommend using Timetracker: http://0xff.net/
I recommend at least trying PSP for a couple of months, because you will create some habits that help reduce the time you spend compiling and correcting minor bugs.
回答7:
I learned it just this last semester in college and it worked great for me. I know that by following it to the letter I can be confident I can hit Compile and won't have any errors and by hitting Run I won't have to spend time anymore fixing and re-compiling the program to run it again and again till the mess is fixed.
People complain about having to record the "missing semi-colons" and such but by the time you're on program 7, you're no longer making such trivial mistakes and instead your defects are found in the important bits of your program. I have not had the opportunity to apply it to a real scenario though but im really looking forward to!
回答8:
I try to follow the PSP 2.1 process when possible. It really helps me keep a focus on not skipping important, but less exciting, portions of a project. Usually this is design and design review for small projects.
To keep track of time you can use the PSP Dashboard, which has a bunch of built in features and scripts that help you follow the process.
If you are just looking for a time-tracking tool, I also like http://slimtimer.com. It can also do some decent reports.
回答9:
I followed the PSP for a few weeks some years ago, because my group wanted to experiment with it. I found it very disappointing and even irritating to work with. It exhausted my patience. My main negative points are:
- Ridiculous emphasys in things like typos or missing semicolons.
- Impractical forms that you have to fill by hand.
- Focus on procedural programming instead of OO.
- Estimating involves counting the number of loops, functions, etc.
I found it a massive waste of time. I'd rather choose to leave this profession than to be forced to follow the PSP.
Related material: My answer about a PSP book in the "What programming book would you NOT recommend to developers" question.
回答10:
I used it during university but at work we really don't have a process at all. Only recently have we started using version control.
My experience with it was that it seemed far too tedious to be useful. If it's not automated, then it can go away.
来源：https://stackoverflow.com/questions/28197/do-you-follow-the-personal-software-process-does-your-organization-team-follow