Programmation agilele cas de la programmation extrême

Sylvain GirouxOctober 3rd, 2000

PlanQuel est le problème à résoudre ? XP: qu’est-ce ? pourquoi et quand l’appliquer ?“X” ?Méthodologie logicielle

VariablesValeursRèglesPratiques

Références

Le problème fondamental : le risqueDé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 logicielleUne 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êmeUne 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éveloppeursLes 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.

TestsUnit 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” ? -- ISi 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” ? -- IIIf 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 VariablesWe will control four variables in our projects

CostTimeQualityScope

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.

ValuesXP is based on

Communication

Simplicity

Feedback

Courage.

Value : communicationProblems 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 PracticesThe 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

PracticesSimple designRefactoring

Value : Feedback at scale of minutes and days

Concrete feedback about the current state of the systemDon’t ask me, ask the system

Feedback for customersWhen customers write new stories (description of features), the programmers immediately estimate them

Feedback on project progressWatching 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 practicesThe more feedback you have, the easier it is to communicate

Simple systems are easier to test

XP practicesThe planning gameSmall releasesTestingPair programmingContinuous integrationOn-site customer

Value : CourageCourage 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

PrinciplesFrom the 4 values,

a dozen or so of principles (rules)

are derived

to guide the development style

Central PrinciplesMain 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 principlesTeach learning

No doctrine

Small initial investmentToo many resources too early in a project is a recipe for disaster

Play to winPlaying to win vs playing not to lose

For sure we need to write reports, … but getting a working system is more important…

Concrete experimentsEvery time you made a decision and you don’t test it, there is some probability that the decision is wrong.

Less central principlesOpen, honest communication

Able to tell each other where there are problems in the codeAble to express fears and get supportFree to deliver bad news to customers and management, to deliver it early, and without being punished

Work with people’s instincts, not against themXP is a process where following short-term self-interest (win, learn, be in control, good work…)also serves long-term team interest

Accepted responsibilityNot telling people what to doDoes not mean that you always do exactly what you feel like doing

Less central principlesLocal adaptation

Adapt XP principles and practices to local conditions

Travel lightYou can’t expect to carry a lot of baggage and move fastBe prepared to change directionArtifacts

Few Simple Valuable

Honest measurementThis will take 14.176 hours (???)

Back to basicsThere are 4 activities to support

Coding

Testing

Listening

Designing

XP PracticesWhat 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 PracticesThe Planning GameSmall Releases. Metaphor. Simple Design. Testing. Refactoring. Pair Programming. Collective Ownership. Continuous Integration. 40-hour Week. On-site Customer. Coding Standard.

Practice: The Planning GameDetermine

what will be accomplished by the due date, determining what to do next

The XP "customer“define the business value of desired features

The programmerprovides cost estimates

The XP "customer“choose

what needs to be done what needs to be deferred

Practice: Small releasesXP teams

put a simple system into production early,

update it frequently on a very short cycle

Practice: MetaphorXP 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 designA 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 cleanwithout duplicationwith 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 ownershipAll 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 integrationXP 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 customerAn 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 waywith 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

ReferencesKent 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/