Hello to All, I will be working for a client as Lead Architect at the start of next year on an EJB project. The client will not only undertake building a web infrastructure from the ground up but will concurrently develop a number of EJB/JSP based web applications to run on this new framework for pilot, before assessing what they have learned and moving on to new projects. My job is to assist the Project Manager in planning and cooordinating all of these projects, as well as designing the apps and leading the developers. Since we are essentially starting from scratch, I plan to introduce the client to the XP phenomenon and drive our development efforts that way. Does anyone have any experience with structuring an XP project (particularly a large project), and what advice do you have/lessons learned from that project?
Based on my experience I would make sure that XP is the right way to go. I assume you have done this so on we go... The very first thing I would do is to make sure everyone involved, particularly the client, is on board with this. (Does anyone scream in fear when you mention pair programming? This is a bad sign... :-)) Make sure everyone understands their roles particularly the person (or persons if there are multiple projects) who will be the Customer. John
The only reason for time is so that everything doesn't happen all at once.
- Buckaroo Banzai
My biggest question here is about what you mean by large. If there's more than about a dozen developers (which must be all in one place) then you're outside the comfort zone of XP and I would be very cautious about using it if you haven't tried XP before. Having said that, such practices as the Testing approach and the Continuous Integration would still be very useful Other than that I'd recommend the XP books (of course), web sites, maybe some questions on the XP egroup all to gather more information. We have some thoughts from our larger project in the Cutter IT Journal and will be posting updates to the web whenever I can catch Cara. Martin
author of:<br /><a href="http://www.amazon.com/exec/obidos/ASIN/0201485672/electricporkchop" target="_blank" rel="nofollow">Refactoring : Improving the Design of Existing Code</a><br /><a href="http://www.amazon.com/exec/obidos/ASIN/020165783X/electricporkchop" target="_blank" rel="nofollow">UML Distilled, Second Edition: A Brief Guide to the Standard Object Modeling Language</a><br /><a href="http://www.amazon.com/exec/obidos/ASIN/0201895420/electricporkchop" target="_blank" rel="nofollow">Analysis Patterns : Reusable Object Models</a><br /><a href="http://www.amazon.com/exec/obidos/ASIN/0201710919/electricporkchop" target="_blank" rel="nofollow">Planning Extreme Programming</a>
How about using a blend of heavyweight and lightweight methodologies? For example, using "pair programming" during the discovery of analysis classes. Could I medium-sized team combine the best of both worlds?
I have limited knowledge in XP, but in the years of experience that I have in the work force, XP (in concept)is really not that new. I tend to follow where Matt is going. The bottom line is the people involved. I know really great developers that do well in some environments and not in others (dont we all fit that discription). The role of the project manager is to build on the strengths of the developers, (not an easy task). Be leery of doing the 'hip' thing just because it is the 'hip' thing to do. Dont forget the guys that helped you get where you are now, doing it the 'old-fashioned' way.... there is still value in that. If you have a group that crave the bleeding edge, go for it...That type loves the blood. Good luck.
Thanks Pamela and Matt. No, these guys are certainly not bleeding edge types -- the transition to a transactional web framework and Java is quite enough. My thought was more around mentoring/knowledge sharing which could be done through pair programming, as well as rapid prototyping the first pilot applications. I like the XP approach, it has worked well for me in the past on singular projects, and I would like to pass it on to the client. To Martin's comment, I use the word "large" to really describe the amount of risk, the learning curve for the client, and the complexity of multiple dependent sub-projects. The programming team will be less than 10 (probably 6 people for application development). I think it will all depend on the client's appetite for XP. I will use the resources kindly provided to outline XP, its pros and cons, and construct a high level project plan.
You showed up just in time for the waffles! And this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop