Une introduction au eXtreme Programming (XP) GEF492A 2014 Référence: [Jefferies et al ch. 1,2, 7, 9-14] Capt Vincent Roberge Collège Militaire Royal du Canada Génie électrique et génie informatique roberge.segfaults.net SPW07-eXtremeProgramming.pdf

Aperçu Introduction au Extreme Programming (XP) Les 12 pratiques du XP Rôles et responsabilités Planification de versions XP Programmation en XP Programmation en pair 2 Automne 2014GEF492

eXtreme Programming Qu'est-ce que c'est Une méthodologie d'élaboration légère pour les projets de développement logiciel petit ou moyen (avec besoins vagues or instables) Une méthodologie qui met l'emphase sur la participation du client et les tests Un départ radical des méthodologies traditionnelles promet une réduction de risques, une réponse au client amélioré, une hausse de productivité, et la transformation de l'activité de construction logicielle en quelque chose d'amusant! Qu'est ce que ce n'est pas De la programmation "cowboy" Une activité ad-hoc sans organisation Un processus rigide La personnalisation bien pensée est encouragée 3 Automne 2014GEF492

Les douze pratiques du XP (1/3) Pratiques visant la programmation: 1.Administration de tests - Emphase unique sur la programmation avec tests initiaux, ainsi que sur les tests d'unité et d'acceptation automatisé 2.Normes de codage – Emphase sur la communication de par le code 3.Design simple – Faire la chose la plus simple qui fonctionne; enlever la complexité superflue immédiatement 4.Réusinage – Changements au système pour enlever la redondance, simplifier ou améliorer la communication 4 Automne 2014GEF492

Les douze pratiques du XP (2/3) Pratiques visant les équipes: 5.Programmation en pair – Tout code de production est développé par deux programmeurs, travaillant à une machine 6.Appropriation collective – N'importe qui peut changer le code, n'importe quand 7.Intégration continue – On construit le code plusieurs fois par jour, chaque fois qu'une tache est complétée 8.Semaine de travail de 40 heures – Les heures supplémentaires doivent être une exception, et non la norme 9.Métaphore – L'architecture découle du développement guider par un cadriciel simple, partagé entre tous, indiquant comment le système doit fonctionner 5 Automne 2014GEF492

Les douze pratiques du XP (3/3) Pratiques visant le processus: 10.Client sur place – Un client est inclut comme membre permanent de l'équipe 11.Versions de petite taille – On commence avec un système complet mais très simple (peut être sans fonctionnalité), et on utilise des cycles de version très court. 12. Jeux de planification – On combine les priorités avec les estimés techniques pour déterminer rapidement l'ampleur de la prochaine itération / version 6 Automne 2014GEF492

Organigramme XP 7 Automne 2014GEF492

Projet XP 8 Source: Automne 2014GEF492

Rôles XP – Que fait un... Client Répond aux questions Fait le design des tests d'acceptation Exécute les tests d'acceptation Guide l'itération Accepte la version Programmeurs Travail en équipe de deux Choisissent une tâche Test, code, ré-usine Intègre ou jette le code Testeur Travail avec le client pour implémenter / automatiser les tests d'acceptation 9 Automne 2014GEF492

Rôles XP – Que fait un... Gérant Ne doit pas : Établir les priorité  C'est le travail du client Assigner les tâches ou bien estimer l'effort –> C'est le travail des programmeurs Dicter l'horaire  C'est négocier durant le jeu de planification Doit: Gérer les problèmes Obtenir les ressources Aider l'équipe à bien s'entendre et maintenir le processus Faire rapport de progrès Organiser les réunions et le célébrations Pisteur Mesure le progrès de l'équipe Mesure le plan de version et les histoires complétées Mesure le plan d'itération par histoires / tâches complétées Mesure les tests d'acceptation 10 Automne 2014GEF492

Rôles XP – Que fait un... Entraîneur Se concentre sur le processus S’assure qu’il est suivit Surveille le progrès Agit comme expert- conseil mentor 11 Automne 2014GEF492

