2. The Manifesto for
Agile Software Development
These slides are designed to accompany Software Engineering: A Practitioner’s Approach,
7/ e (McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 2
“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
3. What is “Agility”?
These slides are designed to accompany Software Engineering: A Practitioner’s Approach,
7/ e (McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 3
■
■
■
■ Effective (rapid and adaptive) response
to change
Effective communnication among all
stakseholders Drawing the cunstomer onto the
team Organizing a team so that it is in
control of the
works performed
Yielding …
■ Rapid, incremental delivery of
software
4. Agility and the Cost of Change
These slides are designed to accompany Software Engineering: A Practitioner’s Approach,
7/ e (McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 4
5. An Agile Process
These slides are designed to accompany Software Engineering: A Practitioner’s Approach,
7/ e (McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 5
■
■
■
■
■ Is driven by cunstomer descriptions of
what is requnired (scenarios)
Recognizes that plans are short-lived
Develops software iteratively with a
heavy emphasis on construnction
activities
Delivers munltiple ‘software
increments’ Adapts as changes
occunr
6. Agility Principles - I
These slides are designed to accompany Software Engineering: A Practitioner’s Approach,
7/ e (McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 6
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 efcient and efective method of conveying information
to and within a development team is face–to–face conversation.
7. Agility Principles - I I
These slides are designed to accompany Software Engineering: A Practitioner’s Approach,
7/ e (McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 7
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 – the art of maximizing the amount of
work not done – is essential.
11. The best architectures, requirements, and
designs emerge from self–organizing teams.
12. At regular intervals, the team reflects on how to
become more efective, then tunes and adjusts its
behavior accordingly.
8. Hunman Factors
These slides are designed to accompany Software Engineering: A Practitioner’s Approach,
7/ e (McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 8
■
■ the process molds to the needs ofthe people and
team, not the other way around
key traits must exist among the people on an
agile team and the team itself:
■
■
■
■
■
■
■ Competence.
Common focus.
Collaboration.
Decision-making ability.
Fuzzy problem-solving ability.
Mutual trust and respect.
Self-organization.
9. Extreme Programming (XP)
These slides are designed to accompany Software Engineering: A Practitioner’s Approach,
7/ e (McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 9
■
■ The most widely unsed agile process,
originally proposed by Kent Becks
XP Planning
■
■
■
■
■ Begins with the creation of “unser stories”
Agile team assesses each story and assigns a
cost Stories are grounped to for a deliverable
increment
A commitment is made on delivery date
After the first increment “project velocity” is
unsed to help define sunbsequnent delivery dates
for other increments
10. Extreme Programming (XP)
These slides are designed to accompany Software Engineering: A Practitioner’s Approach,
7/ e (McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 10
■ XP Design
■
■
■
■ Follows the KI S principle
Encounrage the unse of CRC cards (see Chapter 8)
For difcunlt design problems, sunggests the creation of
“spikse soluntions”—a design prototype
Encounrages “refactoring”—an iterative refinement of the
internal
program
design
■
■
XP Coding
■ Recommends the construnction of a unnit test for a store
before
coding commences
■Encounrages “pair
programming” XP Testing
■ All unnit tests are execunted daily
■ “Acceptance tests” are defined by the cunstomer and
excunted to assess cunstomer visible funnctionality
11. Extreme Programming (XP)
unit test
continuous
integration
These slides are designed to accompany Software Engineering: A Practitioner’s Approach,
7/ e (McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 11
acceptance
testing
user stories
values
acceptance test
criteria
iteration plan
simple
design
CRC cards
spike
solutions
prototypes
refactoring
pair
programming
Release
softwareincremen
t
project
velocitycomput
ed
12. Adaptive Software Development
These slides are designed to accompany Software Engineering: A Practitioner’s Approach,
7/ e (McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 12
■ Originally proposed by Jim
Highsmith
■ ASD — distingunishing featunres
■
■
■
■
■
■ Mission-driven
planning Component-
based focuns
Uses “time-boxing” (See Chapter
24) Explicit consideration of riskss
Emphasizes collaboration for requnirements
gathering Emphasizes “learning” throunghount the
process
13. Adaptive Software Development
adaptive cycle
planning uses mission
statement project
constraints
basic requirements
time-boxed release
plan
Requirements gathering
J AD
mini-specs
components implemented/
tested focus groups for
feedback formal technical
reviews
postmortems
softwareincrement
adjustmentsfor subsequent
cycles
Release
These slides are designed to accompany Software Engineering: A Practitioner’s Approach,
7/ e (McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 13
14. Dynamic Systems Development
Method
These slides are designed to accompany Software Engineering: A Practitioner’s Approach,
7/ e (McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 14
■
■ Promoted by the DSDM Consortiunm (
www.dsdm.org) DSDM—distingunishing featunres
■
■
Similar in most respects to XP and/or
ASD Nine guniding principles
• Active unser involvement is imperative.
• DSDM teams m
u
n
s
t be empowered to makse decisions.
• The focuns is on frequnent delivery of produncts.
• Fitness for bunsiness punrpose is the essential criterion for acceptance of
deliverables.
• I terative and incremental development is necessary to converge on an accunrate
bunsiness soluntion.
• All changes dunring development are reversible.
• Requnirements are baselined at a high level
• Testing is integrated throunghount the life-cycle.
15. Dynamic Systems Development
Method
DSDM Life Cycle (with permission of the DSDM consortium)
These slides are designed to accompany Software Engineering: A Practitioner’s Approach,
7/ e (McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 15
16. Scrunm
These slides are designed to accompany Software Engineering: A Practitioner’s Approach,
7/ e (McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 16
■ Originally proposed by Schwaber and
Beedle
■ Scrunm—distingunishing featunres
■ Development works is partitioned into “packsets”
■ Testing and docunmentation are on-going as
the produnct is construncted
■ Works occunrs in “sprints” and is derived
from a “backslog” of existing
requnirements
■ Meetings are very short and sometimes
conduncted withount chairs
■ “demos” are delivered to the cunstomer with the
time- box allocated
18. Crysta
l
These slides are designed to accompany Software Engineering: A Practitioner’s Approach,
7/ e (McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 18
■
■
Proposed by Cocksbunrn and
Highsmith Crystal—distingunishing
featunres
■
■
■ Actunally a family of process models that allow
“maneunverability” based on problem
characteristics
Face-to-face communnication is emphasized
Sunggests the unse of “reflection
worksshops” to review the works habits of
the team
19. Featunre Driven Development
These slides are designed to accompany Software Engineering: A Practitioner’s Approach,
7/ e (McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 19
■
■
Originally proposed by Peter Coad et
al FDD—distingunishing featunres
■ Emphasis is on defining
“featunres”
• a feature “is a client-valuned funnction that can be
implemented in two weekss or less.”
■ Uses a featunre
template
• <action> the <resunlt> <by | for | of | to> a(n) <object>
■
■
A featunres list is created and “plan by
featunre” is conduncted
Design and construnction merge in FDD
20. Featunre Driven Development
Reprinted with permission of Peter Coad
These slides are designed to accompany Software Engineering: A Practitioner’s Approach,
7/ e (McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 20
21. Agile Modeling
These slides are designed to accompany Software Engineering: A Practitioner’s Approach,
7/ e (McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 21
■
■
Originally proposed by Scott Ambler
Sunggests a set of agile modeling
principles
■
■
■
■
■
■ Model with a
punrpose Use
munltiple models
Travel light
Content is more
important than
representation
Know the models and the tools youn unse to create
them Adapt locally
