Agile Development

Reflecting the use of Agile Methodologies on overall Server Side Design and Development

by Igor Stoyanov.

Agile methodologies are alternative approach to the traditional Engineering Methodologies. The most immediate difference is that they are less document-oriented, usually emphasizing a smaller amount of documentation for a given task. In many ways they are rather code-oriented: following a route that says that the key part of documentation is source code. However, a more precise picture could be drawn with a short excerpt from the article “The New Methodology” written by one of the founders of Agile Manifesto, Martin Fowler:

• Agile methods are adaptive rather than predictive. Engineering methods tend to try to plan out a large part of the software process in great detail for a long span of time, this works well until things change. So their nature is to resist change. The agile methods, however, welcome change. They try to be processes that adapt and thrive on change, even to the point of changing themselves.
• Agile methods are people-oriented rather than process-oriented. The goal of engineering methods is to define a process that will work well whoever happens to be using it. Agile methods assert that no process will ever make up the skill of the development team, so the role of a process is to support the development team in their work.

The rest of this article is invaluable information about Agile Methodologies and there are many references to related links and materials. I will strongly suggest reading this article if you are interested in Agile Methodologies.

However, my purpose is not to do and overview of Agile Methodologies rather than I will look at only a few aspects of agile that I believe have very strong influence on the overall software design during software development of a business driven project.

Agile development is characterized mainly by using two to four weeks iterations. In the beginning of every iteration, the team commits to deliver some number of story cards. A story card is similar to the user cases defined in traditional software engineering process. The main and very essential difference that story cards has limited set of functionality so that the team can deliver it at the end of the iteration. Furthermore, everything in the story card should be driven by the business requirements.

This methodology influences the software design in the following two very essential ways:

1. The team is committed to deliver working product at the end of the iteration – avoid 80:20 problem in software development.
2. Develop functionality that is only business needed driven – doesn’t over design the current systems and produce much cleaner and maintainable code base.

There are many more consequences to add, but all other essential ones are summarized in XP development process, which is a subset of agile methodologies by itself