In Feb 2001, 17 prominent members of the software community came together and created the Agile Manifesto. From that moment on, agile development has gradually become known to the software development world.
I got to know agile development methodology back in 2004, while I was preparing for a Co-op interview. Agile development methods are a collection of development processes including Extreme Programming, Scrum, Crystal, etc. The company was using Extreme Programming (aka XP). I was intrigued by the flexibility that the XP brings to the table. It emphasizes team communication over rigorous design documents. It boasts ideas such as customer involvement, pair programming, test driven development (TDD), and refactoring.
At my first glance, XP seems really, well, Extreme. But when I dug more into it, the whole idea makes sense. It's like that new solar powered air conditioner. Not many people thought about it but when you get to know it. It simply just makes sense.
The classic waterfall methodology and some of its alternatives treat software development process as a traditional engineering process. The development cycle is divided into several phases and executed in sequence, which is seemingly a solid practice. In building construction. Detailed and specific documents were produced and followed. Engineers know exactly what the building is going to look like and how it's going to function. Every step is carefully calculated and measured. Why? Because they have only one chance to build it right. Just like a waterfall, there is no way back.
In my opinion, these methodologies miss some vital and obvious facts:
- Software is Soft. It's flexible and dynamic. It tends to change over its lifetime.
- Software developers are capable of, and usually have to, making ad-hoc decisions during development. Design documents and development rules are hard, if not impossible, to follow and enforce.
- Customers usually don't know what they want , therefore, it 's impossible to envision exactly what the final product will be.
On the contrary, agile methods are adaptive and flexible. It allows software to evolve by not trying to predict unforeseeable future. Instead, detailed analysis and up-front design are integrated into every step of the coding process. In other words, developers always have the confidence and agility to perfect the design. Unlike traditional methodologies which try to avoid requirement changes, agile methods expect the software to change and grow. From a software developer's perspective TDD and Refactoring are arguably the two most significant strategies in agile development. They raise the confidence level of the developers which in turn allow them to improve design and coding while programming.
Ok, Clearly, I've used too many vague and fancy adjectives to describe agile development. Agile development is a board subject so it's impossible to cover everything in a tiny blog entry especially with a entry labeled "My 2 cents on...". So I decide to end this gutless entry here and I will elaborate on more specific topics like TDD, refactoring, and team management as I continue my endeavor to conquer agile development.
book written by Jimmy Nilsson.I have always wondered how do domain-driven design, test-driven development and O/R mapper play together. Eric Evans's Domain-Driven Design: Tackling Complexity in the Heart of Software
