La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

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

Présentations similaires


Présentation au sujet: "EXtreme Programming CNAM – GLG102 – Techniques et Normes pour la Qualité du Logiciel 26/01/2007 François Potentier."— Transcription de la présentation:

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

2 2 Sommaire I. Quest-ce que XP ? II. Le changement comme valeur du projet III. Éléments fondamentaux de XP IV. Modèle de développement V. Cycle de vie VI. Management VII. Outils VIII. Adopter XP IX. XP et Qualité

3 3 I. Quest-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 com

4 4 I. Quest-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 5 II. Changement – valeur du projet Le changement est la seule constante dans un projet => linclure dans le projet => abaisser les coûts du changement Outils adéquats Bonnes pratiques au quotidien – Développement Bonnes pratiques au quotidien – Management

6 6 III. Éléments fondamentaux dXP 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 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 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 dun point de vue utilisateur

9 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 ditération – EQUIPE Le client peut changer davis au début dune 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 10 V. Cycle de vie - Planification Distinction temps technique idéal – vélocité Temps technique idéal Temps que lon 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 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 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 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 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 dheures supplémentaires plus de 2 semaines consécutives

15 15 V. Cycle de vie - Intégration Intégration continue Plusieurs fois par jour pour chaque binôme Tâches dune granularité de quelques heures Évite le rush de lintégration avant la livraison : tous les jours une version stable du logiciel est disponible.

16 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 17 V. Cycle de vie – Tests fonctionnels Écriture de tests fonctionnels Écrits par le client avec laide de léquipe Au moins un testeur technique pour assister le client Itération terminée quand tous les tests fonctionnels passent.

18 18 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 Soccupe du jeu du planning Mesure lavancement Manager Interface avec le reste de lorganisation Soccupe des problèmes matériels de léquipe Vérifie que les résultats sont là

19 19 VII. Outils – Gestion de projet Outils papier – le tableau ostentatoire

20 20 VII. Outils – Gestion de projet Outils classiques MS Project : non adapté Outils agiles : gestion dune 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 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 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 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 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 25 IX. XP et Qualité Définition AFNOR NF5019 : Aptitude dun produit ou dun service à satisfaire les besoins utilisateur Un produit est de qualité sil répond aux exigences des utilisateurs, livré en temps voulu et au plus juste prix.

26 26 IX. XP et Qualité Norme ISO 9126 pour lévaluation dun logiciel Capacité fonctionnelleOUI FiabilitéOUI Facilité dutilisationOUI RendementOUI MaintenabilitéOUI Adaptabilité?

27 27 IX. XP et Qualité - les Normes Esprit damélioration permanente existe mais à lintérieur du projet seulement Côté industriel nexiste pas : absence de documentation : réussite du projet dépend de léquipe plus que de processus définis XP adapté nest pas contradictoire avec les normes

28 28 CONCLUSION Plus une discipline au quotidien et un état desprit quune méthode Première approche dorganisation 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 29 Questions ?


Télécharger ppt "EXtreme Programming CNAM – GLG102 – Techniques et Normes pour la Qualité du Logiciel 26/01/2007 François Potentier."

Présentations similaires


Annonces Google