Extreme Programming

Programmation agile
le cas de la programmation extrême
Sylvain Giroux
October 3rd, 2000
Plan
Quel est le problème à résoudre ?
XP: qu’est-ce ? pourquoi et quand l’appliquer ?
“X” ?
Méthodologie logicielle
Variables
Valeurs
Règles
Pratiques
Références
Le problème fondamental : le risque
Développement du logiciel
Échoue à livrer le logiciel,
Échoue à produire un logiciel ayant une valeur.







Glissements des échéanciers
Annulation de projets
Le système est dépassé
Quantité de défauts, bugs, etc.
Incompréhension ou changements des pratiques d’affaires
Des fonctionnalités puissantes, mais sans intérêt
Roulement de personnel
Méthodologie logicielle
Une méthodologie logicielle est un ensemble de règles
et de pratiques utilisées pour créer des logiciels.
Une méthodologie “lourde” possède plusieurs règles,
pratiques et documents. Elle requiert de la discipline et du
temps pour l’appliquer correctement.

Rational Unified Process (1491 fichiers dans 159 dossiers, en 2000)
Une méthodologie “légère” a peu de règles et de partiques,
qui sont faciles à appliquer.
Programmation extrême
Une discipline pour le développement de logiciel
pour de petites équipes (2-10 personnes)
afin de développer un logiciel
rapidement
dans un environnements où les besoins et les
spécificatiosn changent rapidement.
Objectif de XP
Livrer le logiciel
dont on a besoin
lorsqu’on en a besoin.
Quand utiliser XP?
Domaines pour lesquels les besoins changent / évoluent
On ne possède pas une idée claire / définitive de ce que le système doit faire
On s’attend à des changements fréquents des fonctionnalités du système (de
l’ordre de quelques mois).
Pour gérer les risques liés au projet.
Si le client a besoin d’un nouveau système à une date spécifique,
le facteur de risque est grand.
Si le système présente de nouveaux défis pour l’équipe de développement,
le facteur de risque est encore plus grand.
Si le système présente de nouveaux défis pour l’ensemble de l’industrie du
logiciel,
le facteur de risque est énorme.
Quand utiliser XP?
XP exige une équipe de développement étendue
Les développeurs
Les gestionnaires
Les clients
Pourquoi ?
Poser des questions,
Négocier la portée et les échéanciers,
Créer des tests fonctionnels

Demande plus que l’implication des seuls développeurs.
Tests
Unit Test: A test of one component of the system. Contrast with "system test."
Functional tests: Testing software based on its functional requirements. It ensures that the program
physically works the way it was intended and all required menu options are present. It also ensures that the
program conforms to the industry standards relevant to that environment; for example, in a Windows
program pressing F1 brings up help.
Regression Test: To test revised software to see if previously working functions were impacted.
System Test: Overall testing in the lab and in the user environment. See alpha test and beta test.
Acceptance Test: The test performed by users of a new or changed system in order to approve the system
and go live. Cosmetic and other small changes may still be required as a result of the test, but the system is
considered stable and processing data according to requirements.
Test Case: A set of test data, test programs and expected results.
Test Scenario: A set of test cases that ensure that the business process flows are tested from end to end.
Black Box Test: Testing software based on output only without any knowledge of internal operation.
Contrast with "white box test."
White Box Test: Testing software with knowledge of the internal operation. Contrast with "black box test."
http://www.pcmag.com/encyclopedia_term/0,2542,t=testing+types&i=52777,00.asp
Quand utiliser XP?
“Testabilité” du logiciel
Productivité
Les projets XP démontrent une plus grande
productivité des développeurs lorsqu’elle est
comparée à des projets similaires appartenant au
même domaine corporatif.
Pourquoi “extrême” ? -- I
Si la revue de code est une bonne pratique,
la revue de code sera réalisée en permanence (programmation par paires).
Si les tests sont importants,
tous vont écrire des tests tout le temps (tests unitaires),
même les clients (tests fonctionnels)
Si le design est important,
le design sera partie intégrante de la pratique de tous les membres
(refactorisation)
Si la simplicité est une qualité à rechercher,
le système utilisera toujours le design le plus simple possible capable de
supporter les fonctionnalités courantes
(le plus simple qui puisse possiblement fonctionner).
Pourquoi “extrême” ? -- II
If architecture is important,
everybody will work defining and refining the architecture all the time
(metaphor)
If integration testing is important,
we’ll integrate and test several times a day (continuous integration).
If short iterations are good,
we’ll make the iterations really, really short –seconds and minutes
and hours, not weeks and months and years (the Planning Game).
Four Variables
We will control four variables in our projects
Cost
Time
Quality
Scope
External forces (customers and managers) get to pick
the values of 3 of the variables.
The development team gets to pick the resultant value
of the 4th variable.
Values
XP is based on
Communication
Simplicity
Feedback
Courage.
Value : communication
Problems with projects can invariably be traced back to
somebody not talking to somebody else about something
important
A programmer doesn’t tell someone else about a critical
change in the design
A programmer doesn’t ask the customer the right question, so
a critical domain decision is blown
A manager doesn’t ask a programmer the right question, and
project progress is misreported
Value : communication and XP Practices
XP practices that can’t be done without communication
Unit testing
Pair programming
Task estimation
Value : simplicity
What is the simplest thing that could possibly work?
Not to look toward the things you’ll need
tomorrow and next week and next month
XP stance:
It is better
to do a simple thing today
and pay a little more tomorrow to change if it needs it,
than
to do a more complicated thing today that may never be used
anyway
Value : simplicity and XP Practices
The more you communicate,
the clearer you can see exactly what needs to be done and
the more you have confidence about what really doesn’t need to be
done
The simpler your system is,
the less you have to communicate about
Practices
Simple design
Refactoring
Value : Feedback at scale of minutes and days
Concrete feedback about the current state of the system
Don’t ask me, ask the system
Feedback for customers
When customers write new stories (description of features),
the programmers immediately estimate them
Feedback on project progress
Watching the completion of tasks to give the whole team
feedback about whether they are likely to finish everything they set out to do
in a span of time
Value : Feedback at scale of weeks and months
The customers and testers write functional tests for all the stories
(simplified use cases) implemented by the system.
The customers review the schedule every two or three weeks
to see if the team’s overall velocity matches the plan,
to adjust the plan
The system is put into production as soon as it makes sense,
so the business can
begin to “feel” what the system is in action and
discover how it can best be exploited.
Value : Feedback and XP practices
The more feedback you have,
the easier it is to communicate
Simple systems are easier to test
XP practices
The planning game
Small releases
Testing
Pair programming
Continuous integration
On-site customer
Value : Courage
Courage to take decisions
Radical surgery on code
Throwing code away
Starting over from scratch
Prototyping multiple design alternatives,
and keep only one for “real” development
Last but not least
Respect
Principles
From the 4 values,
a dozen or so of principles (rules)
are derived
to guide the development style
Central Principles
Main principles
Rapid feedback

