eXtreme Programming, une introduction

Introduction à XP Hortis GRC SA - www.hortis.ch

Be prepared for changes!

eXtreme Programming,une introduction

Par Didier [email protected]

Hortis GRC SA - www.hortis.ch

3

Coût du développement software


0

2000

4000

6000

8000

10000

0 5 10 15 20

Time

Co

st

Barry W. Boehm , Software Engineering Economics, Prentice Hall PTR, 1981;ISBN: 0138221227

But de XP

4

eXtreme Programming: principes

Développement itératifs, Plannification adaptable, pas rigide, Architecture évolutive, non-contraignante, Des tests, des tests, et encore des tests, Be prepared for changes!


5

La Métaphore du Cycle

MéthodologiesHéritées des

gros systèmes

eXtremeProgramming

RapidApplicationDevelopment

6

Historical Perspective

MéthodologiesHéritées des

gros systèmes

eXtremeProgramming

RapidApplicationDevelopment

7

Perspective littéraire

Voltaire (1694-1778),Dictionaire Philosophique : “ Le bon sens est la chose du monde la mieux

partagée, car chacun pense en être bien pourvu.”


8

eXtreme Programming en quelques mots

Utilisation du bon sens, Faire les choses simplement, Priviliégier la communication, Interagir de près avec le client; Faire tout cela à 100%,

Sans compromis!



9

Perspective littéraire

René Descartes (1596-1650),Discours de la méthode :

• “ ... La seconde, de diviser chacune des difficultés que j’examinerais, en autant de parcelles qu’il se pourrait, et qui serait requis pour les mieux résoudre.” (page 47 de l’édition G.F. 1966)


10

Méthodologie “Cascade”


Analyse

Design

Code

Test

Années

Analyse dépassée!

11

Application de la 2ème méthode de Descartes


Analyse

Design

Code

Test

Analyse

Design

Code

Test

Analyse

Design

Code

Test

Analyse

Design

Code

Test

FonctionsProjet Analyse

Design

Code

Test

Tâches

Analyse

Design

Code

TestAnalyse

Design

Code

Test

Analyse

Design

Code

Test

Analyse

Design

Code

Test

Analyse

Design

Code

TestAnalyse

Design

Code

Test

Années

Semaines

Jours

12

Plannification à la SCRUM

Client et développeurs écrivent ensembles les fonctionalités sur un support (cartes ou JIRA): User stories;

Le client donne des priorités à chaque fonctionalités ,

Les développeurs fractionnent chaque fonctionalité en tâches,

Les développeurs attribuent “une mesure de complexité” à chaque tâche.


13


La mesure de complexité peut se convertir en temps de réalisation, vélocité (auto-calibrée!);

La complexité de chaque fonctionalité est calculée comme la somme des complexités de chaque tâche,

Le client décide alors de la prochaine livraison du système.


14


Si une date de livraison est en passe d’être dépassée...

... on signale le probléme au client... ... qui décidera des fonctionalités a retirer pour

conserver la date de livraison; Après une “bonne” livraison, le client décide de

la mise en service.


15

Structure en itérations et livraisons


User Stories

LivraisonRecetteclient

LatestversionIterationRelease

plan

BugsNew userstories

Estimation de la vélocité

Acceptance

Sénarios de test

Architecture

Plannifi-cation

Requirements

Structure

16

Les 8 chemins vers XP


Livraisons fréquentes

Simplicité

Refactoring

Intégration continue Code à tous

Programmer en pairesTest

Sépar. métier et technique

17

Séparation métier et technique

Le client connait son métier, Les développeurs connaissent leurs outils, Le client définit les priorités, Les développeurs définissent les délais.


18

Séparation métier et technique

Le client doit

les développeurs pas! décider des enchainements (workflow), définir les champs, les menus et les boutons, choisir une charte graphique;

Les développeurs doivent

le client pas! décider d’une architecture, choisir leurs outils (langage, data base, etc...), définir les classes et les interfaces.


a le dernier mot pour

ont le dernier mot pour

19

Tests

Test Driven Design: Écrire un test avant de coder;

Tests unitaires écrits par les développeurs: Tester tout ce qui peut “foirer”, utiliser les valeurs limites;

Tests d’acceptance écrits par le client: Vérification des requirements, Bon départ pour la documentation;



20

Intégration Continue

Chaque changement est immédiatement inclus dans un système déployé,

Le déploiement fait partie du développement, Un système utilisable existe en permanence,

les développeurs peuvent essayer le système, le client aussi!



21

Livraisons fréquentes

Conséquence directe du principe d’intégration continue,

Le client a le système en main le plus tôt possible,

Cela lui donne l’occasion de réagir avant qu’il ne soit trop tard,

Choc des nouvelles fonctionnalités atténué, Be prepared for changes!


22

Simplicité

Écrire du code lisible (pas de virtuosité), Les autres doivent pouvoir le lire, vous aussi, après quelques semaines!

Les intentions doivent être claires: Utiliser des standards (format, coding), Éviter les abbréviations, Éviter les commentaires;

Ne pas prévoir le futur (vous n’êtes pas devin): C’est une perte de temps pour aujourd’hui, Ce sera une perte de temps demain!


23

Programmation par paires

2 personnes font plus que le double de travail, “One types while the other thinks,” Une variation des paires est le meilleur moyen

de faire circuler l’information, Les nouveaux venus sont promptement

intégrés, Les juniors apprennent beaucoup plus vite... … et donc, contribuent beaucoup plus vite!


24

Le code appartient à tous

Chaque développeur doit savoir tout faire, Pas de chasse gardée, pas de “prima donna”, Personne ne doit être indispensable, Donc, le projet ne s’arrêtera pas si quelqu’un

s’absente, Le principe de simplicité est un pré-requis.


25

Refactoring

Amélioration continue qui fait partie du développement,

Architecture évolutive, qui s’adapte: “This skill helps develop software that stays soft,

and allows more focus on features and less on infrastructure, delivering more value withoutrisking the long term.” (Ron Jeffries)



26

Conséquences sur le code

Coder dans l’ordre suivant: “Make it run ”

Créer un cas test, le faire passer, “Make it good ”

Refactorer le code pour en améliorer la lisibilité et l’architecture,

“Make it fast ”Si besoin est, optimiser l’exécution;

“Say things once and once only! ” Ne rien duplifier “extract method” au lieu de “cut&paste”.


27

Les 8 chemins vers XP (conclusion)


Sépar. métier et techniqueCustomers know their business,Developer team knows how to use the tools.

Intégration continueCustomers can always see a working version.Full control over development.

Livraisons fréquentesCustomers make their product evolve withthe market. Changes are possible on the fly.

TestAutomated tests ensure that a change doesnot create new errors. Business test cases.

SimplicitéClearly stated code, no duplicated logic, fewest number of objects.

Programmer en paires“One types, the other thinks”. This ensuresthe best communication within the team.

Code à tousAnyone would can contribute to the code will.Customers get the best of our developers.

RefactoringWhen adding a new feature, existing code isadapted if needed, ensuring code reuse.

28

Questions

?


Technology

eXtreme Programming, une introduction