XpLite is an attempt to describe a subset of XP which could or should be implemented as an intermediate step or steps between traditional HeavyWeight? methodologies and full XP.
XpLite is what people are using while they are trying to get the group to adopt ExtremeProgramming. It is a collection of bits and pieces they can put into place first, and this page discusses which bits and pieces they should put into place first. There is a list of pointers to projects that might have been XpLite.
There is some belief that XpLite is bad because the concept diluttes the message of Xp.. This is not that page. That discussion may be found at XpLiteConsideredHarmful. There is some belief that XpLite is bad because the name dilutes the XpName?. Discussion about renaming XpLite may be found at XpJr.
There is some argument as to whether or not even the concept of XpLite is a good thing. This is not that page. That discussion may be found at WhyXpLite.
" What we did [on VcapsProject] was to examine what was hurting our project the most and try to fix it. In our case we had oodles of bugs. Many were of the type MessageNotUnderstood?. It was clear that automated testing would help that problem. It was irrelevant that testing was one of the cornerstones of XP. " -- DonWells
If you want something light, that isn't yet XP, and that doesn't infringe on the XP name, then look at the CrystalClearMethodology, which is another of the MinimalMethodologies. Just be sure to implement automated regression unit tests as the first inching towards XP.
XpLite might be some BigDesignUpFront + UnitTests + ReFactoring and tighter iterations. That is a stable configuration and it allows people to back out of corners. It is an easier pill to swallow and it is something that XP will have to beat or embrace if it ascends.
My suggestions, based on the ExtremeRules
1. Begin with ExtremeCoding
Problems
How to introduce PairProgramming?
What if politics keep the customer from being involved?
How to make the next step?
Even if you are not able to get full PairProgramming instilled, you can make some strides towards more collaborative development. If you don't know how to do something, ask someone else for help. If they will sit down with you, you've accomplished something. Also, every time someone asks you for help, do it, enthusiastically. These are little pieces but they can help migrate a culture. -- MichaelFeathers
If I were going to introduce XpLite, I'd try to focus on getting to the heart of the matter:
Suppose we ask the boss to let us do a SpikeSolution of XP. That is, we request permission to do do full-throttle XP for 6 weeks (two iterations). By then, we will have done something good to the product under development, and we'll have a bunch of happy XP proponents who will leave the company before going back to the old ways. Anyone game to try?
I'm not worried about persuading the boss. I'm worried about persuading the other programmers! I'm probably not doing a good job of selling XP but they don't want to let go of the SecurityBlanket? practices. They hate writing requirements and design documents - they don't do a good job on them, and we generally ignore them once we reach the coding stage, but can I suggest that there's a better way to do it? No......................
I'd recommend 6 1-week iterations. You'll get more practice and have more data. -- KentBeck
Are you trying to convince your peers to use XP on legacy code? I have found that is doubly difficult; code is generally not testable (lots of abstract classes, good layering) unless testability has been built in from the start. Perhaps choosing a new project or sub-system and doing XP on that will help. A clean slate can encourage people to branch out a bit. -- IanRae
See TransitioningToExtremeProgramming, PathDependence