Agile Process & Extreme Programming-1

CS231: Software Engineering

Kardi Teknomo, PhD

Note: Most of these materials are borrowed from many sources as specified in the
references
 Kardi Teknomo, PhD

Agenda
„ Agile Process
„ XP Process
„ Four XP Values
„ XP Practices
„ XP Evaluation
 Kardi Teknomo, PhD

Agenda
„ Agile Process
„ XP Process
„ Four XP Values
„ XP Practices
„ XP Evaluation
 Kardi Teknomo, PhD

What Do We Mean By “Agile?”

„ According to the Merriam-Webster on-line
dictionary “agile” means:
„ “1: marked by ready ability to move with
quick easy grace;”
„ “2: having a quick resourceful and adaptable
character.”
„ In agile software development, “agile”
tends to mean “the ability to respond to
change.”
 Kardi Teknomo, PhD

Agile Alliance
„ 2001 – representatives from agile processes meet in
Snowbird, Utah
„ Recognize a need for an alternative to documentation-
driven, heavyweight software development processes
which doesn’t work for ALL projects
„ Agreed on a “manifesto” of values and principles
„ Individuals and interactions over processes and tools
„ Working software over comprehensive documentation
„ Customer collaboration over contract negotiation
„ Responding to change over following a plan
„ Similar to merging of Booch, Rumbauch, Jacobson,
OMT, and others into UML?
 Kardi Teknomo, PhD

Agile Methodologies - Examples

„ SCRUM
„ Dynamic Systems Development Method (DSDM)
„ Popular in UK; 9 practices similar to XP; being adopted by UK
government
„ Crystal Family & Adaptive Software Development
(merged in 2001)
„ Feature-Driven Development (FDD – Coad)
„ Pragmatic Programming
„ dX (agile form of RUP)
„ Extreme Programming (XP)
 Kardi Teknomo, PhD

Agile Methodologies ask…

„ If design is good, why not make it everyone’s job?

„ If simplicity is good, why not use the simplest design that supports
the currently desired functionality?

„ If architecture is good, why not have everyone work at defining

and refining the architecture continuously?

„ If short iterations are good, why not make iterations really short
(hours and days) instead of weeks and months?

„ If requirements, design, and code reviews are good, why not do it

all the time?

„ If testing is good, why not do it all the time… even customers?

„ If integration testing is good, why not do it several times a day?

 Kardi Teknomo, PhD

Agile Methodologies
„ Seek to address these questions and the
“realities” of software development

„ Maintain a repeatable, quality-driven process

„ Properties of an Agile Methodology:

„ Iterative development
„ Short iterations (2-6 weeks)
„ Working versions at conclusion of each iteration
„ Fully integrated and tested
„ Adaptable: can evolve with each iteration
„ People-centric: developers & management equal
 Kardi Teknomo, PhD

Agile Assumptions
„ The design shall be simple and the code quality
must be high
„ The customer can change their mind, substitute
functionality, and change priorities
„ Delivering the most value to the business,
efficient use of resources, maximize ROI and
time-to-ROI
 Kardi Teknomo, PhD

Economics of software development

cost of change

Requirements Analysis Design Implementation Testing Production

 Kardi Teknomo, PhD

What if…
cost of change

Time
 Kardi Teknomo, PhD

Key Assumption of Agile Process

„ The cost of change curve can be
flattened
„ How?
„ Better program organization (object-oriented)
„ Simple designs kept simple with refactoring
„ Automated testing to maintain integrity
„ Better tools and faster machines
„ Because of this we can:
„ Make decisions later, defer costs, keep options open
„ Reduce the time-to-ROI with partial solutions
„ Learn from feedback, adapt to change
 Kardi Teknomo, PhD

Agenda
„ Agile Process
„ XP Process
„ Four XP Values
„ XP Practices
„ XP Evaluation
 Kardi Teknomo, PhD

What is XP?
„ Who is behind XP?
„ Kent Beck, Ward Cunningham, Ron Jeffries
„ Short definition
„ lightweight process model for OO software development
„ What’s in the name?
„ code is in the centre of the process
„ practices are applied extremely
„ What is new in XP?
„ none of the ideas or practices in XP are new
„ the combination of practices and their extreme application is
new
„ XP is not intended to be a complete framework

14
 Kardi Teknomo, PhD

What Is Extreme Programming?

„ A system of practices that a community of
software developers is evolving to address the
problems of quickly delivering quality software,
and then evolving it to meet changing business
needs.
„ Extreme programming is a software
methodology, which has a set of simple
practices to be followed
„ Overall, the methodology emphasizes team
work, customer participation and concentration
in the essential.
„ XP is a specific instantiation of an agile process
 Kardi Teknomo, PhD

