Extreme Programming

Excilys - ENSTA 2019

Bastien Deroo - Gaëtan Puget

https://slides.com/gpuget/presentation-xp/live

Agenda

  • 06/12 : Cours & user stories
  • 13/12 (matin) : TP - Planification et sprint 1 
  • 13/12 (a. midi) : TP - Réévaluation et sprint 2

Evaluations sur les TP et la participation

Introduction

Le cycle en V

Quel est le problème ?

Pourquoi XP ?

  • Les besoins du client sont affinés pendant le projet
    • Adapté aux changements
  • Impliquer le client pour assurer sa satisfaction
    • Il a une meilleure visibilité
    • Mise en production régulière

Projet Initial

  • Kent Beck, Ward Cunningham, Ron Jeffries
  • Projet "C3", mise à jour du système de paie chez Chrysler (1996)

Formalisation

  • Extreme Programming Explained (1999)
  • Extreme Programming Installed (2001)
  • Plateforme collaborative Wiki Wiki Web
  • Adopté par l'industrie (IBM, Total Gas Elec)

Objectifs

  • Projet orienté produit client
  • Résistance au changement
  • Réduction des coûts
  • Qualité
  • Maîtrise des délais et de la satisfaction

Théorie

Les valeurs

  • Communication
  • Simplicité
  • Feedback
  • Courage
  • Respect

Communication

Communication

  • Entre toutes les parties prenantes
  • Transparence
  • Contact humain
  • Communication directe / intense

Simplicité

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 unitaires et fonctionnels automatiques
  • Itérations courtes - Livraisons fréquentes
  • Maîtrise des flux
  • Meilleur pilotage

Courage

Courage

  • Être honnête sur l'état du projet
  • Accepter le changement
  • Accepter de jeter et recommencer

Rappel : les acteurs

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

Des valeurs aux pratiques

Pratiques collaboratives

  • Métaphores et user stories
  • Conventions de codage
  • Propriété collective du code
  • Travail en binôme
  • Intégration continue

Métaphores

  • Faciliter la compréhension
  • Utilisations d'analogies et champs lexicaux
    • Amélioration de la communication
    • Aide au développement de l'architecture
  • Média de communication / outil de vulgarisation

Métaphores ?

  • Avantages
    • Simplification domaine métier
    • Prétexte à communiquer => pas d'ambiguïtés
    • Association d'idées
  • Inconvénients
    • Pratique controversée, peu documentée

User stories

  • Décrit un cas d'utilisation une fonctionnalité
    • Identifiant
    • Description : en tant que...(qui ?) je peux/veux...(quoi ?) pour...(pourquoi ?)
    • Valeur business : estimation client convertible en €
    • Estimation de coût ré-évaluable

User Stories : INVEST

  • I : Independent
  • N : Negotiable
  • V : Valuable
  • E : Estimable
  • S : Small (Sized appropriately)
  • T : Testable

Conventions de codage

Conventions de codage ?

  • Bonnes pratiques
  • Facilite les comparaisons
  • Facilite la maintenance
  • Uniformise le code

Conventions de codage

  • Règles de codage
  • S'applique aux éléments variables
  • Nommage, indentation, architecture

Propriété collective du code

  • Responsabilité partagée
  • Connaissance de l'ensemble du code
  • Meilleure utilisation des modules
  • Refactoring facilité
  • Diminution des impacts de turn over

Travail en binôme

  • Pilote : accès clavier, explique ce qu'il fait
  • Copilote : assiste et suggère des options
  • Responsabilité commune de la qualité
  • Roulement des rôles et des paires
  • Prévoir des fenêtres de travail en solitaire

Travail en binôme ?

  • Avantages
    • Diffusion de la connaissance
    • Amélioration de la communication
  • Inconvénients
    • Difficile à faire accepter
    • Besoin de proximité géographique
    • Problème d'affinités et de bruits

Intégration continue

  • Intégration au moins une fois par jour
  • Précédée par des tests et un build

