Module 3

 Agile Development

1
 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.” 2
 What is “Agility”?
 Effective (rapid and adaptive) response to change
 Facile communication among all stakeholders
 Emphasizes rapid delivery of operational software
 Adopts the customer as part of the team
 it recognizes that planning in an uncertain world has its
limits and that a project plan must be flexible

Yielding …
 Rapid, incremental delivery of software
3
 Why Agile?
 Agile Methods were developed in an effort to overcome
perceived and actual weaknesses in conventional software
engineering
 In the modern economy, it is often difficult or impossible to
predict how a computer-based system will evolve as time
passes
 Market conditions change rapidly, end-user needs evolve,
and new competitive threats emerge without warning
 In many situations, you won’t be able to define
requirements fully before the project begins
 You must be agile enough to respond to a fluid business
environment 4
Agility and the Cost of Change

5
Agility Principles – (1/3)
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 adapt 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.
6
Agility Principles – (2/3)
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 effective, then tunes and adjusts 7
Agility Principles – (3/3)
 Not every agile process model applies these 12
principles with equal weight, and some models
choose to ignore (or at least downplay) the
importance of one or more of the principles

 However, the principles define an agile spirit

that is maintained in each of the process
models

8
The Politics of Agile Development: – a
debate
 There is considerable debate about the benefits and
applicability of agile software development as opposed to
more conventional software engineering processes.
 No one is against agility. The real questions are:
 What is the best way to achieve it?
 how do we build quality software that meets customers’
needs?
 How software scaled to meet customer’s needs
 There are no absolute answers to either of these questions.
Even within the agile school itself, there are many proposed
process models each with a subtly different approach to the
agility problem 9
 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. (innate talent, SW skills, Knowledge about
processes)
 Common focus: (different tasks, different skills but same
common interest)
 Collaboration: (frequent collaboration of stakeholders)
 Decision-making ability: ( )
 Fuzzy problem-solving ability: (learn lessons from
problem solving)
 Mutual trust and respect. (respect for integrity)
 Self-organization.(self-defined, targets, schedule, Process)
Extreme
11
Programming (XP)
Model
 The most widely used approach to agile software
development
 XP uses an object-oriented approach as its
preferred development paradigm
 XP encompasses a set of rules and practices that
occur within the context of four framework
activities:
 planning,
 design,
 coding,
 testing.
 Extreme
12 Programming (XP)
Model
XP Planning
 Begins with listening (Requirements gathering,
understanding business context for the SW, a picture of
features and functionalities)
 Listening leads to the creation of “user stories” (again
focus is output, features and functionalities, story is
similar to use-cases, written by the customer)
 Customer assigns a value to the story.
 Agile team assesses each story and assigns a cost
 Stories are grouped to for a deliverable increment
Extreme
13
Programming (XP) Model

 A commitment is made on delivery date

 the XP team orders the stories that will be developed in one
of three ways:
• Development of all stories immediately

• Development of high priority stories at first

• Development of risky stories at first

 After the first increment “project velocity” is used to help
define subsequent delivery dates for other increments
Extreme Programming (XP) Model
 XP Design
 Follows the KIS (Keep It Simple) principle
 Encourage the use of CRC (Class-Responsibility-Collaborator) cards
(see Chapter 8)
 For difficult design problems, suggests the creation of “spike
solutions”—a design prototype
 Encourages “refactoring”—an iterative refinement of the internal
 program design
 XP Coding
 Recommends the construction of a unit test for a story before
 coding commences
 Encourages “pair programming” to code for a story
 One person codes, the other checks the coding standards used, test
whether the code follows the story being implemented, fulfills the
unit tests
 XP Testing
 All unit tests are executed daily (whenever code is modified)
 “Acceptance

1
6
Extreme Programming
(XP) Model
spike solut
simple
ions
prot ot
design
ypes
user st ories CRC cards
values
accept ance t est crit
eria
it erat ion plan

ref act oring

pair
programmi
ng

Release
sof t ware increment
unit t est
project velocit y comput cont inuous int
ed egrat ion

1
7
16
Agile Process Models
 The most widely used of all agile process models
is Extreme Programming (XP). But many other
agile process models have been proposed and
are in use across the industry. Among the most
common are:
 17
Adaptive Software Development
 Originally proposed by Jim Highsmith
 ASD — distinguishing features
 Mission-driven planning
 Component-based focus
 Uses “time-boxing” (See Chapter 24)
 Explicit consideration of risks
 Emphasizes collaboration for requirements gathering
 Emphasizes “learning” throughout the process
 18

Adaptive Software Development

adapt ive cycle
planning uses Requirement s gat
mission st at ement
hering
project const raint s JAD
basic requirement s mini-specs
t ime-boxed
release plan

Releas
e
sof t ware increment adjust ment s f or component s implement ed/ t est
subsequent cycles ed
f ocus groups f or f eedback f
ormal t echnical reviews
post mort ems
 Scrum
 Originally proposed by Schwaber and Beedle
 Scrum principles are consistent with the agile
manifesto and are used to guide development
activities within a process that incorporates the
following framework activities:
 requirements, analysis, design, evolution, and
delivery.

1
8
 Scrum
 Scrum—distinguishing features
 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
 Development work is partitioned into “packets”
 Testing and documentation are on-going as the
product is constructed

1
9
Scrum

2
0
Dynamic
22 Systems Development Method

 Promoted by the DSDM Consortium (www.dsdm.org)

 DSDM—distinguishing features
 Similar in most respects to XP and/or ASD
 Nine 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.
23 Dynamic Systems
Development Method

DSDM Life Cycle (with permission of the DSDM consortium)

24

Cryst
al  Proposed by Cockburn and Highsmith
 Crystal—distinguishing features
 Actually a family of process models that
allow
“maneuverability” based on problem
characteristics
 Face-to-face communication is emphasized
 Suggests the use of “reflection
workshops” to review the work habits
of the team
25

Feature Driven Development

 Originally proposed by Peter Coad et
al
 FDD—distinguishing features
 Emphasis is on defining “features”
• a feature “is a client-valued
function that can be implemented in two
weeks or less.”
 Uses a feature template
• <action> the <result> <by | for | of | to> a(n)
<object>
 A features list is created and “plan by
feature” is conducted
 Design and construction merge in FDD
26

Feature Driven Development

27

Agile Modeling
 Originally proposed by Scott Ambler
 Suggests a set of agile modeling
principles
 Model with a purpose
 Use multiple models
 Travel light
 Content is more important than representation
 Know the models and the tools you use to
create them
 Adapt locally