eXtreme Programming

CNAM – GLG102 – Techniques et Normes pour la Qualité du Logiciel

26/01/2007 François Potentier

2

Sommaire

I. Qu’est-ce que XP ?II. Le changement comme valeur du projetIII. Éléments fondamentaux de XPIV. Modèle de développementV. Cycle de vieVI. ManagementVII. OutilsVIII. Adopter XPIX. XP et Qualité

3

I. Qu’est-ce que XP ?

Méthode de développement Rassemblement de bonnes pratiques déjà

connues et utilisées Une des méthodes agiles Récente : 1999 Bilan des premiers retours : fin 2004 Prend son essor début 2000 - .com

4

I. Qu’est-ce que XP ?

Caractéristiques des méthodes agiles –Agile Manifesto

1. Travail d’équipe VS Process et outils

2. Logiciel qui fonctionne VS Documentation

3. Collaboration client VS Contrat blindé

4. Ouverture au changement VS Suivre un plan

5

II. Changement – valeur du projet

Le changement est la seule constante dans un projet

=> l’inclure dans le projet=> abaisser les coûts du changement

Outils adéquats Bonnes pratiques au quotidien – Développement Bonnes pratiques au quotidien – Management

6

III. Éléments fondamentaux d’XP

5 valeurs les racines

Communication Simplicité Feedback Courage Respect

5 principes essentiels les guidelines

Accélérer le feedback Supposer la simplicité Changer de façon

incrémentale Accueillir le changement Chercher la qualité

Mise en œuvre dans les pratiques au quotidien

7

IV. Modèle de développement

Modèle de développement INCREMENTAL Cycle de vie en SPIRALE Petites livraisons : entre 1 et 2 mois Itérations : entre 2 à 3 semaines

8

V. Cycle de vie - Spécifications

Client sur site Documentation minimale Il écrit les scénarios client – fiches scénarios Il choisit les scénarios de la prochaine

livraison Il les classe par importance d’un point de vue

utilisateur

9

V. Cycle de vie - Planification Planning de livraison – CLIENT

A partir des scénarios écrits par le client L’équipe estime les scénarios Le client classe les scénarios par importance L’équipe donne au client le nombre de points à dépenser Il choisit les scénarios de la prochaine livraison

Planning d’itération – EQUIPE Le client peut changer d’avis au début d’une itération Les fiches de scénario donnent des fiches de tâches Choix des tâches puis estimation personnelle Nivellement des charges de travail

10

V. Cycle de vie - Planification

Distinction temps technique idéal – vélocité Temps technique idéal

Temps que l’on mettrait sans être dérangé, sans réunion… Correspond à une charge de travail

Vélocité Temps calendaire pour réaliser la charge de travail estimée

Vélocité itération courante = vélocité constatée pour itération précédente

Total scénarios choisis ne dépasse pas la vélocité

11

V. Cycle de vie - Planification

Choix : Le client choisit le contenu => date déduite Le client fixe la date => contenu adapté

On privilégie : Fréquence fixe Variation du périmètre

12

V. Cycle de vie - Conception

Une conception simple Le système répond aux scénarios du client. Aucune anticipation des problèmes futurs Architecture obtenue lors de la première

itération Graphes de conception maintenus à jour

13

V. Cycle de vie – Développement

Responsabilité collective du code Chacun intervient sur tout le projet

Programmation en binômes Code de meilleure qualité Partage des connaissances Évite les retours à « l’état sauvage »

Refactoring permanent Éliminer toute flexibilité inutile Ajouter de la souplesse en cas de besoin Améliorer le code en le rendant plus clair

14

V. Cycle de vie – Développement

Conventions de nommage Utilisation de métaphores

Parler un langage commun dans l’équipe Meilleur dialogue entre fonctionnel et technique

Rythme soutenable Pas d’heures supplémentaires plus de 2 semaines consécutives

15

V. Cycle de vie - Intégration

