Why "Agile" Software Development?
Submitted by J. Timothy King on Tue, 10/14/2008 - 03:17
Experts disagree on what “Agile development” exactly means, but here are some characteristics of Agile development and project management that I advocate and use. Compare them with traditional counterparts I’ve witnessed.
| Traditional development | Agile development |
|---|---|
| Deploy a new release only after all features are implemented, in a big-bang integration, and pray that everything works as expected. | Deploy frequently, in small iterations, and use the results to direct future development. |
| Do a project post-mortem, if anyone has any energy left. | Continuously improve, iteration by iteration, through reflection and iteration retrospectives. |
| Developers sit in different cubicles, sometimes in geographically separated parts of the office. | Developers communicate daily— and publicly, so that other developers can overhear their conversations. |
| Everyone is expected to multitask between different tasks and projects. | Each developer, once he begins a task, continues working on it until he finishes or gets stuck. |
| Throw a spec over the wall to development, and in a year (if you’re lucky), they’ll throw back software (and if you’re lucky, it’ll even work). | Developers have ongoing contact with expert users or their representatives (e.g., business analyst, product manager), who can direct development efforts toward the right result. |
| Rely on ad-hoc testing, on QA, or on users to catch bugs. | Deploy internal automated tests, at several levels of granularity (e.g., unit testing, subsystem testing, acceptance testing), to catch as many bugs as possible as quickly and cheaply as possible. |
| Spend 6 months drawing diagrams, without a single line of working code, then dive in to programming, without a harness, and continue tweaking the code until you feel good about it. | Diagram only as much of the system as you need to understand the next feature to implement, and write automated tests before coding, to tell you when you’re done. |
| Define project requirements by thinking of anything that sounds even the least bit kewl and then saying, “Yeah, we’ve gotta have that! We’ll fit it in somehow.” | Take tiny, realistic steps, by making tough choices about only the next, small iteration: “What if you had to choose between this must-have feature and that? Which one is really more important?” |
| “Done” is when the software developer thinks he’s finished coding. | “Done” is when the software actually works, as demonstrated by both automated and manual testing. |
| The release is always held up by a list of critical bugs, which must be fixed before it can go out. | There are rarely critical bugs that hold up a release, because there is rarely a list of critical bugs, because bugs are fixed as early in the process as they can be detected. |
| As the software becomes more complex, it becomes less maintainable and more expensive to enhance. | As the software becomes more complex, it becomes more maintainable, because developers regularly refactor poorly designed parts of the code to make them more maintainable. |
| “Refactoring” is a project in itself, entailing great risk to the system. | Refactoring is a common occurrence with little risk, because a suite of automated regression tests helps assure that the software continues to perform as expected. |
| Features are frequently difficult or expensive to add, because “if we touch this, we’ll break it.” | Features are usually easy and cheap to add, because the system is well designed, and the automated tests will tell us how to fix most of what we might have broken. |
Technorati Tags: 