Emergence
„ XP provides values and principles to guide team
behavior
„ Team expected to self-organize
„ XP provides specific core practices
„ Each practice is simple and self-complete
„ Combination of practices produces more
complex emergent behavior
„ Synergy of practices still not fully understood
 Kardi Teknomo, PhD

Why Is It Called “Extreme?”

„ Selected the minimal set of effective practices
„ “Turned the knob up to 10” on each practice
„ Very short cycles (planning game)
„ Continuous code reviews (pair programming)
„ Extensive testing (unit testing, acceptance testing)
„ Continuous integration
„ Constant design improvement (refactoring)
„ Continuous architecture refinement (metaphor)
„ Etc…
 Kardi Teknomo, PhD

Growing a System
„ Have a running system from day 1.
„ Integrate stories one by one
„ Work with small releases, iterations,
tasks, episodes:
„ Each iteration approx. 3 weeks
„ Split (combine) stories into tasks, estimate
„ Design, test, build, test
„ Measure progress, learn to estimate

18
 Kardi Teknomo, PhD

XP Process Cycle
„ XP is iterative and incremental
„ XP is driven by time-boxed cycles
„ The rhythm (below) of the XP process is
crucial
Product

Releases

Iterations

Tasks

Episodes
 Kardi Teknomo, PhD

Forward-Driving Activities
„ Each level of activity provides the minimal
materials needed for the next level
„ Product activities provide materials for release cycles
– requirements and priorities
„ Release planning sessions provide materials for
iteration cycles – prioritized & sized stories
„ Iteration planning sessions provide materials for task
cycles – task breakdowns
„ Task development provides materials for
development episodes
„ Development episodes produce product
 Kardi Teknomo, PhD

Product
„ Involves chartering, strategy planning, feature
set definition and planning, investment and
resource commitments…
„ Tends to be organizationally context dependent
„ XP does not provide specific practices for this
„ XP assumes the Customer does these things
„ Primary deliverable: stories
 Kardi Teknomo, PhD

Releases
„ Whole team gathers
„ Review prior progress
„ Customer presents stories
„ Stories are discussed (analysis)
„ Developer determines technical approach & risk
(architecture & design)
„ Developer provides first-level estimates & options
„ Customer prioritizes stories
„ Customer chooses target release time box
„ Stories arranged into probable iterations
„ Begin the next iteration
„ Primary deliverable: release plan
„ Releases are typically from 1 to 6 months
 Kardi Teknomo, PhD

Planning a Release
„ Release: every 2 - 6 months
„ Fix date, cost and quality
„ Determine scope: how many stories can be
done following development estimates
„ Most important user stories first
„ Feedback / adjustment at every iteration
„ New / modified stories
„ Changed estimates

23
 Kardi Teknomo, PhD

Iteration
„ Each iteration is 1-3 weeks long.
„ For each iteration, the customer chooses the user
stories to be implemented.
„ Rule: Choose more valuable first. (This way, you will
focus on the most important parts.)
„ Also, choose which user stories to fix, if there are some
that did not pass their acceptance tests.
„ Choose such an amount of user stories that based on
the velocity estimates, they will be completed within
the iteration.
„ Preliminary deliverable: iteration plan
„ Begin the development of the tasks
„ Final deliverable: a deployable system
 Kardi Teknomo, PhD

Tasks
„ Developer signs up for a task
„ Developer begins episodes to implement
„ Developer ensures task is complete
„ If last task, Developer ensures story is
complete via acceptance tests
 Kardi Teknomo, PhD

Task planning
„ Programming tasks are identified from the user
stories and failed tests.
„ The tasks are written down on index cards.
Duplicates are removed.
„ Developers choose tasks and estimate their
duration (1-3 ideal days ie. days without
interruption – shorter ones can be grouped and
longer ones devided).
„ After this, it is possible to evaluate how full the
iteration is.
 Kardi Teknomo, PhD

Episodes
„ = daily development work
„ Developer obtains a pair partner
„ Pair verifies understanding of story for this task
(analysis)
„ Pair determines detailed implementation approach
(detailed design)
„ Pair begins test-driven cycle of write test, implement to
pass, refactor
„ At appropriate intervals, pair integrates to code base
„ Pair retrospects on progress frequently
„ Pair continues until pair changes or task complete
 Kardi Teknomo, PhD

Feedback
„ Pairs are constantly communicating within themselves
and outward to team
„ Daily “stand-up” meetings provide overall team status,
re-synchronization, and micro-planning
„ Retrospectives provide overall status and points for
process adjustment and improvement
„ Development cycles may cause rethinking of tasks
„ Task development may cause rethinking of stories
„ Story re-estimation may cause iteration changes or
recovery
„ Iteration results may cause changes to release plan
 Kardi Teknomo, PhD

