SCRUM is a loose set of guidelines
that govern the development process of a product, from its design stages to its
completion. It aims to cure some common failures of the typical development
process, such as:
- Chaos due to changing requirements - the real or perceived requirements of a project usually change drastically from the time the product is designed to when it is released. Under most product development methods, all design is done at the beginning of the project, and then no changes are allowed for or made when the requirements change.
- Unrealistic estimates of time, cost, and quality of the product - the project management and the developers tend to underestimate how much time and resources a project will take, and how much functionality can be produced within those constraints. In actuality, this usually cannot be accurately predicted at the beginning of the development cycle.
- Developers are forced to lie about how the project is progressing - When management underestimates the time and cost needed to reach a certain level of quality, the developers must either lie about how much progress has been made on the product, or face the indignation of the management.
SCRUM has been successfully employed
by hundreds of different companies in many different fields, with outstanding
results.
You will find many similarities
between SCRUM and Extreme Programming, but one of the major differences is that
SCRUM is a fairly general set of guidelines that govern the development process
of a product. For this reason, it is often used as a "wrapper" for
other methodologies, such as XP or CMM (Capability Maturity Model) - that is,
it is used to guide the overall process of development when using these other
methodologies.
The SCRUM values are derived from
the Agile values of software development.
- Individuals and interactions over processes and tools - processes and tools are helpful, but they will do you no good if the team does not communicate and collaborate in a constructive fashion.
- Working software over comprehensive documentation - documentation is important, but what's most important is to have working software.
- Customer collaboration over contract negotiation - you are not just looking to get a contract and get money that way - you are solving the customer's problem.
- Responding to change over following a plan - if the requirements or perceived requirements changed, so should the plans and design.
Figure
1: General SCRUM Process
The scrum process has 3 main phases.
In this phase, the project is
planned and high-level design decisions are made.
Figure
2: The SCRUM Sprint Cycle
The sprint cycle is an iterative
cycle of about 3-4 weeks, in which the actual development of the product is
done. It starts out with a Sprint Planning Meeting to decide what will be done
in the current sprint. Then the development is done. A sprint is closed with a
Sprint Review Meeting where the progress made in the last sprint is
demonstrated, the sprint is reviewed, and adjustments are made to the project
as necessary.
The sprint cycle is repeated until
the product's development is complete. The product is complete when the
variables of time, quality, competition, and cost are at a balance.
- Develop the product further - implement, test, and document.
- Wrap up the work - get it ready to be evaluated and integrated.
- Review the work done in this sprint.
- Adjust for any changes in requirements or plans.
In this phase, the product's
development is brought to a close, and the product is released.
The SCRUM team consists of 2 groups
- the interested team, which consists of people who are interested, but who
will not be doing the work, and the working team - people who are interested,
and will be doing the work on the project.
A team typically has no more than
6-9 working members, although SCRUM has been successfully used with more members.
If there are more members than manageable, the project should be broken into
multiple sub-projects, each focusing on one, self-contained area of work (one
for QA, one for documentation, etc.). There should be people to act as bridges
- that is, to attend the meetings of more than one SCRUM team, and act as a
communication bridge between the teams. Members of teams that are closely
related/involved with each other should sit in on the other teams' SCRUM
meetings.
The team's leader is called the
Scrum Master. He should be one of the members of the working team - that is, he
should be one of the people who is actually doing the work on the project. The
SCRUM Master measures progress, removes impediments, and leads the team
meetings.
The product is developed in a series
of 1-to-4-week iterations, or sprints. Before a sprint is begun, a Sprint
Planning Meeting is held to determine what features are to be implemented in
that sprint. The sprint has 4 major steps:
- Develop the product further - implement, test, and document.
- Wrap up the work - get it ready to be evaluated and integrated.
- Review the work done in this sprint.
- Adjust for any changes in requirements or plans.
A prioritized list of all the
desired changes to the product being developed, put together by the product
owner. See Figure 2.
A list with items that will be
completed in the current sprint, taken from the product backlog. See Figure 2.
A 15-minute SCRUM meeting is held
every day. The SCRUM Master asks the three questions, and all members of the
team and interested parties take part and give feedback. The meeting should be
held at the same place every time, so that people know where to go.
A unit test is an automated test
that ensures that the functionality required for a certain area of a project is
implemented, and that there are no breaking changes that have not been taken
into consideration. See http://www.xprogramming.com/software.htm for a list of unit testing frameworks for different
languages/platforms.
Impediments are things that get in
the way of the progress of the project. The SCRUM Master is responsible to look
for and remove these obstacles so that they do not slow down or impair the
project.
The Scrum Master asks the developers
3 important questions at every SCRUM meeting:
- What have you accomplished since the last meeting?
- Are there any obstacles in the way of meeting your goal?
- What will you accomplish before the next meeting?
The person who commissions the
project, and defines the requirements and priorities for the product.
A meeting at the beginning of a
sprint where the sprint is planned. Items from the Product Backlog are selected
to be completed in the sprint, based on the priorities set by the Product
Owner.
A sprint is closed with a Sprint
Review Meeting where the progress made in the last sprint is demonstrated, the
sprint is reviewed, and adjustments are made to the project as necessary.
-----------------------------------------*^%^&%^&------------------------------------------------------
There
is no IT meeting that does not talk and debate endlessly about Waterfall vs.
Agile development methodologies. Feelings run strong on the subject with
many considering Agile ‘so of the moment’, just so right, while Waterfall
is thought to be passé! But, before deciding which is more
appropriate, it is essentially important to provide a little background on
both.
Waterfall
A
classically linear and sequential approach to software design and systems
development, each waterfall stage is assigned to a separate team to ensure
greater project and deadline control, important for on-time project
delivery. A linear approach means a stage by stage approach for product
building, e.g.
1.
The
project team first analyses, then determining and prioritising business
requirements / needs.
2.
Next,
in the design phase business requirements are translated into IT
solutions, and a decision taken about which underlying technology i.e. COBOL,
Java or Visual Basic, etc. etc. is to be used.
3.
Once
processes are defined and online layouts built, code implementation takes
place.
4.
The
next stage of data conversion evolves into a fully tested solution for
implementation and testing for evaluation by the end-user.
5.
The
last and final stage involves evaluation and maintenance, with
the latter ensuring everything runs smoothly.
However,
in case a glitch should result, changing the software is not only a practical
impossibility, but means one has to go right back to the beginning and start
developing new code, all over again. That’s Waterfall for you! Now,
as for minimal risk Agile, it is a low over-head method that emphasizes values
and principles rather than processes. Working in cycles i.e. a week, a
month, etc., project priorities are re-evaluated and at the end of each
cycle. Four principles that constitute Agile methods are:
1.
The
reigning supreme of individuals and interactions over processes and tools.
2.
As
does, working software over comprehensive documentation.
3.
Likewise,
customer collaboration over contract negotiation.
4.
And
again, responding to change over plan follow-throughs.
To
synopsise the difference between the two, one can say the classic waterfall
method stands for predictability, while Agile methodology spells
adaptability. Agile methods are good at reducing overheads, such as,
rationale, justification, documentation and meetings, keeping them as low as is
possible. And, that is why Agile methods benefit small teams with
constantly changing requirements, rather more than larger projects.
Agile,
based on empirical rather than defined methods (Waterfall) is all about light
maneuverability and sufficiency for facilitating future development. By
defined methods what one means is that one plans first and then enforces these
plans. However, Agile methods involve planning what one wants and then
adapting these plans to the results. Extreme Programming (XP) is an
excellent example of Agile methodology i.e.:
1.
Communication between customers and other team members;
2.
Simple, clean designs;
3.
Feedback given on Day 1 of software testing;
4.
Early delivery and implementation of suggested changes.
Agile
methodology means cutting down the big picture into puzzle size bits, fitting
them together when the time is right e.g. design, coding and testing
bits. So, while there are reasons to support both the waterfall and agile
methods, however, a closer look clarifies why many software and web design
firms make the more appropriate choice of employing Agile methodology.
The following table enumerates the raison d’être for choosing Agile methodology
over the Waterfall method.
- Once a stage is completed in the Waterfall method, there is no going back, since most software designed and implemented under the waterfall method is hard to change according to time and user needs. The problem can only be fixed by going back and designing an entirely new system, a very costly and inefficient method. Whereas, Agile methods adapt to change, as at the end of each stage, the logical programme, designed to cope and adapt to new ideas from the outset, allows changes to be made easily. With Agile, changes can be made if necessary without getting the entire programme rewritten. This approach not only reduces overheads, it also helps in the upgrading of programmes.
- Another Agile method advantage is one has a launchable product at the end of each tested stage. This ensures bugs are caught and eliminated in the development cycle, and the product is double tested again after the first bug elimination. This is not possible for the Waterfall method, since the product is tested only at the very end, which means any bugs found results in the entire programme having to be re-written.
- Agile’s modular nature means employing better suited object-oriented designs and programmes, which means one always has a working model for timely release even when it does not always entirely match customer specifications. Whereas, there is only one main release in the waterfall method and any problems or delays mean highly dissatisfied customers.
- Agile methods allow for specification changes as per end-user’s requirements, spelling customer satisfaction. As already mentioned, this is not possible when the waterfall method is employed, since any changes to be made means the project has to be started all over again.
- However, both methods do allow for a sort of departmentalization e.g. in waterfall departmentalization is done at each stage. As for Agile, each coding module can be delegated to separate groups. This allows for several parts of the project to be done at the same time, though departmentalization is more effectively used in Agile methodologies.
In
conclusion, though on the plus side, waterfall’s defined stages allow for
thorough planning, especially for logical design, implementation and
deployment, Agile methodology is a sound choice for software development and
web design projects. More and more firms are becoming Agile!
A lot of people do prefer it when they are through production or its about how well things needs to be planned.This is what my opinion is at the same time it isn't that confidential for what something like that is necessary,Its all cool you just need understand difference between agile and scrum and that will take everything on another level.
ReplyDelete