Tuesday, July 25, 2006

Agile development

For a long time, I have been wanting to write a blog on development methodologies, but haven't done so because I usually write the blog when I am satisfied with my survey of all the recent developments in that area. But methodologies are endless research so here is a brief overview of Agile which will be updated soon.

A brief overview first. Strictly speaking, Agile methods are not a methodology but a philosophy for modern application development. So there are specific methodologies like XP, Scrum, Crystal, Lean Development (from the Google article) which belong to the Agile class. It is absolutely true that most of our development happens that way and we should use Agile philosophy. As for RUP, it is a broad set of practices like use cases, iterations, documentation. Hence really speaking, RUP is a framework that can be fitted with many methodologies. For example, RUP can be used with XP (incidentally called dX - XP turned round on its head :)

When it comes to choosing a methodology, it is easy to fall into the trap of mix-and-match. For example, many organizations claim to follow a variation of XP, but all they are doing is - following the part of XP which says developers may not question the requirements, but conveniently forgetting that XP strictly specifies that only developers may give the estimates for the work. For the same reason, if we are to really follow Agile, we need to watch for conflicts. Agile clearly says that it is heavily dependent on people rather than just process-oriented. So it does not think of people as resources but as individuals, each of which has its own strengths and weaknesses and it is no longer possible to think of developers as pluggable units. It also changes the process itself if people want that.

I have also studied a bit on outsourcing using Agile methods. There are some big differences. First of all, usual Agile does not rely much on documentation but on close proximity between technical and business people. In outsourcing scenarios, this needs to be handled by more documentation. Practitioners believe that the amount of documentation should be "just enough", although this is determined only by experimentation across several projects. Secondly constant visits from both sides are necessary. Third is that business requirements should be written down at the client side and then test scenarios be written at the outsourcing side. Most important is that continous integration systems be in place, so that nightly builds can be taken any time the customer wants to see the current situation. I also believe that Agile methods have certain weaknesses, like lack of an integrated architecture, which can be well addressed by the software architecture artifact from RUP.