Agile software development practices

June 12, 2008 · Filed Under Software development, Web development 
From: Shawn Gay

I am a big believer in iterative software development. The Agile model for software development is the one I currently look to for guidance in steering my projects. At the heart of the Agile model is the set of principles expressed in the Agile Manifesto.

It’s been said over and over, but the traditional waterfall process of software development is setting your project up to fail. The biggest problem with developing software is managing the risk involved in constructing something as complex as a software program. This is what iterative development models are designed to do: manage project risk.

One large risk with software development is the possibility that the end-product does not really solve the problem the customer needs. It is effectively impossible for a software developer to know and understand all of the requirements that the final application should satisfy for the customer and end-users. Iterative development models, like Agile, admit this fact up front and require the developer to get frequent feedback from the project stakeholders by showing snapshots of the development along the way. For this to work, it is important for the developers to produce quasi-stable applications early on and have testable product versions available at frequent intervals. A typical interval is every two to four weeks, although it should vary according to the project and the development team.

A second major risk for software development is the possibility that major changes to the architecture need to be made late in the project. As any seasoned developer knows, this is a scary prospect, as changes in the core architecture can propagate through the system producing hard to find bugs. Iterative development schemes aim to identify high-risk components and develop these along with the core architecture components during early iterations. This way, higher-risk activities are undertaken early on, and consequences of any complications can be dealt with early rather than late in the project life. If something does not go right, or if the complexity is much greater than originally anticipate, it is much better to know early in the project.

One of the best resources for Agile development out there is Scott Ambler’s website. In particular, his material on the Agile Unified Process, a modification of the well known Rational Unified Process is a must read.

Tags: , , , ,

Comments

Leave a Reply