XP

Started by
4 comments, last by Shannon Barber 22 years, 4 months ago
Has anyone around here ever been part of a team that used eXtreme Programming on any of thier projects? I''m curious to know how it was introduced, how the team reacted, and how well (or unwell) it worked out. Magmai Kai Holmlor "Oh, like you''ve never written buggy code" - Lee "What I see is a system that _could do anything - but currently does nothing !" - Anonymous CEO
- The trade-off between price and quality does not exist in Japan. Rather, the idea that high quality brings on cost reduction is widely accepted.-- Tajima & Matsubara
Advertisement
I''ve been on a team more or less using RAD. I can tell you what my experiences were there. Overall I would say it is short term gain in exchange for long term pain. I would also say that how soon an individual is disgruntalled because of the long term pain is inversely proportional to their experience and skill. I don''t have any experience with XP specifically so I won''t bore you with the details.
Keys to success: Ability, ambition and opportunity.
I tried hinting a few articles over to my "managers" but since they know crapp all about programming they probably through the articles in teh garbage XP looks interesting but... Even though a lot of people say they are team workers! 95% of them get anoyed having someone overlooking them... Also from what I understand XP is a bit chaotic.
Using any development methodology is a subjective business. On my last project we used a mix of XP and RUP, this mix was basically worked out on the fly ...

When RUP and or XP was a little too verbose, it was kicked in favor of an in-house method (based on XP/RUP, but modified to fit our needs.)

The same was true if XP/RUP was a too under specified.

On the positive side, XP''s Pair Programming went down well, after initial reservations. As did the Cue Card system.

On the down side, ''The Code is the Documentation'', was not accepted by the management. , but what do you expect.

As with all things try bits out and modify as required.
Actually for documentation...

In XP when you get the specs from client and you create the cue cards... Maybe before coding like mad, write the documents and then code. Makes sense no?
quote:Original post by ANSI2000
I tried hinting a few articles over to my "managers" but since they know crapp all about programming they probably through the articles in teh garbage XP looks interesting but... Even though a lot of people say they are team workers! 95% of them get anoyed having someone overlooking them... Also from what I understand XP is a bit chaotic.


Hah ha
I''ve been where you are... Of course the biggest problem to overcome is people are complacent and really not eager for change.

As far as your statement about XP being a bit chaotic - your correct but if you''ve ever been involved with a software project that was anything but chaotic XP wouldn''t work for you. XP tries to move and flow with that of the project... and every project that I have worked on in the past 8 years has had moving targets and missed deadlines... XP tries to correct this by allowing the development process to move with the changes.

It''s really just another methodology... that tries to work with the way real projects progress. NASA''s Software Engineering Lab has a methodology that many large companies use and most serious development house utilize some form of a methodology - the problem is that these methodologies are usually rigid and go against the actual way most of these company''s work. XP tries to blend with the way you do development... I''ve never used it... but I have been reading about it and think it does have potential.

Dak Lozar
Elysian Productions, Inc.
Dave Dak Lozar Loeser
"Software Engineering is a race between the programmers, trying to make bigger and better fool-proof software, and the universe trying to make bigger fools. So far the Universe in winning."--anonymous

This topic is closed to new replies.

Advertisement