Describe Agile SDLC Model ?
Agile methods generally promote a disciplined project management process that
encourages frequent inspection and adaptation, a leadership philosophy that
encourages teamwork, self-organization and accountability, a set of engineering
best practices that allow for rapid delivery of high-quality software, and a
business approach that aligns development with customer needs and company goals
Agile methods break tasks into small increments with minimal planning, and
don't directly involve long-term planning. Iterations are short time frames
("timeboxes") that typically last from one to four weeks. Each iteration is
worked on by a team through a full software development cycle including
planning, requirements analysis, design, coding, unit testing, and acceptance
testing when a working product is demonstrated to stakeholders. This helps
minimize overall risk, and lets the project adapt to changes quickly.
Stakeholders produce documentation as required. An iteration may not add enough
functionality to warrant a market release, but the goal is to have an available
release (with minimal bugs) at the end of each iteration. Multiple iterations
may be required to release a product or new features
Team composition in an agile project is usually cross-functional and
self-organizing without consideration for any existing corporate hierarchy or
the corporate roles of team members. Team members normally take responsibility
for tasks that deliver the functionality an iteration requires. They decide
individually how to meet an iteration's requirements
Agile methods emphasize face-to-face communication over written documents when
the team is all in the same location. When a team works in different locations,
they maintain daily contact through videoconferencing, voice, e-mail, etc
Each agile team will contain a customer representative. This person is appointed
by stakeholders to act on their behalf and makes a personal commitment to being
available for developers to answer mid-iteration problem-domain questions. At
the end of each iteration, stakeholders and the customer representative review
progress and re-evaluate priorities with a view to optimizing the return on
investment and ensuring alignment with customer needs and company goals
The Agile Manifesto states:
We are uncovering better ways of developing software by doing it and helping
others do it. Through this work we have come to value:
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on
the left more.
The waterfall model is the most structured of the methods, stepping through
requirements-capture, analysis, design, coding, and testing in a strict,
pre-planned sequence. Progress is generally measured in terms of deliverable
artifacts: requirement specifications, design documents, test plans, code
reviews and the like.
The main problem with the waterfall model is the inflexible division of a
project into separate stages, so that commitments are made early on, and it is
difficult to react to changes in requirements. Iterations are expensive. This
means that the waterfall model is likely to be unsuitable if requirements are
not well understood or are likely to change in the course of the project.
Agile methods, in contrast, produce completely developed and tested features
(but a very small subset of the whole) every few weeks. The emphasis is on
obtaining the smallest workable piece of functionality to deliver business
value early, and continually improving it and adding further functionality
throughout the life of the project. If a project being delivered under the
waterfall method is cancelled at any point up to the end, there is nothing to
show for it beyond a huge resources bill. With the agile method, being
cancelled at any point will still leave the customer with some worthwhile code,
that has likely already been put into live operation