Autorité du client vs Programmeur Le client décide De la portée Qu'est-ce que le système doit faire Priorités Qu'elles sont les richesses fonctionnelles importantes Composition Qu'est-ce que le système doit faire dans chaque version pour être utile Dates de sorties de version Qu'elles sont les dates importantes (fin de la session!) Le programmeur décide Estimés horaires* Délai accordé pour implémenter les histoires et les tâches Risques techniques Expliquer les risques au client, qui décide ensuite comment procéder Processus Organisation de l'équipe Horaire d'itération Quelles histoires / tâches seront complétées pendant une itération 12 Automne 2014GEF492 * Radicalement différent de l'approche de développement logicielle traditionnelle

13 Automne 2014 GEF492 Phase d'exploration Client écrit les histoires (fonctionnalité essentielle testable du système Les programmeurs estiment les histoires Estimés en semaine-programmeur idéale (1 point) Le client doit décomposé l'histoire si l'estimé > 3 semaines "cloue" les histoires ne pouvant pas être estimée Jeux de planification de version XP Histoire: Choisit item à acheter Choisir un item à acheter du catalogue en le surlignant et le placant dans le panier d'épicierie prototype

Jeux de planification de version XP Phase de planification 1. Le client classe les histoires selon leur valeur De la plus haute à la plus basse OU haute / medium / basse 2. Programmeurs classent les histoires selon le risque haut / medium / bas 3. Programmeurs déclarent la vélocité de l'équipe # de points d'histoire par itération Un bon estimé est 1/3 de point d'histoire par programmeur par semaine 4. Client choisit la portée Choisit les histoires pour la version Effort total ≈ # total de points / vélocité La première version devrait exercer le système de bout en bout, même si il y a peut de fonctionalité 14 Automne 2014GEF492

Programmer en XP De façon incrémentale La programmation est faite selon des cycles très serrés; quelques lignes de code ou une méthode à la fois (moins d'une classe) Tests avant tout * Les tests d'unité automatisé sont créés avant le code qui sera créé On exécute le test, et on observe l'échec du système! Designs simples (FLCLPSQF) Faire la chose la plus simple qui fonctionne On complète seulement assez de code pour passer le test Test – codage - réusinage On répète le processus pour ajouter de petit morceaux de fonctionnalité, testant toujours d'abord On réusine le design tout au long, et on test encore 15 Automne 2014GEF492 Les tests continuels sont une bonne chose!

Réusinage Un terme, attribué à Martin Fowler, voulant dire: "Améliorer le design de code existant" Le “code pue” ou “anti-formes”: classes / méthodes trop longues, Trop / pas assez de fonctionnalité Manque / mauvaise utilisation d'héritage Duplication de code … Sans l'automatisation de test d'unité, le réusinage continuel serait dangereux ou même impossible On doit conserver la philosophie du test avant tout, ou la méthodologie XP ne fonctionnera pas! 16 Automne 2014GEF492 Le design continuel est une bonne chose!

La question se pose: “Qu'est-ce qui est du Design?” Voir la page unique sur le design, Chap 10 de votre texte XP Automne 2014GEF492 17

Programmation en pair Tout le code de production est codé en pair Ceci est une partie inhérente et essentielle du XP Qu'est-ce que la programmation en pair Deux programmeurs partagent un seul ordinateur pendant une session Un programmeur tape/design de façon tactique, alors que l'autre design de façon stratégique; on change souvent de rôles Avantages de la programmation en pair Hausse de qualité Hausse de productivité (n'est pas évident!) Entraînement mutuel constant La programmation en pair n'est pas évidente – il faut du temps pous s'y habituer! 18 Automne 2014GEF492 L'inspection continuelle est une bonne chose!

Aperçu du développement XP 19 Automne 2014GEF492

20 Automne 2014GEF492

Sommaire 21 Automne 2014GEF492

22 Automne 2014GEF492

Références supplémentaires Kent Beck. eXtreme Programming eXplained - Embrace Change. Addison Wesley, ISBN Extreme Programming: A gentle introduction Automne 2014GEF492

PROCESSUS DE CYCLE DE VIE CONVENTIONNELS VS. PROCESSUS MODERNE Prochaine séance: 24 Automne 2014GEF492