Tuesday, November 14, 2006

The Nirvana Method - aka my first mental scribblings

The following is something I wrote - the first thing actually - to vent my frustrations of tenory versus practice.

I’ve decided to come up with a methodology for developing software. Now before I get in to it I should warn you that I am not a techie, and do not (and have never) written code for a living. I have worked (in no particular order) as a systems analyst, business analyst, requirements analyst, information architect, and interaction designer. The Nirvana Method is my take on an ideal methodology. For me, this would combine the theoretical elements of RUP and the practical guidance offered by AGILE methods.

RUP out of the box is a giant beast of a thing, to even begin to use it you need to throw a good chunk away as your organization does not use/want/need* all of the roles/artifacts/activities* that comes as standard (* delete as needed). RUP then needs to be tweaked, which leads me to the conclusion that it is mostly a theoretical approach to software development.

AGILE methodologies are in essence a backlash against waterfall methodology and crushing documentation and processes that leave countless projects stuck in the mud. When looking at the AGILE Alliance site, especially the article “An Introduction to Agile Methods” that uses XP as an example, that the AGILE approach is aimed at getting the job done. AGILE deals with the more practical approach to developing software, for example pair programming and promoting single location teams (XP).

What are the common points of RUP and an AGILE method?
Iterative Development;
Deliver working software at the end of each iteration;
Highest Risks First (technical, business, usability);

OK then, what is specific to an AGILE methodology?
Define functionality as stories;
Programming in pairs;
Test Driven Development;

What is specific to RUP?
Model the business domain;
Define functionality as use cases;
Use Case Driven Development;
Work with components;

And what is just Common Sense (never to be underestimated)?
Communication as a key success factor;
Individuals as a key success factor;
Customer and end user involvement;
Requirements will change;
Planning will change;
Learn as you go, write better code (refactor);
It costs less to fix a requirement than an application.

So my big question is why cannot all of the above elements be combined? It can, the Nirvana Method. The Nirvana Method:

An iterative development methodology that delivers working software at the end of each iteration, attacking the highest risks functionality first based on a sound understand of a specific business goal(s) and environment.

The Nirvana Method believes that communication, individuals, customer involvement, and user centered design are critical success factors that are needed to combat the reality of changing requirements, priorities and planning.


OK, so it is not really a method; more like a statement of how I would like projects I am involved with to work.

No comments: