Introduction
Waterfall model follows application
development in phases with checkpoint and deliverable documents in each
checkpoint. It advocates rigours project management, strategy and processes to
track the status. The main drawback is that it requires more than 80% project
understanding before kicking off the project which is impossible in major
cases. Cause of volatile requirements and understanding business feels, 80% of
software projects using this methodology fail to meet their objectives.
Typical
Waterfall Model
Agile
Methodology
Agile mythology has small box
iterations rather than phases. The output of each iteration will be production
release deliverable and could be evaluated and get early feedback.
Agile was a significant departure
from the heavyweight document-driven software development methodologies—such as
waterfall—in general use at the time.
Agile refers to more collaboration
and interaction between different departments at enterprise level and delivers
the successful product with individual contribution.
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.
It promotes adaptive planning,
evolutionary development & delivery, a time-boxed iterative approach, and
encourages rapid and flexible response to change.
XP
(Extreme Programming
It advocates frequent “release” in
short development cycles, each release follows with several iterations. When
the product release has enough features to satisfy the user, the team
terminates iteration cycle and releases the software.
Other elements of Extreme
Programming include: programming in pairs, continuous integration, add only
needed features for a particular release.
Users write a story which helps the
team to estimate the time to build the release and to define acceptance
testing. A user is a part of XP team and adds the detail requirement as the
software is being built. This allows requirements to evolve as both users and
developers define what the product will look like.
- Continuous Integration: Integrate often at least once a day using automated
continuous integration tool
- Pair Programming:
Pair programing to extensively code review while coding
- Project velocity:
Velocity is a measure of how much work is getting done on the project.
This important metric drives release planning and schedule updates.
Scrum
Scrum is a way for teams to work
together to develop a product wherein requirement changes rapidly during
development. Product development, using Scrum, occurs in small pieces, with
each piece building upon previously created pieces. Building products one small
piece at a time encourages creativity and enables teams to respond to feedback
and change, to build exactly and only what is needed. Unlike XP, Scrum
methodology includes both managerial and development processes.
- Sprints:
Short development process
- Stand up meeting:
Daily 10 minutes meeting status of the work to be done that day, progress
from the day before, and any blocks that must be cleared
- Scrum Master:
The ScrumMaster is the person responsible for managing the Scrum project
- Sprint backlog:
Sprint backlog is the list of backlog items assigned to a sprint, but not
yet completed.
- Burn down chart:
This chart, updated every day, shows the work remaining within the sprint.
The burn down chart is used both to track sprint progress and to decide
when items must be removed from the sprint backlog and deferred to the
next sprint.
- Product backlog:
Product backlog is the complete list of requirements
Agile: The Pros
Agile offers an incredibly flexible
design model, promoting adaptive planning and evolutionary development. Agile
might be described as freeform software design. Software developers work on
small modules at a time. Customer feedback occurs simultaneously with
development, as does software testing. This has a number of advantages,
especially in project environments where development needs to be able to
respond to changes in requirements rapidly and effectively.
Agile can be especially beneficial
in situations where the end-goals of projects are not clearly defined. For
example, if you are working with a client whose needs and goals are a bit hazy,
it is probably worthwhile to employ the Agile method. The client’s requirements
will likely gradually clarify as the project progresses, and development can
easily be adapted to meet these new, evolving requirements. Agile is also an
excellent option for experimental software design.
Lastly, this method also facilitates
interaction and communication – collaboration is more important here than
design. Because interaction among different designers and stakeholders is key,
it is especially conducive to teamwork oriented environments. Different
developers work on different modules throughout the development process and
then work to integrate all of these modules together into a cohesive piece of
software at the end of the project.
Waterfall: The Pros
The emphasis of Waterfall is the
project plan and therefore before beginning any kind of development there needs
to be a clear plan and a clear vision in order. Because the Waterfall method
requires upfront, extensive planning, you can launch software fairly quickly.
You can also estimate timetables and budgets more accurately, which definitely
tends to please clients.
Furthermore, Waterfall development
processes tend to be more secure because they are so plan oriented. For
example, if a designer drops out of the project it isn’t a huge problem, as the
Waterfall method requires extensive planning and documentation. A new designer
can easily take the old designer’s place, following the development plan
without a problem.
Agile: The Cons
Though highly flexible, Agile simply
doesn’t have the structure that the Waterfall method has and this does present
some drawbacks. Agile projects tend to be hard to predict, from timelines to
budgets. Without a concrete plan, everything remains a bit vague and nebulous.
In addition, as previously
discussed, active user involvement and intense collaboration are required
throughout the Agile process. This can prove highly problematic for a number of
reasons. First of all, this method of development can be quite time consuming,
much more time consuming than the Waterfall method. And, it means that
designers need to be committed for the duration of the project. If a designer
leaves in the midst of a Waterfall method development project, it likely won’t
be too big of a deal as the project is plan based. In the case of the Agile
method, however, development is much more person based. Having a person drop
out of the project could prove catastrophic.
Waterfall: The Cons
The Waterfall method is incredibly
rigid and inflexible. Altering the project design at any stage in the project
can be a total nightmare and once a stage has been completed, it is nearly
impossible to make changes to it. So, if you’re planning to use Waterfall, you
will need to gather all of the requirements upfront. In addition, the problem
with the Waterfall method is that feedback and testing are deferred until very
late into the project. So if there is a problem, it is very difficult to
respond to it, requiring a substantial amount of time, effort, and sometimes
money.
So, What’s Better?
When it comes down to it, neither
the Agile method nor the Waterfall method is inherently better than the other.
That being said, each method does have its uses. Waterfall tends to be best for
static projects, where it’s not likely that many changes will be made
throughout the development process. In contrast, Agile tends to be a better
option for smaller projects where changes are likely to be made during the
design process. Though, keep in mind that these are just rough guidelines and
suggestions. Really, when it comes to choosing a method there is not a right or
wrong choice. You just need to understand which method is better suited to your
project and your needs.
Thanks
R.karthikeyan
