XP - eXtreme

Programming

A Brief Introduction ?
Carl-Fredrik Sørensen, PhD Fellow
mailto:carlfrs@idi.ntnu.no

09/19/20
 Presentation Outline
 XP/Agile SD: What and Why?
 How to do XP?
– Processes
– Team practices
– Programming
– Rules and Practices

09/19/20
 I: What Is Extreme
Programming?
 Deliberate and disciplined approach to
software development.
 Stresses customer satisfaction.
– Deliver when needed.
– Respond to changing requirements.

09/19/20
 II: What Is Extreme
Programming?
 Emphasises team work.
 Improves in Four essential dimensions:
– Communication.
– Simplicity.
– Feedback.
– Courage.

09/19/20
 A Change in the Way We
Program
 Keep things simple and elegant.
 Emphasises testing.
– Automated tests.
– Create tests before, when and after coding.
– When bugs are found, new tests are added.
 Embrace change.
– Early feedback.
– Acknowledges that requirements can/will change.
 Constant integration.

09/19/20
 Do We Need Yet
Another Methodology?
 XP - Based on observations of what
improves/reduces the speed of
programming.
 Re-examination of software development
practices.
 Lightweight/Agile software methodology.
– Reduce cost of software.
– Simple and enjoyable.

09/19/20
 What Is an Agile/lightweight
Methodology?
 Software Methodology:
– Set of rules and practices.
 Heavyweight.
– many rules, practices and documents.
 Lightweight.
– few rules and practices or some that are easy to
follow.

09/19/20
 Agile Software Manifesto
 XP, Scrum, DSDM, ASD, Crystal, Feature-driven
Development, Pragmatic Programming:
– 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 up a plan.
– That is, while there is value in the items on the right,
we value the items on the left more.

09/19/20
09/19/20
 User Stories
 Same purpose as use cases.
– Used to create time estimates for release planning.
– Replaces large requirements documents.
 Written by customers.
 Drives the creation of acceptance tests.
 Developers create estimates in “ideal development
time”.
 A set of selected user stories form a release plan.
 Focused on user needs.
09/19/20
 User Story Examples
Story: Handle
overdraft
When a transaction causes a customer’s account to go
into overdraft, transfer money from the overdraft
protection account, if any.

Story: Compute balance

For each account, compute the balance by adding up

all the deposits, and subtracting all the deductions.

09/19/20
 Architectural Spike
 Spike solutions:
– Figure answers to tough technical or design problems.
– Reduce the risk of a technical problem.
– Increase the reliability of estimate for a user story.
 Simple program to explore potential solutions.
 Address only one problem at a time.

09/19/20
 Choose a System Metaphor
 Establish a common vocabulary for the
system.
 Consistent naming of classes and methods.
 Names should be easy to learn and relate to.

09/19/20
 Examples: System Metaphor
 Naïve  Editors:
 Assembly line – Card (Punched card
imitation)
 Shared blackboard
– Array of lines (vi)
 Subcontractors – String (Emacs)
 Workflow – Sequence of runs
(Word)
– Tree (XML)
– Combinations

09/19/20
 I: Release Planning Meeting
 Establish a release plan.
 The release plan is used to create iteration plans
for each individual iteration.
 Has a set of rules to balance technical and
business decisions/forces to negotiate a
schedule.

09/19/20
 II: Release Planning Meeting
 The release plan is based on developer estimates
of a set of user stories and customer priorities
(time/scope).
 Customer decides priorities of user stories. Most
important first.
 User stories are selected for an iteration based on
either time or scope. Early deliverable with
business value is desired.

09/19/20
 Release Plan
 Contains:
– user stories to be implemented for each system
release.
– dates for those releases.

09/19/20
 Release Planning
Split a Story
(Customer) Sort Stories
by Value
“Too big” (Customer)

Write a Story Estimate a Story

Declare Velocity
(Customer) (Programmer)
(Programmer)
“Don’t know how”

Spike a Story Choose Scope

(Programmer) (Customer)

09/19/20 Exploration Planning

 I: Acceptance Test
 Created from user stories.
 Iteration: selected user stories are translated to
acceptance tests.
 Scenarios: specified by the customer to test for correct
implementation of a user story.
 A story may have one or many acceptance tests.
 Is black-box system tests.
 Customer verifies correctness and reviews test scores to
decide priority of failed tests.
 Used as regression tests prior to a production release.

09/19/20
 II: Acceptance Test
 User story is not complete before succeeding its
acceptance tests.
– New tests for each iteration, or the development will
report zero progress.
 Should be automated to be run often.
 The XP team schedules time to fix any failed