Intégration continue Plusieurs fois par jour pour chaque binôme Tâches d’une granularité de quelques heures Évite le rush de l’intégration avant la livraison :

tous les jours une version stable du logiciel est disponible.

16

V. Cycle de vie – Tests unitaires

Écriture systématiques de tests unitaires Clé de voûte de la méthode Priorité numéro 1 du programmeur Écrits avant le code

le code est terminé quand tous les tests unitaires imaginés passent

Conservés sans limite de temps Exécutés en totalité à chaque build Exécution automatique

17

V. Cycle de vie – Tests fonctionnels

Écriture de tests fonctionnels Écrits par le client avec l’aide de l’équipe Au moins un testeur technique pour assister

le client Itération terminée quand tous les tests

fonctionnels passent.

18

VI. ManagementResponsabilité forte de l’équipe - dilution du rôle de chef de projet Coach

Mise en œuvre de la démarche Amélioration du fonctionnement de l’équipe

Tracker Responsable des indicateurs S’occupe du jeu du planning Mesure l’avancement

Manager Interface avec le reste de l’organisation S’occupe des problèmes matériels de l’équipe Vérifie que les résultats sont là

19

VII. Outils – Gestion de projet

Outils papier – le tableau ostentatoire

20

VII. Outils – Gestion de projet Outils classiques

MS Project : non adapté

Outils agiles : gestion d’une liste de tâche, pas de synchro entre les tâches. Important : charge de travail cohérente et date atteignable.

Hansoft

XPlanner

Bugs trackers étendus JIRA

Mantis…

21

VII. Outils – Dvt-Intégration-Tests

Souplesse et ciblage des modifications Langage objets : Java sous Eclipse (C# en .NET)

Graphes de conception UML : eUML2 pour Eclipse, cohérence graphes-code

Tests unitaires Framework de tests : JUnit pour Eclipse (NUnit en .NET)

Contrôle de version Subversion, Subversive/Subclipse pour Eclipse

Intégration continue et tests unitaires automatiques CruiseControl

22

VIII. Adopter XP - … ou pas

Utiliser XP quand…

Besoins flous Périmètre mal défini Petite équipe – 12

personnes maximum Site unique Pas de sous-traitance

Ne pas utiliser XP si…

Besoins changeront peu Périmètre bien défini Équipe de plus de 12

personnes Dvt multi-sites Dvt off-shore Projets critiques

23

VIII. Adopter XP – Comment ?

Le jeu du planning Tests unitaires et intégration continue avec

mise en place de serveurs de builds Testeur technique pour les tests

fonctionnels

Appliquer les recommandations de la méthode :par petites touches

24

VIII. Adopter XP - Difficultés

Implication forte du client nécessaire Entente parfaite entre les membres de

l’équipe Synergie des pratiques entre elles => tout

ou rien Abandon temporaire des tests unitaires =>

effondrement de l’édifice Contrats peu adaptés à XP

25

IX. XP et Qualité

Définition AFNOR NF5019 : Aptitude d’un produit ou d’un service à satisfaire les besoins utilisateur

Un produit est de qualité s’il répond aux exigences des utilisateurs, livré en temps voulu et au plus juste prix.

26

IX. XP et Qualité

Norme ISO 9126 pour l’évaluation d’un logiciel Capacité fonctionnelle OUI Fiabilité OUI Facilité d’utilisation OUI Rendement OUI Maintenabilité OUI Adaptabilité ?

27

IX. XP et Qualité - les Normes

Esprit d’amélioration permanente existe mais à l’intérieur du projet seulement

Côté industriel n’existe pas : absence de documentation : réussite du projet dépend de l’équipe plus que de processus définis

XP adapté n’est pas contradictoire avec les normes

28

CONCLUSION

Plus une discipline au quotidien et un état d’esprit qu’une méthode

Première approche d’organisation Limites assez vite atteintes XP est en pleine évolution – 6 ans Fait avancer la réflexion sur les méthodes Devient un argument commercial Bien adapté au jeu vidéo

29

Questions ?