SE CHAP 3 Agility

Agile Development
The Manifesto for

Agile Software Development
“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
That is, while there is value in the items on the
right, we value the items on the left more.”
Kent Beck et al
What is “Agility”?
 Effective (rapid and adaptive) response to
change
 Effective communication among all stakeholders
 Drawing the customer onto the team
 Organizing a team so that it is in control of the
work performed
Yielding …
 Rapid, incremental delivery of software
Agility
 An agile team is able to respond to changes
during project development
 Agile development recognizes that project
plans must be flexible
 Agility encourages team structures and
attitudes that make communication among
developers and customers more facile (easily
done)
 Eliminates the separation between customers
and developers
Agility
 Agility emphasizes the importance of rapid delivery of
operational software and de-emphasizes importance of
intermediate work products
 Agility can be applied to any software process as long as
the project team is allowed to streamline tasks and
conduct planning in way that eliminate non-essential
work products
 The costs of change increase rapidly as a project
proceeds to completion, the earlier a change is made
the less costly it will be
 Agile processes may flatten the cost of change curve by
allowing a project team to make changes late in the
project at much lower costs
Agility and the Cost of Change
An Agile Process
 Is driven by customer descriptions of what is
required (scenarios)
 Recognizes that plans are short-lived
 Develops software iteratively with a heavy
emphasis on construction activities
 Delivers multiple ‘software increments’
 Adapts as
changes
occur
An Agile Process
 Are based on three key assumptions
1. It is difficult to predict in advance which requirements or
customer priorities will change and which will not
2. For many types of software design and construction
activities are interleaved (construction is used to prove
the design)
3. Analysis, design, and testing are not as predictable (from
a planning perspective) as one might like them to be
 Agile processes must adapt incrementally to manage
unpredictability
 Incremental adaptation requires customer feedback based
on evaluation of delivered software increments (executable
prototypes) over short time periods
Agility Principles
1. Our highest priority is to satisfy the customer through
early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in
development. Agile processes harness change for the
customer's competitive advantage.
3. Deliver working software frequently, from a couple of
weeks to a couple of months, with a preference to the
shorter timescale.
4. Business people and developers must work together
daily throughout the project.
5. Build projects around motivated individuals. Give them
the environment and support they need, and trust them
to get the job done.
6. The most efficient and effective method of conveying
information to and within a development team is face–
to–face conversation.
Agility Principles
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The
sponsors, developers, and users should be able to
maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good
design enhances agility.
10. Simplicity
11. The best architectures, requirements, and designs
emerge from self–organizing teams.
12. At regular intervals, the team reflects on how to become
more effective, then tunes and adjusts its behavior
accordingly.
The Politics of Agile Development
 There is considerable debate about the
benefits and applicability of agile software
development
 No one is against agility. The real question is:
 What is the best way to achieve it?
Human Factors
 The process molds to the needs of the people and
team, not the other way around
 key traits must exist among the people on an
agile team and the team itself:
 Competence (proficiency)
 Common focus
 Collaboration
 Decision-making ability
 Fuzzy problem-solving ability
 Mutual trust and respect
 Self-organization
Extreme Programming (XP)
 The most widely used agile process, originally proposed by
Kent Beck
 XP uses an object-oriented approach as its preferred
development paradigm
 XP Values
 Communication
 Simplicity
 Feedback
 Courage
 Respect
 Defines four (4) framework activities
 Planning
 Design
 Coding
 Testing
Extreme Programming (XP)
simple design spike solutions
CRC cards prototypes
user stories
values
acceptance test
criteria
iteration plan
refactoring
pair
programming
Release
unit test
software
software increment
increment continuous integration
project
project velocity
velocity computed
computed
acceptance testing
XP - Planning
 Begins with the creation of a set of stories (also
called user stories)
 Each story is written by the customer and is placed
on an index card
 The customer assigns a value (i.e. a priority) to the
story
 Agile team assesses each story and assigns a cost
 Stories are grouped to for a deliverable increment
 A commitment is made on delivery date
 After the first increment “project velocity” is used to
help define subsequent delivery dates for other
increments
XP - Design
 Follows the KIS (keep it simple) principle
 Encourage the use of CRC (class-
responsibility-collaborator) cards
 For difficult design problems, suggests the