Agenda
„ Agile Process
„ XP Process
„ Four XP Values
„ XP Practices
„ XP Evaluation
 Kardi Teknomo, PhD

Values and Practices

Developers XP practices
planning
planning game
game
short
short releases
releases
XP values metaphor
metaphor
communication simple
simple design
design
communication test-first
test-first coding
coding
simplicity
simplicity refactoring
refactoring
feedback
feedback pair
pair programming
programming
courage
courage code
code co-ownership
co-ownership
continouos
continouos integration
integration
no
no overtime
overtime
Customer on-site
on-site customer
customer
coding
coding standard J.Nawrocki et al.,
standard CMM Level 2 & XP
 Kardi Teknomo, PhD

XP > 4 Values
„ Simplicity
„ Do the simplest thing that works for the current business need
„ Communication
„ Select practices that encourage talking & listening (better
communication)
„ At all levels: unit testing, pair programming, estimation
„ Feedback …at all levels and timescales
„ The system tests will tell you; Listen to the code!
„ Minutes, days, weeks: unit tests, functional tests, early production
„ Scope: as soon as customer writes a user story, a developer estimates
„ Courage
„ To rework design and code when needed
„ To throw away code when no longer needed
„ Go at top speed
 Kardi Teknomo, PhD

Agenda
„ Agile Process
„ XP Process
„ Four XP Values
„ XP Practices
„ XP Evaluation
 Kardi Teknomo, PhD

The Original 12 Core Practices

1. On-Site Customer
2. The Planning Game
3. Small Releases
4. Testing
5. Simple Design
6. Pair Programming
7. Refactoring
8. Continuous Integration
9. Collective Ownership
10. Coding Standards
11. Metaphor
12. 40-Hour Week
 Kardi Teknomo, PhD

XP > 12 Practices > Synergy

„ XP says: practices will fail individually but
will work synergistically

Tools Available

Simulations Available
 Kardi Teknomo, PhD

Evolving Core Practices

„ On-Site Customer
„ Whole Team

„ The Planning Game

„ Release Planning

„ Iteration Planning

„ Testing
„ Acceptance Testing

„ Unit Testing

„ Test-Driven Development

„ Refactoring
„ Design Improvement

„ 40-Hour Week
„ Sustainable Pace

Rules and Practices
Planning
User stories; Release planning;
small releases; Business Analysis;
Project Velocity; Iterations;
Iteration planning; Move people
around; Stand-up meeting day; Fix
XP when it breaks.
Design
Simplicity; System metaphor.
Use CRC cards for design
sessions.
Spike solutions to reduce risk.
No functionality added early.
Refactor.
Kardi Teknomo, PhD
Coding
Customer is always available;
Standards.
Code the unit test first; Pair
programmed; Integrates often;
Collective code ownership.
Optimization till last; No overtime.
Testing
All code must have and pass unit
tests before it
can be released; When a bug is
found tests are created; Acceptance
tests are run often and the score is
published.
 Kardi Teknomo, PhD

The Original 12 Core Practices

1. On-Site Customer
2. The Planning Game
3. Small Releases
4. Testing
5. Simple Design
6. Pair Programming
7. Refactoring
8. Continuous Integration
9. Collective Ownership
10. Coding Standards
11. Metaphor
12. 40-Hour Week
 Kardi Teknomo, PhD

Daily Standup Meeting

„ Goal: Identify items to be accomplished

for the day and raise issues
• Everyone attends,
including the customer
• Not a discussion forum
• Everyone gets to speak
• 15 minutes

38
 Kardi Teknomo, PhD

Whole Team (On-Site Customer)

„ small teams (up to 10-15 programmers)
„ common workplace and working hours
„ Development is an ongoing conversation across the
whole team
„ Face-to-face communication is the most efficient
„ Team members available to others with minimal effort,
waiting, and disruption
„ developer and client must commit 100% to XP
practices
 Kardi Teknomo, PhD

On-site customer
„ User stories (see: Planning Game) are
not detailed, so there are always
questions to ask the customer
„ The customer must always be available
„ to resolve ambiguities
„ set priorities
„ provide test cases
„ Customer is considered part of the team

40
 Kardi Teknomo, PhD

The Original 12 Core Practices

1. On-Site Customer
2. The Planning Game
3. Small Releases
4. Testing
5. Simple Design
6. Pair Programming
7. Refactoring
8. Continuous Integration
9. Collective Ownership
10. Coding Standards
11. Metaphor
12. 40-Hour Week
 Kardi Teknomo, PhD

