Extreme Programming

Oxyl - ENSTA

2022/2023

Gaëtan Puget

gpuget@oxyl.fr

https://slides.com/gpuget/extreme-programming/live

https://github.com/gpuget/ExtremeProgramming

Programme

• 17/01 : Cours et planning 

• 24/01 : Sprint 1

• 31/01 : Démo / Rétro 

• 07/02 : Sprint 2

Introduction

Les origines de l'XP

Cycle en V

Cycle en V

• Temps entre l'analyse du besoin et la recette
• Changement de besoin
• Beaucoup de travail peut-être "pour rien"
• Ségrégation MOA/MOE
• 80% projets sont en retard

Pourquoi l'XP ?

Pourquoi l'XP ?

• Les besoins sont affinés tout au long du projet​​​​​

  • ​Adapté aux changements

• Le client est directement impliqué

  • Meilleure visibilité

  • Mise en production régulière

Historique

• Projet C3, mise à jour du système de paie chez Chrysler (1996)
• Kent Beck, Ward Cunningham et Ron Jeffries
  • Signataires du Manifest Agile en 2001
  • Beck, pratique du TDD et JUnit
  • Cunningham, créateur du concept de wiki
  • Jeffries, ...

Formalisation

• Extreme Programming Explained: Embrace Change (Beck, 1999)
• Extreme Programming Installed (Jeffries, 2001)
• Extreme Programming Refactored: The Case Against XP (Stephens & Rosenberg, 2003)

Objectifs

• Projet orienté produit client
• Résistance aux changements
• Qualité
• Réduction des coûts (moins de bugs, moins de travail inutile)
• Maîtrise des délais et de la satisfaction

Théorie

Qu'est-ce que l'XP ?

Valeurs de l'XP

• Communication
• Simplicité
• Feedback
• Courage
• Respect

Communication

Communication

• Transparence
• Contact humain
• Communication directe / intense
• Entre toutes les parties prenantes
  • Client, managers, devs, etc.

Simplicité

Simplicité

