Agile software development (also called “agile”) isn’t a set of tools or
a single methodology, but a philosophy put to paper in 2001 with an initial 17
signatories. Agile was a significant departure from the heavyweight
document-driven software development methodologies—such as waterfall—in general
use at the time. While the publication of the “Manifesto for Agile Software
Development” didn’t start the move to agile methods, which had been going on
for some time, it did signal industry acceptance of agile philosophy. A recent
survey conducted by Dr. Dobb’s Journal shows 41 percent of development projects
have now adopted agile methodology, and agile techniques are being used on 65
percent of such projects.
Agile vs. waterfall: practical differences in methodology
The first software development methodologies were hardly methodologies
at all, but a free-for-all as organizations struggled to profit from new
computer-related technologies. As the industry learned more about developing
software, certain techniques for managing and predicting the cost of software
development projects came into use. The methodology that has dominated software
development projects for decades is called “waterfall.” Winston Royce coined
the term in 1970 to describe a serial method for managing software projects
through the five stages shown below
 |
| Agile vs Waterfall |
Adoption of waterfall has helped drive down the failure rate of software
development projects, but even with rigorous project management and processes,
a full 70 percent of software projects using this methodology fail to meet
their objectives. To put this in perspective, waterfall software projects have
less than half the success rate (66 percent) of going over Niagara Falls in a
barrel.
One of the most important differences between
the agile and waterfall approaches is that waterfall features distinct phases
with checkpoints and deliverables at each phase, while agile methods have
iterations rather than phases. The output of each iteration is working code
that can be used to evaluate and respond to changing and evolving user
requirements.
Waterfall assumes that it is possible to have perfect understanding of
the requirements from the start. But in software development, stakeholders
often don’t know what they want and can’t articulate their requirements. With
waterfall, development rarely delivers what the customer wants even if it is
what the customer asked for.
Agile methodologies embrace iterations. Small teams
work together with stakeholders to define quick prototypes, proof of concepts,
or other visual means to describe the problem to be solved. The team defines
the requirements for the iteration, develops the code, and defines and runs
integrated test scripts, and the users verify the results. Verification occurs
much earlier in the development process than it would with waterfall, allowing
stakeholders to fine-tune requirements while they’re still relatively easy to
change.
Link to the
presentation, Click here
No comments:
Post a Comment