This week's book giveaway is in the Mac OS forum. We're giving away four copies of a choice of "Take Control of Upgrading to Yosemite" or "Take Control of Automating Your Mac" and have Joe Kissell on-line! See this thread for details.
Good Day, XP is a very different methodology than what most developers/customers/managers are use to. And most references refer to XP being an all-or-nothing methodology. I would like to know if it is possible to incremently introduce XP into an organisation and what would be the best way to accomplish it.
"All-or-nothing" is a common misconception that a lot of people have about XP. In Extreme Programming Explained (XPE), you will find the following advice in Chapter 19 - Adopting XP: Adopt XP one practice at a time, always addressing the most pressing problem for your team. Once that's no longer your most pressing problem, go on to the next problem. Perhaps it would be more accurate to say that you will only garner the full benefits of XP when you have the full synergy of the entire set of practices. Also, some practices may not work well without the support of other related practices, such as Continuous Integration, Testing, and Refactoring. J.Lacar
Originally posted by Mark Ashworth: And most references refer to XP being an all-or-nothing methodology. I would like to know if it is possible to incremently introduce XP into an organisation and what would be the best way to accomplish it.
[This message has been edited by JUNILU LACAR (edited April 03, 2001).]
A typical step-by-step process might be to adopt unit testing, then refactoring, then planning game, small releases, continuous integration and pair programming as appropriate. The trick is to keep moving and keep adding to the XP "toolbox" until you have at least given a good try to the whole set.
Hi I have a small development company as an aside to what I do daily and we employ XP practices that have been able to easily integrate into our environment. Unit testing (love jUnit), refactoring, CRC cards and small interations of deliverables are the basis of all our projects, but, we can't get the 'client on site' and 'pair programming' done because the developers all work off site and I don't really have an office for my client. (The Garage get's kind of stuffy at times... ) We are also new to CVS (not VSS but now we have a total *nix environment) and we have clobbered our code because of the 'make code everyones' rule. Obviously this is not a fault of XP but of our lack of experience. This of course will change as we learn the environment. Since, at times, you can't know everything about everything we've had to be a bit stricter on making certain layers the responsibibility of one person who then delegates the object development/creation to the coders. So far it's worked but I can't wait to get all my coders in one building. P.S. Commenting.. we still demand that a person code the 'why' and not the 'what or how' of their code, but we've been noticing that it become more and more obvious 'why' something is happenning when we've got a nice design pattern wrapped around it.
[This message has been edited by John Bateman (edited April 03, 2001).]
for my own programming, the best thing I ever did was start to use the XP method of testing using JUnit. After every change, run your tests. After a while you have a test suite that tests every method, then you can see what was broken by your changes. This is great for developing classes and beans for JSP when you don't have an integrated IDE. By thoroughly testing before you add the class to the web-app u can be assured it is working the way u expect. Be sure to make the test fail the first time you write it so that u can be sure it is actually executing.
<BLOCKQUOTE><font size="1" face="Verdana, Arial">quote:</font><HR> fantastic, a towel? <HR></BLOCKQUOTE>