Présentation XP

Excilys - ENSTA 2016

Zacaria Chtatar - Lucas Coatanlem

Plan

  • Historique
  • Objectifs
  • Théorie

Projet Initial

  • Kent Beck, Ward Cunningham, Ron Jeffries
  • 1996 : Projet "C3", mise à jour du système de paie chez Chrysler (10 000 personnes)
  • Nouvelle méthode agile => succès en 1 an

Formalisation

  • Premier ouvrage sur la "méthode XP"
  • Plateforme collaborative Wiki Wiki Web
  • Adopté par l'industrie (IBM, Total Gas Elec)

Objectifs

Objectifs

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

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

Théorie

Les valeurs

  • Communication
  • Simplicité
  • Feedback
  • Courage
  • (Respect)

Les valeurs

Communication

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

Les valeurs

Simplicité

  • Ne pas anticiper
  • KISS, YAGNI
  • Livraisons utilisables

Les valeurs

Feedback

  • Tests unitaires et fonctionnels automatiques
  • Itérations courtes - Livraisons fréquentes
  • Maîtrise des flux
  • Meilleur pilotage

Les valeurs

Courage

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

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
    • Jeux intellectuels & 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...(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

User Stories : KANO

Conventions de codage

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

Conventions de codage ?

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

Il faut s'y tenir !

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

Bowliwood...

  • Réalisation d'une application pour jouer au Bowling
    • User Stories
      • INVEST, KANO
Id En tant que... Je peux... Pour... Valeur métier O(n)
1 joueur préciser le nombre de joueur et les nommer démarrer une partie 100 +++
2 spectateur consulter les scores avoir des infos 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

Junit

Liens

Made with Slides.com