Planning Game
„ Customer and developers cooperate to produce the maximum
business value as rapidly as possible.
„ Customer comes up with a list of desired features for the system.
„ Each feature is written out as a User Story, giving each feature
a name and describes in broad strokes what is required. User
stories are typically written in 2-3 sentences on 4x6 story cards.
„ Developers estimate how much effort each story will take, and
how much effort the team can produce in a given time interval
(iteration).
„ Project velocity = how many days can be committed to project
per week.
„ Customer decides which stories to implement in what order, and
when and how often to produce a production releases of the
system.
 Kardi Teknomo, PhD

Planning Game
•Customer and developers cooperate to produce the maximum
business value as rapidly as possible
•How to plan?
– Create and prioritize user stories - customer
– Estimate difficulties - developers
– Select stories for next release - customer
– Split stories into tasks - developers
– Plan the tasks for the next iteration -
customer/developers
 Kardi Teknomo, PhD

Planning Game
„ Pieces: user stories
„ Players: customer & developer
„ Moves:
„ User story writing
„ requirements are written by the customer on
small index cards
„ user stories are written in business language
„ and describe things that the system needs to do
„ each user story is assigned a business value
„ for a few months projects there may be 50-100
user stories
 Kardi Teknomo, PhD

Planning Game (Contd)

„ Moves:
„ Story estimation
„ each user story is assigned a cost by the
developer
„ cost is measured on ideal weeks (1-3 weeks)
„ a story is split by the customer if it takes longer
than 3 weeks to implement
„ Commitment
„ customer and developer decide which user stories
constitute the next release

45
 Kardi Teknomo, PhD

Planning Game (Contd)

„ Moves:
„ Value and Risk first
„ Put the most valuable functionality into

production as quickly as possible

„ Developer sorts the user stories of the

next release so that

„ more valuable or riskier stories are moved
earlier in the schedule (minimal initial
investment)
„ a fully working (sketchy) system is completed
(in a couple of weeks)
46
 Kardi Teknomo, PhD

What are User Stories?

„ A user story is a short description of what
the business or customer wants the
software to do, written by the customer
in the customer terminology without
techno-syntax.
„ Short, just a few sentences.

They are in the format of about

three sentences typically written
on 4”x6” cards.
 Kardi Teknomo, PhD

Purpose
„ The basic goal is to create a release plan
„ Used as a basis for implementation.
„ Used as a basis for release planning.
„ Used as a basis for testing.
„ Used as a basis for velocity estimation (1-3 weeks per
user story)
„ They are also used instead of a large requirements
document.
„ User Stories also drive the creation of the acceptance
tests.
 Kardi Teknomo, PhD

User Stories
„ Collect requirements as user stories
„ Possible to explain, test, and estimate
„ Prioritize stories in order of business
importance
„ Development:
„ Estimate effort for stories
„ Highlight technical risks / consequences

49
 Kardi Teknomo, PhD

Example Simple Project

 Kardi Teknomo, PhD

User Story Example-1

 Kardi Teknomo, PhD

User Story Example-2

 Kardi Teknomo, PhD

User Story Example-3

 Kardi Teknomo, PhD

Prioritizing Stories
 Kardi Teknomo, PhD

Task Example-1
 Kardi Teknomo, PhD

Task Example-2
 Kardi Teknomo, PhD

Sign Up Example
 Kardi Teknomo, PhD

Tracking Information
Kardi Teknomo, PhD
 Kardi Teknomo, PhD

Ideal Programming week

„ The amount of work you can complete in
a week during which the phone does not
ring, there are no meetings, you dont
have to work with anyne else, nobody
bugs you, you aren‘t sick, you don‘t have
a hangover, you don‘t get hungr, you are
always alert and you see pigs fly.
(extreme programming in practice)
 Kardi Teknomo, PhD

User Stories vs Use Cases

„ A story is a token for a piece of system capability to be
implemented (sort of a change request)
„ A story is a placeholder for a long-running conversation
about requirements
„ Stories vs. Use Cases
„ A story is not a use case, a use case is not a story
„ A use case defines functional requirements in total
„ Set of use cases define breadth and depth of system
behavior, augmented with non-functional requirements
„ A story points to a portion of breadth and depth
„ Stories incrementally build up full scope
 Kardi Teknomo, PhD

Requirements VS User Stories

„ level of detail
„ User stories are short and to the point
„ User stories should only provide enough detail to
make a reasonably low risk estimate of how long the
story will take to implement.
„ focus on user needs
„ You should try to avoid details of specific
technology, data base layout, and algorithms. You
should try to keep stories focused on user needs and
benefits as opposed to specifying GUI layouts.
 Kardi Teknomo, PhD

Group Project
„ Make user stories
„ Estimate time for each user stories
„ Prioritize user stories
„ Plan a release & an iteration
„ Break down stories of one iteration into
tasks
„ Estimate time (hours) for each task
„ Prioritize tasks