Extreme Programming
Excilys - ENSTA 2017
Gaëtan Puget - Zacaria Chtatar
https://slides.com/zacariachtatar/presentation-xp/live
Plan
- 8/12 : Introduction + pratiques collaboratives + TP 1
- 15/12 a.m. : Pratiques de pilotage + TP 2
- 15/12 p.m. : Pratiques de développement + TP 3
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
- 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
- Projet orienté
produitclient - 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)
Les valeurs
Communication
- Entre toutes les parties prenantes
- Transparence
- Contact humain
- Communication directe / intense
Les valeurs
Simplicité
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
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'utilisationune 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, le jeu de cartes
Exemple
- Réalisation d'une application pour jouer au Poker
- 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
- Framework de tests
- @Test
- Liste des méthodes disponibles
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
- formation.agile@excilys.com
- Permalien du cours
Présentation XP
By Zacaria Chtatar
Présentation XP
- 203