tests for each iteration.

09/19/20
 Small Releases
 Release iterative versions to the customers often.
 Release planning meeting to discover small units of
functionality that:
– Make good business sense.
– Released into the customer's environment early in the project.

 Critical to getting valuable feedback in time to have an

impact on the system's development.
 The longer you wait to introduce an important feature
the less time you will have to fix it.

09/19/20
09/19/20
 Iterative Development
 Divide schedule into about a dozen iterations of 1
to 3 weeks in length.
 Do not schedule programming tasks in advance.
– Use iteration planning meetings before each iteration.
– Do not implement anything ahead (not scheduled for
this iteration).
 Easier to handle changing requirements when:
– never adding functionality early.
– practice just-in-time planning.

09/19/20
 Project Velocity
 A measure of how fast work is getting
done.
– Number of user stories/programming tasks
finished during an iteration.
– Compare to estimates.
 Used as input for estimating how many new
stories to be done in next iteration.

09/19/20
Never Add Functionality Early
 Code for today, leave tomorrow code until
tomorrow.
 Avoid guesses of what are needed in the
future.

09/19/20
 When a Bug Is Found
 Create tests to stop it coming back.
 Acceptance tests helps customers define
and communicate the problem concisely.
 Created before debugging helps developers
to:
– focus their efforts (create unit tests).
– know when a problem is fixed.

09/19/20
 Iteration Planning
 Performed at the start of each iteration to:
– Choose user stories (customer) and failed acceptance
tests for the iteration.
– Translate chosen user stories into programming tasks.
– Sign up for tasks and estimate them (developers).
– Use project velocity to determine if tasks can be
accomplished in time.
 Plan only programming tasks for the first (next)
iteration.

09/19/20
 Iteration Planning Game
Phase 1: Brainstorming Phase 2: Accepting tasks

Programmer 1
Select and
Read Story Estimate
Cards Tasks
“It’s too big” Programmer 2
Or
“I'm too busy”
Write Task Programmer 3
Unclaimed
Cards Tasks

Programmer 4

09/19/20
09/19/20
 Daily Stand Up Meeting
 Every morning to communicate:
– problems.
– solutions.
– promotes team focus.
 Replaces project meetings.

09/19/20
09/19/20
I: Collective Code Ownership
 Everyone contributes new ideas to all parts
of a project.
 Any developer can change any line of
code to:
– add functionality.
– fix bugs.
– refactor.

09/19/20
II: Collective Code Ownership
 Avoids bottlenecks.
 Unit tests guards (all code must include
unit tests).
 All code must pass the entire test suite
100%.

09/19/20
 CRC Cards
 Class, Responsibilities and Collaboration
(CRC) Cards are used to design the system
as a team.
 Allows the whole team to participate.
 Simulates the system by representing
objects with responsibilities and
collaborating objects.

09/19/20
 CRC Cards
 UML-tools can be used, but may be
awkward when many people participate.
 Round-trip engineering possible in many
“CASE”-tools to UML’ify the CRC-design
from source code.

09/19/20
 Code the Unit Test First
 Easier and faster to create code if the unit tests
are created before the code.
 Explicit about the scope of the implementation.
 Helps to consider what is needed to be done.
Requirements are represented by tests.
 Gives immediately feedback, and we know when
we are done (all unit tests run).
 Grows confidence in the correct functioning of
the system as it grows.

09/19/20
 Code the Unit Test First
 Benefit for system design by being easier to
test.
 Separates logical design from physical
design from implementation.
 Simplifies the design.
 Always code as simple as possible to make
the test(s) pass.
 Only wanted features are coded.

09/19/20
 I: Pair Programming
 All production code are created by two
people working together at a single
computer.
– Increases software quality without impact on
delivery time.
– Add as much functionality by coding individual
by with much higher quality (saves time later in
the project).

09/19/20
 II: Pair Programming
 One thinks tactically about the method to
implement.
 The other thinks strategically about how
that method fits into the class.
 More people learn more of the system.
 Pairs are not constant, may switch many
times a day.

09/19/20
 Simplicity Is the Key
 Simple design takes shorter time to complete than
a complex one.
 Always do the simplest thing that can possible
work.
 Replace complex code by simpler, it is cheaper to
replace it now than use a lot of time on it later.
 Never add functionality before it is scheduled.
 Keeping design simple is a hard work!

09/19/20
 Move People Around
 Avoid serious knowledge loss and coding bottle
necks.
 Cross-training is achieved.
 Everyone knows much of the code in each part of
the system.
 Makes team more flexible and increases
productivity.
 Encourage people to work on a new part in each
iteration.

