Professional Documents
Culture Documents
3
Principles to achieve agility(The Agile
Manifesto is based on 12 principles)
1. Highest priority -> satisfy the customer
2. Welcome changing requirements
3. Deliver working software frequently
4. Business people and developers must
work together
5. Build projects around motivated
individuals
6. Emphasize face-to-face conversation
4
7. Working software is the primary measure of
progress
6
Agile Software Process
7
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?
8
Human Factor
Key point:
– The Process molds to the needs of the people and team, not
the other way around
A number of 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
Agile Process Models
11
Extreme Programming (XP) - 2
simple design spike solutions
CRC cards prototypes
user stories
values
acceptance test criteria
iteration plan
refactoring
pair programming
Release
unit test
software increment continuous integration
project velocity computed
12
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 13
XP Values
Beck defines a set of five values that establish a
foundation for all work performed as part of XP
Communication (close, informal collaboration
between developers and stakeholders)
Simplicity (developers design for current
needs, not future needs)
Feedback [is derived from three sources: the
implemented software itself(unit tests), the
customer(user stories guide acceptance tests),
and other software team members(iterative
planning)]
Courage (design for today not tomorrow)
Respect (stakeholders ,team members and
indirectly for the software itself)
14
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
15
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.
16
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
17
Industrial XP[“IXP is an organic evolution of XP” ]
XP differs most from the original XP in its greater inclusion of
management, its expanded role for customers, and its upgraded technical
practices.
IXP incorporates six new practices
•Readiness acceptance
Does an appropriate development environment exists to support IXP?
Will the team be populated by stakeholders?
Does the organization have a distinct quality program that support
continuous process improvement?
Will the organizational culture support new values of the agile team?
Will the broader project community be populated appropriately?
•Project community (finding the right people for the project team)
•Project chartering (determining whether or not an appropriate business
justification exists to justify the project)
•Test-driven management (used to establish measurable destinations and
criteria for determining when each is reached)
•Retrospectives (specialized technical review focusing on issues, events,
and lessons-learned across a software increment or entire software release)
•Continuous learning (vital part of continuous process improvement)
18
In addition to the six new practices discussed, IXP modifies a
number of existing XP practices.
XP Issues
•Requirement volatility (can easily lead for scope
creep that causes changes to earlier work design for the
then current needs)
•Conflicting customer needs (many project with many
customers make it hard to assimilate all customer
needs)
•Requirements expressed informally (with only user
stories and acceptance tests, its hard to avoid
omissions and inconsistencies)
•Lack of formal design (complex systems may need a
formal architectural design to ensure a product that
exhibits quality and maintainability)
19
Adaptive Software Development –
a technique for building complex software and systems. The
philosophical underpinnings of ASD focus on human
collaboration & team self organization.
3 phases- 1.speculation
2.collabration
3. learning
DSDM—distinguishing features
22
Nine guiding principles
24
DSDM life cycle activities
Feasibility study (establishes requirements and
constraints)
Business study (establishes functional and information
requirements needed to provide business value, also,
defines the basic application architecture and identifies
the maintainability requirements for the application)
Functional model iteration (produces set of
incremental prototypes to demonstrate functionality to
customer)
Design and build iteration (revisits prototypes to
ensure they provide business value for end users, may
occur concurrently with functional model iteration)
Implementation (latest iteration placed in operational
environment)
25
Scrum
another Agile method. Good for projects that have tight
timelines, changing requirements, and business criticality.
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
Currently seems to have overtaken XP as most popular
26
27
Crystal
Proposed by Cockburn and Highsmith
Crystal—distinguishing features
32
A feature set groups related features into business-
related categories and is defined as:
<action><-ing> a(n) <object>
33
Lean Software Development (LSD)
Adapted principles of Lean manufacturing to the world of
SE.
Lean principles that inspire LSD process are:
Eliminate waste
Build quality in
Create knowledge
Defer commitment
Deliver fast
Respect people
Optimize the whole
34
Agile Modeling
Originally proposed by Scott Ambler
Practice-based methodology for effective modeling and
documentation of software systems in a light-weight manner.
Suggests a set of agile modeling principles
Model with a purpose
Use multiple models
Travel light - as software engineering proceeds, keep
only those models that will provide long term value and
jettison the rest.
Content is more important than representation
Know the models and the tools you use to create them
representation – understand the strengths & weaknesses of
each model & the tools that are used to create it.
Adapt locally – the modeling approach should be
adapted to the needs of the agile team.
35
Agile Unified Process(AUP)