• KISS (Keep It Simple, Stupid)
• YAGNI (You Ain't Gonna Need It)
• Ne pas anticiper
• Arriver rapidement au résultat

Feedback

Feedback

• Tests unitiares (fonctionnement du code)
• Tests fonctionnels (avancement du produit)
• Livraison fréquentes (itérations courtes)
• Meilleur pilotage

Courage

Courage

• Être honnête avec soi-même et ses collègues
• Être honnête sur l'état du projet
• Accepter le changement
• Accepter de jeter et recommencer

Respect

Respect

• Respect des autres
  • Communication
  • Pratiques (compilation, tests)
• Respect de soi-même
  • Ne pas tout accepter
  • Respecter ses engagements

Pratiques collaboratives

Pratiques collaboratives

• Utilisation de métaphores
• Conventions de nommage/code
• Appropriation collective du code
• Intégration continue

Métaphores

• Médium de communication

• Outil de vulgarisation

• Utilisations d'analogies et champs lexicaux

  • Améliore la communication

  • Aide au développement

Métaphores

• Avantages

  • Simplification du domaine métier

  • Reformulation et précision

  • Association d'idées

• Inconvénients

  • Pratique controversée

  • Peu documentée

Conventions de code

Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.

Martin Golding

Conventions de code

• Bonnes pratiques
• Uniformisation du code
• Maintenance facile (techniquement)
• Comparaison immédiate

Nommage des variables, documentation, indentation, architecture, etc.

Propritété collective du code

• Responsabilité partagée
• Connaissance globale (tout le projet)
• Connaissance partagée (par tout le monde)
• Maintenance facile (théoriquement)

Intégration continue

• Incorporation du nouveau code de manière systématique et automatique
  • Vérification de la compilation
  • Vérification des conventions de code
  • Vérification des tests
  • Notification aux développeurs

Intégration continue

Intégration continue

• Avantages

  • Meilleure visibilité

  • Résolution des anomalies facilité (rapide et ciblé)

• Inconvénients

  • Acceptation par l'équipe

  • Mise en place de l'architecture

TP1 - User Stories

User stories

• Décrire un usecase une fonctionnalité

• Identifiant (unique)

• Description

  • En tant que... (qui ?)

  • Je peux/veux... (quoi ?)

  • Pour/afin de... (pourquoi ?)

• Valeur métier (estimation client)

• Critères d'acceptation

INVEST

• Independant
• Negociable
• Valuable

• Estimable
• Small
• Testable

Consignes

• Former des groupes de 4-5 personnes
• Choisir un sujet
• Créer un projet github
• Créer une vingtaine de user stories
  • brainstorming + regroupement
  • INVEST
  • valeur métier + critères d'acceptation

Exemple

User stories

Exemple

Critères d'acceptation

Sujets au choix

• Casse-brique
• Pong
• Tetris
• Snake
• Bataille navale
• Morpion
• 2048
• Bowling (historiquement)

Pratiques de pilotage

Pratiques de pilotage

• Client sur site
• Planning Poker
• Rythme soutenable
• Petites livraisons
• Tests de fonctionnels

Rappels : acteurs agiles

• Le client
• Le "Product Owner"
• Le "Scrum Master"
• Le reste de l'équipe (multidisciplinaire)

Client sur site

Client sur site

• Prise de décision
• Définition des exigences
• Définition des priorités
• Validation des avancées

Planning Poker

Planning Poker

• Estimer le coût des tâches (complexité ou temps)
• Préciser les tâches
• Ouvrir la discussion
• Estimer la vélocité (ce que pourra produire l'équipe)

Rythme soutenable

Rythme soutenable

• Rester réaliste sur le contenu de l'itération

• Alterner les périodes

  • de tension et de détente

  • nouvelles fonctionnalités et correctifs

Livraisons fréquentes

Charges répartie et risques amoindris

Tests d'acceptation

Tests d'acceptation

• Définis par des critères d'acceptation
• Effectués par le client
• Validés (ou non) par le client

TP2 - Planning Poker

Consignes

• Reprendre les user stories du TP1
• Faire des estimations (complexité)
• Répartir les tâches en 2 itérations (~ 2 x 3h30)
  • Selon la valeur métier (priorité)
  • Selon vos estimations
  • Selon le livrable

Prendre en considération que vous allez coder en Java en binôme et effectuer des tests

Pratiques de développmeent

Pratiques de développement

• Programmation en binôme
• Conception simple
• Tests unitaires
• Refactoring

Programmation en binôme

Programmation en binôme

• Pilote : accès clavier, explique ce qu'il fait
• Co-pilote : assite, suggère des options
• Responsabilité communes de la qualité
• Complémentarité et divergeance
• Roulement des rôles et des paires
• Roulement des paires

Programmation en binôme

• Avantages

  • Diffusion des connaissances

  • Amélioration de la communication

• Inconvénients

  • Difficile à faire accepter

  • Besoin de proximité

  • Problème d'affinités et de bruits

Conception simple

Conception simple

• KISS

  • Plus compréhensible

  • Plus maintenable

  • Qualitatif

• YAGNI

  • Pas de perte de temps

  • Moins de chose (maintenance, documentation, complexité)

  • Quantitatif

Tests unitaires

Tests unitaires

• Guide de développement
• Assurance
• Retour immédiat
• Description de l'application

Refactoring

Refactoring

• Nettoyer le code
• Faire passer les tests
• Changer l'implémentation (mais pas le comportement)
• Restructurer par étapes

TP3 - TDD

Test Driven Development

• Écrire un test
• Faire échouer le test
• Faire le minimum pour faire passer le test
• Faire des améliorations sans changer le comportement
• Recommencer

Git

• Branche master
• Branche dev
• Branches feature
• Au moins 2 contributeurs
• Beaucoup de commit !

Si je fais une diapo dessus, c'est important ;)

Consignes

• Séance 1
  • Réaliser les tâches de l'itération 1
  • Faire une livraison
• Séance 2
  • Réévaluer les tâches de l'itération 2
  • Réaliser les tâches prévues
  • Faire une seconde livraison