09/19/20
 Refactor Mercilessly
 Remove redundancy.
– Everything should be expressed once and only
once.
 Eliminate unused functionality.
 Replace complex and/or obsolete design
with new simpler design.
 Saves time and increases quality.
 Keeps the code clean and concise.

09/19/20
 I: Integrate Often
 Integrate and release code into code
repository as often as possible.
 Never hold a change more a than day.
 Avoids diverging and fragmented
development efforts.
 Makes code reuse and sharing more
effective.

09/19/20
 II: Integrate Often
 Everyone is working with the latest
version.
 Compatibility issues are detected and/or
avoided earlier.
 Avoids integration problems late in the
project.

09/19/20
 Sequential Integration
 Developers should integrate code to code
repository sequential. Only one pair at a
time.
– Consistent repository.
– Avoid obsolete versions.
 Dedicated computer.
 Integrate and release often.

09/19/20
 I: Unit Tests
 Create/download a unit test framework (i.e.
JUnit).
– Create automated test suites.
 Test all classes in the system.
 Create tests before code.
 Unit tests part of the release.
– Code without test should not be released.

09/19/20
 II: Unit Tests
 Missing unit tests should be created.
 Enables collective code ownership.
 Guards functionality to be accidentally
harmed.
 All code should pass all unit tests before
released.

09/19/20
 Fix XP When It Breaks
 If there are practices that do not work,
change them.

09/19/20
 The Customer Is Always
Available
 One of few requirements.
 Is part of the team. All phases requires
communication with the customer.
– User stories.
– Release planning.
– Acceptance tests.
– Detailing user stories.
– Try the system early.

09/19/20
 XP Project Organisation
 Customer
 Programmers
 (Project) Manager
 Tracker
 Coach

09/19/20
 XP Managers Do Not:
 Set priorities; the customer do
 Assign tasks; programmers do
 Estimate stories or tasks; programmers do
 Dictate schedules; Customer and
programmers negotiate them

09/19/20
 XP Managers Do:
 Face outside parties.
 Form the team.
 Obtain resources.
 Manage the team:
– Report progress.
– Host meetings.
– Host celebrations.
 Manage problems.
09/19/20
 Trackers
 Track the release plan (stories)
 Track the iteration plan (tasks)
 Track acceptance tests (succeeded, failed)

09/19/20
 I: How Do I Start XP?
 New project.
– Collect user stories.
– Conduct spike solutions.
– Release planning meeting.
– Iterative development (iteration planning
meeting).

09/19/20
 II: How Do I Start XP?
 Already running project.
– Collect user stories if trouble with requirements.
– Iterative and just in time planning of tasks if changing
requirements.
– Automated functional tests if many bugs in production,
to be used in regression and validation testing.
– Automated unit tests if trouble with integration.
– Refactoring, test-first programming (on your own).

09/19/20
 The Rules and Practices
of Extreme Programming.
 Planning.  Designing.
– User stories are written. – Simplicity.
– Release planning creates the – Choose a system metaphor.
schedule. – Use CRC cards for design
– Make frequent small releases. sessions.
– The Project Velocity is measured. – Create spike solutions to
– The project is divided into iterations. reduce risk.
– No functionality is added
– Iteration planning starts each
iteration. early.
– Refactor whenever and
– Move people around.
wherever possible.
– A stand-up meeting starts each day.
– Fix XP when it breaks.
09/19/20
 The Rules and Practices
of Extreme Programming
 Coding.
– The customer is always available.
– Code must be written to agreed
standards.
– Code the unit test first.
– All code is pair programming.
– Only one pair integrates code at a
time.
– Integrate often.
– Use collective code ownership.
– Leave optimisation till last.
– No overtime.
09/19/20
 Testing.
– All code must have unit
tests.
– All code must pass all 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.
 References
 Books: XP Series
– Kent Beck: Extreme Programming Explained; Embrace
change
– Kent Beck & Martin Fowler: Planning Extreme
Programming
– Ron Jeffries et.al: Extreme programming Installed
– Bill Wake: Extreme Programming explored
– James Newkirk, Robert C. Martin: Extreme
Programming in Practice
– G. Succi & M. Marchesi: Extreme Programming
Examined

09/19/20
 References
 Martin Fowler: Refactoring
 Alistair Cockburn: Agile Software
Development

09/19/20
 Web Sites
 http://www.extremeprogramming.org/
 http://www.xprogramming.com/
 http://www.egroups.com/group/extremeprogramming
 http://www.junit.org/
 http://www.pairprogramming.com
 http://www.refactoring.com/
 http://www.xpdeveloper.com
 http://www.xp123.com

09/19/20