Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                

Agile Software Devlopment

Download as pptx, pdf, or txt
Download as pptx, pdf, or txt
You are on page 1of 23

Agile software

development
A

SUBMITTED BY
SAJJAN KUMAR BARLA
REGD.NO.0821227050
GROUP-B
Introduction
A

Agility is dynamic, context-specific, aggressively

change-embracing and growth oriented.


Definition
A
Agile software development is a group of
software development methodologies based on
iterative and incremental development, where
requirements and solutions evolve through
collaboration between self-organizing, cross-
functional teams.
Self-organization is the process where a structure
or pattern appears in a system without a central
authority or external element imposing it through
planning.
A cross-functional team is a group of people with
different functional expertise working toward a
common goal.
Predecessors

Incremental software development methods have


been traced back to 1957.
In 1974, a paper by E. A. Edmonds introduced an
adaptive software development process.
So-called lightweight software development
methods evolved in the mid-1990s as a reaction
against heavyweight methods.
lightweight methodology

A lightweight methodology is a software development


methodology which has only a few rules and practices or ones
which are easy to follow. In contrast, a complex methodology
with many rules is considered a "heavyweight methodology".
Some examples of lightweight methodologies are:
Adaptive Software Development by Jim Highsmith (1995)
Crystal Clear (1996).
Extreme Programming (XP)(1996) .
Feature Driven Development (FDD) (1995)
ICONIX .
These are now typically referred to as agile methodologies, after
the Agile Manifesto published in 2001.
Agile Manifesto

In February 2001, 17 software developers met at a


ski resort in Snowbird, Utah, to discuss lightweight
development methods. They published the
Manifesto for Agile Software Development to
define the approach now known as agile software
development.
Agile Manifesto

Agile Manifesto reads, in its entirety, as follows…


 We are uncovering better ways of developing software by
doing it and helping others do it. Through this work we
have come to value:
 Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Agile Manifesto
Twelve principles underlie the Agile Manifesto, including:
 Customer satisfaction by rapid delivery of useful software
 Welcome changing requirements, even late in development
 Working software is delivered frequently (weeks rather than months)
 Working software is the principal measure of progress.
 Sustainable development, able to maintain a constant pace
 Close, daily co-operation between business people and developers
 Face-to-face conversation is the best form of communication (co-
location)
 Projects are built around motivated individuals, who should be trusted
 Continuous attention to technical excellence and good design
 Simplicity
 Self-organizing teams
 Regular adaptation to changing circumstances
Characteristics

 There are many specific agile development methods. Most promote


development, teamwork, collaboration, and process adaptability
throughout the life-cycle of the project.
 Agile methods break tasks into small increments with minimal
planning, and do not directly involve long-term planning. Iterations
are short time frames (time boxes) that typically last from one to four
weeks.
 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 size is typically small (5-9 people) to simplify team comm
Comparison with other methods
 Agile methods lie on the adaptive side of this continuum. Adaptive
methods focus on adapting quickly to changing realities. When the
needs of a project change, an adaptive team changes as well. An
adaptive team cannot report exactly what tasks are being done next
week, but only which features are planned for next month. When
asked about a release six months from now, an adaptive team may
only be able to report the mission statement for the release, or a
statement of expected value vs. cost.
 Predictive methods, in contrast, focus on planning the future in
detail. A predictive team can report exactly what features and tasks
are planned for the entire length of the development process.
Predictive teams have difficulty changing direction. The plan is
typically optimized for the original destination and changing
direction can require completed work to be started over.
Risk analysis

Agile home ground:


Plan-driven home Formal methods:
 Low criticality ground:  Extreme criticality
 Senior developers  High criticality
 Senior developers
 Requirements  Junior developers
 Limited
change often  Requirements do requirements,
 Small number of not change often limited features (
developers  Large number of Wirth's law)
 Culture that developers  Requirements
thrives on chaos  Culture that that can be
demands order modeled.
 Extreme quality.
Agile methods

Well-known agile software development methods include:


Agile Modeling
Agile Unified Process (AUP)
Dynamic Systems Development Method (DSDM)
Essential Unified Process (EssUP)
Extreme Programming (XP)
Feature Driven Development (FDD)
Open Unified Process (OpenUP)
Scrum
Velocity tracking
Extreme Programming

Extreme Programming (XP) makes the need for


method adaptation explicit. One of the fundamental
ideas of XP is that no one process fits every project,
but rather that practices should be tailored to the
needs of individual projects.
Scrum

Scrum is an iterative, incremental framework for project


management often seen in agile software development, a type of
software engineering.
Although the Scrum approach was originally suggested for
managing product development projects, its use has focused on
the management of software development projects, and it can be
used to run software maintenance teams or as a general
project/program management approach.
Measuring agility

While agility can be seen as a means to an end, a number of


approaches have been proposed to quantify agility. Agility Index
Measurements (AIM) score projects against a number of agility
factors to achieve a total. The similarly-named Agility
Measurement Index, scores developments against five
dimensions of a software project (duration, risk, novelty, effort,
and interaction). Other techniques are based on measurable
goals.Another study using fuzzy mathematics has suggested that
project velocity can be used as a metric of agility. There are agile
self assessments to determine whether a team is using agile
practices (Nokia test, Karlskrona test, 42 points test).
While such approaches have been proposed to measure agility,
the practical application of such metrics has yet to be seen.
Experience and reception

 One of the early studies reporting gains in quality, productivity,


and business satisfaction by using Agile methods was a survey
conducted by different organizations as follows..

Organization Year of survey Benefit


Shine Technology Nov 2002-Jan 2003 Yes
Scott Ambler 2006 Yes
IBM Rational’s Method -do- Yes
Group
VersionOne 2008 55%(respondant) 90-
100%(cases)
Others Too young to require
Extensive Academic proof
of their success.
Suitability
 Agile development has been widely documented as working
well for small (<10 developers) co-located teams.
Some things that may negatively impact the success of an agile
project are:
 Large-scale development efforts (>20 developers), through
scaling strategies and evidence of some large projects have been
described.
 Distributed development efforts (non-colocated teams).
Strategies have been described in Bridging the Distance and
Using an Agile Software Process with Offshore Development
 Forcing an agile process on a development team.
 Mission-critical systems where failure is not an option at any
cost (e.g. software for surgical procedures).
Experience reports

As of 2006, experience reports have been or will be


presented at the following conferences:
 XP (2000,2001, 2002, 2003, 2004, 2005, 2006, 2010
(proceedings published by IEEE))
 XP Universe (2001)
 XP/Agile Universe (2002, 2003, 2004)
 Agile Development Conference(2003,2004,2007,2008)
(peer-reviewed; proceedings published by IEEE)
Reference

www.wikipedia.org
www.snip.gob.ni/xdc/Agile/
Software engineering by Rajib mall.
Conclusion

Agile software development stresses rapid


iterations, small and frequent releases, and
evolving requirements facilitated by direct user
involvement process.
Large-scale agile software development remains an
active research area.
ANY QUERY

You might also like