Intégration continue ?

  • Avantages
    • Meilleure visibilité
    • Facilite la résolution des anomalies
  • Inconvénients
    • Mise en place de la structure
    • Acceptation par l'équipe

TP #1 : User stories

Exemple

  • Réalisation d'une application pour jouer aux cartes
    • User Stories INVEST
Id En tant que... Je peux... Pour... Valeur métier O(n)
1 joueur voir mes cartes décider d'une action 100 +++
2 spectateur consulter les cartes des joueurs suivre le jeu 60 +

Règles du bowling

  • Une partie s'effectue sur 10 tours.
  • L'objectif est de faire tomber via les lancers d'une boule, les 10 quilles sur le terrain.
  • 9 tours se déroulent avec 1 à 2 lancers (un seul lancer si celui-ci est un strike).
  • Le dernier tour donne la possibilité d'un troisième lancer si le joueur fait un strike ou un spare.
  • Le score total d'un joueur est la somme des scores de chacun de ses lancers.
  • Pour calculer le score d'un tour, on peut avoir besoin d'une référence sur les lancers des tours suivants (spare et strike).

Pratiques de pilotage

  • Planning Poker
  • Livraison fréquentes
  • Rythme soutenable
  • Client sur site : équipe globale
  • Tests d'acceptation

Planning Poker

  • Estimation de la vélocité de l'équipe
  • Ouvrir la discussion
  • Estimer le coût des user stories
  • Préciser les user stories

Livraisons fréquentes

Rythme soutenable

  • Rester réaliste sur le contenu du sprint
  • Alterner périodes de tension et périodes de détente

Client sur site

  • Impliquer le client
  • Membre décideur de l'équipe
  • Fixe les priorités
  • Définit les exigences
  • Valide les avancées

Equipe globale

  • Pluridisciplinaire :
    • Développeurs
    • Concepteurs
    • Designers
    • Client
  • Appropriation, implication, appartenance

Tests d'acceptation

  • Effectués par le client sur site
  • Valide les avancées

TP #2 : Planning Poker

...Bowliwood...

  • Estimation en heures de binôme idéales
    • (échelle : 0, 0.5, 1, 2, 4, 8)
    • Parcours par ordre de priorité décroissant
  • Estimation de la vélocité de l'équipe
  • Deux itérations de 3,5 heures
  • Environnement de développement déjà installé

TP #2 : Intégration Continue

...Bowliwood...

  • Mise en place de l'intégration continue
    • Fork du répertoire formationXP depuis github
    • Configuration de Jenkins
    • Vérifier que le build ne passe pas, push
    • Corriger le test, vérifier que le build passe, push

Pratiques de développement

  • Conception simple
  • Test Driven Development
  • Refactoring

Conception simple

  • KISS
  • YAGNI

Test Driven Development

  • Spécification par les tests
  • Conception par les tests
  • Validation par les tests
  • Documentation par les tests

Refactoring

  • Nettoyer le code
  • Faire passer les tests
  • Changer l'implémentation mais pas le comportement
  • Restructurer en petites étapes

How To TDD

TP #3 : TDD

https://github.com/gpuget/ExtremePrograming

Junit

Hint 1: Read user input

/**************** Java 7 ***************/

try {
    BufferedReader br = new BufferedReader(new InputStreamReader(System.in))

    // Read string
    String s = br.readLine();
    
    // Read integer
    int i = Integer.parseInt(br.readLine());
} catch (IOException) {
    // Error message or clean exit or fallback on menu
} finally {
    br.close();
}

/**************** Java 8 ****************/

// Automatic close
try(BufferedReader br = new BufferedReader(new InputStreamReader(System.in))) {
    // Read string
    String s = br.readLine();
    
    // Read integer
    int i = Integer.parseInt(br.readLine());
}

Hint 2: How to commit

Hint 3: How to fetch

Hint 4: Print and replace current console line

// Use print instead of println
System.out.print("Current player : John\n");

// This replaces John with Paul
System.out.print("\rCurrent player : Paul\n");

Liens

Made with Slides.com