creation of “spike solutions”—a design
prototype
 Encourages “refactoring”—an iterative
refinement of the internal program design
 Design occurs both before and after coding
commences
XP - Coding
 Recommends the construction of a series
of unit tests for each of the stories before
coding commences
 Encourages “pair programming”
 Mechanism for real-time problem solving and
real-time quality assurance
 Keeps the developers focused on the problem
at hand
 Needs continuous integration with other
portions (stories) of the s/w, which
provides a “smoke testing” environment
XP - Testing
 Unit tests should be implemented using a
framework to make testing automated.
This encourages a regression testing
strategy.
 Integration and validation testing can occur
on a daily basis
 Acceptance tests, also called customer
tests, are specified by the customer and
executed to assess customer visible
functionality
 Acceptance tests are derived from user
stories
Adaptive Software Development
 Originally proposed by Jim Highsmith
 Self-organization arises when independent
agents cooperate to create a solution to a
problem that is beyond the capability of any
individual agent
 Emphasizes self-organizing teams, interpersonal
collaboration, and both individual and team
learning
Phases
 Speculation (project initiated and adaptive
cycle planning takes place)
 Collaboration (requires teamwork from a jelled
team, joint application development is preferred
requirements gathering approach)
 Learning (components implemented and
tested, focus groups provide feedback, formal
technical reviews, postmortems)
Adaptive Software Development
Scrum
 Originally proposed by Schwaber and Beedle
 Scrum—distinguishing features
 Development work is partitioned into “packets”
 Testing and documentation are on-going as the
product is constructed
 Work occurs in “sprints” and is derived from a
“backlog” of existing requirements
 Meetings are very short and sometimes conducted
without chairs
 “Demos” are delivered to the customer with the time-
box allocated
 Roles
• Product Owner
• Scrum Master
• Scrum team
Scrum principles
 Small working team used to maximize communication,
minimize overhead, and maximize sharing of informal
knowledge
 Process must be adaptable to both technical and business
challenges to ensure best product produced
 Process yields frequent increments that can be inspected,
adjusted, tested, documented and built on
 Development work and people performing it are
partitioned into clean, low coupling partitions
 Testing and documentation is performed as the product is
built
 Provides the ability to declare the product done whenever
required
Scrum
Dynamic Systems Development
Method
 Promoted by the DSDM Consortium (www.dsdm.org)
 DSDM—distinguishing features
 Similar in most respects to XP and/or ASD
 Guiding principles
• Active user involvement is imperative.
• DSDM teams must be empowered to make
decisions.
• The focus is on frequent delivery of products.
• Fitness for business purpose is the essential
criterion for acceptance of deliverables.
• Iterative and incremental development is necessary
to converge on an accurate business solution.
• All changes during development are reversible.
• Requirements are baselined at a high level
• Testing is integrated throughout the life-cycle.
Dynamic Systems Development
Method
Agile Idea
 Frequent idea: Fix time, not features
Functionality Time Resources

FIXED
Agile
Prescriptive
Time Resources VARIABLE Functionality

Criticisms
 Lack of structure and necessary documentation
 Only works with senior-level developers
 Incorporates insufficient software design
 Requires meetings at frequent intervals at enormous
expense to customers
 Requires too much cultural change to adopt
 Can lead to more difficult contractual negotiations
 Can be very inefficient— maybe code things multiple
times as they change if the requirements for one area of
code change through various iterations, the same
programming may need to be done several times over.
Whereas if a plan were there to be followed, a single
area of code is expected to be written once.
Criticisms
 Hard to develop realistic estimates of work
effort because at the beginning of the project
no one knows the entire scope/requirements
 Agile is feature driven, non-functional quality
attributes are hard to be placed as user stories
 Can increase the risk of scope creep due to
lack of detailed requirements
Thank you

SE CHAP 3 Agility

Uploaded by

Copyright:

Available Formats

SE CHAP 3 Agility

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SE CHAP 3 Agility

Uploaded by

Copyright:

Available Formats

Agile Development

The Manifesto for

Functionality Time Resources

Time Resources VARIABLE Functionality

You might also like