CNAM – GLG102 – Techniques et Normes pour la Qualité du Logiciel eXtreme Programming CNAM – GLG102 – Techniques et Normes pour la Qualité du Logiciel 26/01/2007 François Potentier

Sommaire Qu’est-ce que XP ? Le changement comme valeur du projet Éléments fondamentaux de XP Modèle de développement Cycle de vie Management Outils Adopter XP XP et Qualité

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 Méthode encore récente donc en évolution .com => mise sur le marché rapide nécessaire. Les méthodes traditionnelles ne sont pas adaptées.

Caractéristiques des méthodes agiles – Agile Manifesto I. Qu’est-ce que XP ? Caractéristiques des méthodes agiles – Agile Manifesto Travail d’équipe VS Process et outils Logiciel qui fonctionne VS Documentation Collaboration client VS Contrat blindé Ouverture au changement VS Suivre un plan

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

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

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

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

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

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é

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

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

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

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

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.

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

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.

VI. Management Responsabilité 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à

VII. Outils – Gestion de projet Outils papier – le tableau ostentatoire A étoffer avec des screenshots

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…

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 VIII. V

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

VIII. Adopter XP – Comment ? Appliquer les recommandations de la méthode : par petites touches Le jeu du planning Tests unitaires et intégration continue avec mise en place de serveurs de builds Testeur technique pour les tests fonctionnels

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

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.

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é ?

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

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

Questions ?