JeanLouis Marechaux

Sorry, DSDM is not very popular in Canada either.

About OpenUP, as stated in that post, I see it as a fair and sound process following the Agile principles.

Regarding the phases in open up, no need to be afraid. OpenUP really supports and encourages iterative development. Phases are just there to identified some key milestones through the whole delivery process

You cannot compare Agile to RUP.

First, Agile is not a methodology but a set of principle documented in the Agile Manifesto
RUP is a methodology for software and system delivery when the principles are documented, but also the roles, activities, and delivery processes (Work Breakdown structure to achieve a specific goal). So while Agile is identifying the theory, RUP gives elements also at the project plan level(WBS)

Second, Agile and RUP principles are very similar in essence. I know this statement is not popular in the Agile community, but it is so true. Take a look at Agile principles, and compare to RUP principles. It fits
* Adapt the Process
* Balance Competing Stakeholder Priorities
* Collaborate Across Teams
* Demonstrate Value Iteratively
* Elevate Level of Abstraction
* Focus Continuously On Quality

You can compare two different Agile methodologies though. Like RUP and XP for instance.
Some references can help:
Comparison of XP and RUP
using RUP for small projects

last, but not least, RUP is not only one methodology. It is a family of methodologies, all based on a common Core. And the most Agile element of that family is OpenUP

Other elements of the family are listed here

Some distributed Agile development were a real success.
For instance........ Eclipse.

The Eclipse team has created a process based on Agile, called The Eclipse Way

It is usually admitted that the more you need formalism, the more your process must be robust

Depending on your needs, you can adopt (and adapt) 3 different processes all based on Agile.
- OpenUP (small collocated teams)
- Eclipse Way (distributed teams, low level of formalism)
- RUP (distributed teams, traceability, high ceremony)

As every task (even non-IT), software development is easier, quicker, better when you have SMEs in your team.
This is also true for Agile
Take the example of Extreme Programming. XP comes from a collaborative work at Chrysler between Kent Beck and Ron Jeffries. Yes, it was a real project success. But how many among us are working daily with guys like K.Beck, R Jeffries, Erich Gamma or Grady Booch ?... hum... not that much.

So yes, your adoption of an Agile methodology will be harder that it was for gurus of the IT industry. But it does not mean you will not succeed.
You will also probably encounter problem they never had, and you never see in the literature. Agile is definitely not a magic bullet. But it is a way to organize your software development. So you will also gain from Agile practices.

It's amazing to see the 10 practices listed here :
1. Active user involvement is imperative
2. The team must be empowered to make decisions
3. Requirements evolve but the timescale is fixed
4. Capture requirements at a high level; lightweight & visual
5. Develop small, incremental releases and iterate
6. Focus on frequent delivery of products
7. Complete each feature before moving on to the next
8. Apply the 80/20 rule
9. Testing is integrated throughout the project lifecycle � test early and often
10. A collaborative & cooperative approach between all stakeholders is essential

... are similar to the practices listed here
* Adapt the Process
* Balance Competing Stakeholder Priorities
* Collaborate Across Teams
* Demonstrate Value Iteratively
* Elevate Level of Abstraction
* Focus Continuously On Quality

Btw, list #2 is extracted from RUP, that the initial website does not even mention :-)

Originally posted by John Todd:
Hi.
We all like Agile development, we all like to to write unit tests, to write beautiful code.
But in real world, do we have the luxury to be agile? or agile developement is kind of "Nervana" we will not never reach?
Thank.

I like this statement. It is probably closer to reality that any other statement claiming Agile is the way to go, and every non-Agilist is a stupid cow.
Even if Agile practices are a Nirvana, you can pick and choose some practices (and not all) to get closer to that Nirvana. Agile adoption can be incremental too, based on your environment, and not on the what pure methodologists think.

I believe you can see this on 2 different perspectives

1-On a philosophical perspective.
Using Agile practices and Scrum, filling in a timesheet does not really bring additional value to the team. It is is a valueless effort and you are not going to produce and deliver your application any faster with it

2-On a practical perspectives
The organization you work for always need to collect metrics on the time spent by employees on projects and tasks. We can argue it is useless, but just face it, that is the reality and we probably never be able to change that. Bean counters are there for quite long. So let�s live with them.

The best you can do to minimize the timesheet effects is to have coarse grained activities in that timesheet, to speed up the feeding process of that beast.

Hi Authors,

As Agile experts (and XP practioners), what is your opinion about other Agile approaches likes DSDM or RUP.

In particular, have you take a look at OpenUP, the Eclipse initiative for Agile processes.
http://www.epfwiki.net/wikis/openup/

Hi James & Shane.
I'm glad to see the promotion of such an Agile book on JR 1 Welcome onboard.

Could you please share with us a bit of your background. And I am not talking about your Agile involvment but more about:
- The kind of projects you worked in
- The kind of role you played in thoses projects
- The team size of the projects, and so on so forth.

Are you more involved aqs a Process guru, or a PM, or a developer ?
Thanks
/JL
[ October 30, 2007: Message edited by: JeanLouis Marechaux ]

You need a WebSphere Network Deployment version to be able to create multiple servers
http://www-306.ibm.com/software/webservers/appserv/was/network/

WebSphere 6 is J2EE 1.4 compliant.
So it supportsok.. EJB 2.1, as required by the J2EE specification

EJB 3.0 is not supported yet ( and as far as I know, there is no commercial app server that supports it). Don't forget the spec (JSR 220) as not been approved yet (so is not final)
It will be part of J2EE 5 (the next J2EE version)
[ September 14, 2005: Message edited by: JeanLouis Marechaux ]

So ? what is your question exactly ?
Are you looking for a code sample ?

If you have WebSphere, don't forget it comes with a couple of sample applications you can learn from

The WebSphere Infocenter is also a great source of information

Basically,

A server is a runtime environment, a process of execution.
A node is a grouping of servers that share common configuration. It is a physical machine.
A cell is a grouping of nodes into a sigle administrative domain. For websphere, it mean that if you group several servers within a cell, then you can administer them with one Websphere admin console

Need further details ??

Each time you think about creating design documentation, I would suggest to ask yourself the question :
"Who is going to benefit from this design documentation - Which level of granularity is sufficient for them ?"
Even if you are designing your application before implementing it, you should not go into to much details if there is not a specific identified need for it.
For instance, do you need an UML representation of all the classes (class diagram) of your system ? Maybe yes, maybe no. You have to decide based upon what you know of your organization, the way people use to work, the kind of doc they are comfortable with...
Maybe it's more important to depict the dynamic aspects through sequence diagrams ?
Mayge a high level UML doc is sufficient (Analysis diagrams of the RUP methodology), as Java IDEs now provide a really good way to document your system (the code is a good documentation, no ??)

This is also true when you are doing reverse engineering. It is not because a tool allows you to do it that the result will be useful for you. As Ilja said, the testing aspect could be far more interesting, and they document what you really want to do with your system.

Jignesh,

Some tools on the market are already implementing MDA concepts. For example, check this url.
And I agree with Lasse. You don't do MDA without PIMs.

Scott,
I agree with you, MDA will probably remain hard to understand for some developers. But if tools create PIMs to PSMs transformation, then the learning curve will be less important. We will see what vendors will provide...

Anyway, one key principle of MDA is to decouple the conceptual aspect from the implementation. This is not new. RUP already stresses on that technique for a couple of years now. The RUP logical view is also supposed to be neutrral regarding technologies. So MDA is only bringing normalized transformation on the table, while the concept is existing and widely used across organizations.

Finally, maybe MDA will find its audiance through MDD (Model Driven Development), extending the concepts to MDA later on.