Discussions

General J2EE: Methodologies used on your projects

  1. Methodologies used on your projects (7 messages)

    I am preparing myself for managing a java projects (I have managed many client server projects already).

    I am studying two methodologies right now:

    The Rational Unified Process

    and

    Extreme Programming

    I would greatly appreciate any input people can give me on these methodologies in practice. Are there are any others that people would recommend?

    Thanks

    Threaded Messages (7)

  2. Methodologies used on your projects[ Go to top ]

    This is my two cents worth. XP is OK for small projects with tight deadline. Although, I still have not been able to stomach the idea of dual programming and collective ownership.

    As your project gets bigger and more complex, you might be leaning towards RUP. The reality is that projects don't tend to follow any particular methodology exacactly. They adopt whatever works from different methodologies.

    Pranab
  3. XP is definitely not for everybody. I couldn't make a judgement about a "large project" which for me means more than 20 developers over more than 1 year. For as few as 10 developers, even over a longer timeframe, I have found XP to be far superior.

    The metric I'm using to determine which is better is the stakeholder satisfaction, the quality of the code base over a long period of growth, the flow of information between the team members (in the case of XP, the team will include representatives from the client/stakeholders and any nontechnical domain experts who will be part of the evaluation of the final result).

    If you're looking for an asscovering manouvre then XP is not for you. If you want reams of documents to choke down any attempts at fingering blame when dissatisfaction follows delivery, then I'd suggest RUP.

    Also, if you ask XP people, if you're not doing pair programming, you're not doing XP. The seven practices which make up XP are mutually supportive and will not work properly if you pick and choose the ones you like.

    Christo.
  4. Methodologies used on your projects[ Go to top ]

    There are several critical insights of XP that I think should be integral to any project, regardless of the overall methodology used.

    Test everything. All the time. Implement a JUnit testing methodlogy. It takes a little time upfront to learn the API and the approach but saves so much time in the long run that you will shudder to think about your days before Junit. Seriously. Unit test with Junit or a similar system.

    Everyone owns the code. This is the best way to share knowledge and build a robust codebase. Different minds and experiences bring different insights...rotate the code through the team and overall quality improves as critical assumptions are revealed as innaccurate and techniques refined by fresh insight. Next to testing, this is in my opinion the most critical and valuable feature of XP. (Perhaps arguments can be made suggesting that a large part of the success of the Open Source movement lies in collective code ownership).

    Test everything. All the time.

    Design & Code are linked. This is actually part of the RUP, in a way. RUP says that you can't architect anything unless you have some code to prove the concept (I forget exactly but it is something like 80% of the system (in effort, not in lines of code)) should be complete as you move into the implementation phase. XP goes a little further in this regard and says that design and code are almost the same thing. This is a great concept, because you end up with an approach that is flexible and responds well to change. Rather than working with big up-front designs that lock you into a particular approach, you can move rapidly to new architectures as insight from practical experience provides critical design decisions.

    Test everything. All the time.



  5. Methodologies used on your projects[ Go to top ]

    Testing, eh?

    I like all XP concepts except paired programming. As long as you exercise frequent code reviews I feel paired programming is not necessary. Ok, so I'm picking and choosing features of XP.
  6. I agree with Jeff. I prefer thorough design and code review by peers over pair programming and collective ownership.

    Pranab
  7. Methodologies used on your projects[ Go to top ]

    Thanks for all the great input! I'm still quite new to XP. I can see how parts of it could work great, but like most people there are parts that I have not accepted yet. I did find a pretty active group on Yahoo groups called: extremeprogramming . I have not been able to find a good group dealing specifically with RUP, any suggestions?

      
  8. Methodologies used on your projects[ Go to top ]

    Does anyone know of a methodology which is kind of like a RUP Lite? I know I could just pick and choose parts, but it would helpful to have logical subset that has proven useful.

    I'm still learning about Extreme Programming and find it really interesting. But it seems like it could be a hard sell to management and takes a great deal of trust to implement fully (keep in mind that I am still learning it, before you jump on that, thanks).


    Thanks