time between action and feedback is critical
Assume simplicity
Incremental change

Big change made all at once just don’t work
Embracing change

Preserves the most options while solving the most pressing problem
Quality work

Nobody likes working sloppy
Less central principles
Teach learning
No doctrine
Small initial investment
Too many resources too early in a project is a recipe for disaster
Play to win
Playing to win vs playing not to lose

For sure we need to write reports,
… but getting a working system is more important…
Concrete experiments
Every time you made a decision and you don’t test it,
there is some probability that the decision is wrong.
Less central principles
Open, honest communication
Able to tell each other where there are problems in the code
Able to express fears and get support
Free to deliver bad news to customers and management,
to deliver it early,
and without being punished
Work with people’s instincts, not against them
XP is a process
where following short-term self-interest (win, learn, be in control, good work…)
also serves long-term team interest
Accepted responsibility
Not telling people what to do
Does not mean that you always do exactly what you feel like doing
Less central principles
Local adaptation
Adapt XP principles and practices to local conditions
Travel light
You can’t expect to carry a lot of baggage and move fast
Be prepared to change direction
Artifacts



Few
Simple
Valuable
Honest measurement
This will take 14.176 hours (???)
Back to basics
There are 4 activities to support
Coding
Testing
Listening
Designing
XP Practices
What is a practice?
the usual way of doing something
Aim of practices in XP:
Structure the 4 activities
In XP, there are 12 practices
12 Practices
The Planning Game
Small Releases.
Metaphor.
Simple Design.
Testing.
Refactoring.
Pair Programming.
Collective Ownership.
Continuous Integration.
40-hour Week.
On-site Customer.
Coding Standard.
Practice: The Planning Game
Determine
what will be accomplished by the due date,
determining what to do next
The XP "customer“
define the business value of desired features
The programmer
provides cost estimates
The XP "customer“
choose
 what needs to be done
 what needs to be deferred
Practice: Small releases
XP teams
put a simple system into production early,
update it frequently on a very short cycle
Practice: Metaphor
XP teams use


common "system of names" and a
common system description

that guide development and communication

We don’t literally mean “the system is…”

Give everyone a coherent story within which to work

Help everyone on the project understand the basic elements and
their relationships

"this program works like a hive of bees, going out for pollen and bringing it
back to the hive" as a description for an agent-based information retrieval
system
Practice: Simple design
A program built with XP should be
the SIMPLEST program that meets the current requirements.

There is not much building "for the future".
Practice: Testing
XP teams focus on validation of the software at all times.
Programmers develop software by writing tests first,
then software that fulfills the requirements reflected in the tests.
Customers provide acceptance tests
that enable them to be certain that
the features they need are provided.
Practice: Refactoring
XP teams improve the design of the system
throughout the entire development
removal of duplication (a sure sign of poor design),
on increasing the "cohesion" of the code, while lowering the "coupling".
High cohesion and low coupling have been recognized as the hallmarks of well-designed
code for at least thirty years
This is done by keeping the software clean
without duplication
with high communication
simple
yet complete
Practice: Pair Programming
XP programmers write all production code in pairs,
two programmers working together at one machine
Practice: Collective ownership
All the code belongs to all the programmers
This lets the team go at full speed,
because
when something needs changing,
it can be changed without delay
Practice: Continuous integration
XP teams integrate and build the software system
multiple times per day
This keeps all the programmers on the same page,
and enables very rapid progress
integrating more frequently tends to eliminate
integration problems that plague teams who
integrate less often
Practice: 40-hour week (sustainable pace)
Tired programmers make more mistakes.
XP teams do not work excessive overtime,
keeping themselves fresh, healthy, and effective
This means that they work overtime when it is effective, and that they
normally work in such a way as to maximize productivity week in and
week out.
Practice: On-site customer
An XP project is steered by a dedicated individual
who is empowered to
determine requirements,
set priorities,
answer questions as the programmers have them
Practice: Coding standards
to work effectively in pairs,
to share ownership of all the code,
all the programmers need to write the code in the same way
with rules that make sure the code communicates clearly
Software, naming, language, {}…
XP map
A spike solution is a very simple program to explore potential solutions
References
Kent beck, Extreme Programming Explained: Embrace Change,
Addison Wesley, 2000
Martin Fowler, Refactoring : Improving the Design of Existing Code,
Addison-Wesley, 1999
http://www.xprogramming.com
http://www.xprogramming.com/xpmag/index.htm
http://www.xprogramming.com/Practices/xpractices.htm
http://www.extremeprogramming.org/