Vous êtes sur la page 1sur 20

Plan

Introduction à l’eXtreme Programming •! Introduction


et au développement agile •! Equipe XP
G. Picard
•! Processus XP
SMA/G2I/ENS Mines Saint-Etienne •! Pratiques XP
gauthier.picard@emse.fr •! Autres considérations
Septembre 2009

Source :
eXtreme Programming Ou les bienfaits d’un développement « Agile » par
Kévin Ottens, KDE Core Developer

Plan La préhistoire : Influences (1/3)

•! Introduction •! Culture SmallTalk


–! 198x : Kent Beck et Ward Cunningham travaillent chez Tektronix
–! Un peu d’histoire... –! Elements clef de cette culture :
–! Motivations •! Développement en binôme
•! Refactoring
–! Valeurs & principes •! Changements rapides

•! Equipe XP •!
•!
Interaction permanente avec le client
Intégration continue
•! Processus XP •! Développement itératif
•! Tests permanents
•! Pratiques XP •! « Episodes »
•! Autres considérations –! 1986-1996 : Kent Beck et Ward Cunningham développent un
ensemble de bonnes pratiques
–! Support dans le language Episodes de Ward Cunningham

3 4
La préhistoire : Influences (2/3) La préhistoire : Influences (3/3)
•! Refactoring •! Design Patterns
–! 1989-1992 : William F. Opdyke, "Refactoring Object-Oriented –! Idée reprise de l’architecture, plus particulièrement de Christopher
Frameworks". PhD Thesis Alexander
–! 1995-1996 : Kent Beck, "Smalltalk Best Practices Patterns" –! Kent Beck et Ward Cunningham ont appliqué le concept de patrons
–! 1999 : Mar tin Fowler, "Refactoring: Improving the Design of Existing au logiciel depuis 1987
Code" –! 1995 : Publication de Design Patterns, par
•! Test-Driven Development •! Erich Gamma
•! Richard Helm
–! Dérivé des pratiques de refactoring
•! Ralph Johnson
–! Premier article publié par Kent Beck à propos de SmallUnit
•! John Vlissides
–! 1997 : Création de JUnit par Kent Beck et Erich Gamma

5 6

Les débuts (1/2) Les débuts (2/2)


•! Projet C3 (Chrysler, 1996) : Naissance du processus •! Evolution et gain de popularité
–! Intervention de Kent Beck pour améliorer les performances –! Septembre 1999 : "Extreme Programming Explained" par Kent Beck
–! Identification de maux plus profonds –! Processus presque identique à celui appliqué sur C3
–! La direction lui confie l’équipe pour récrire le logiciel –! Intégration du processus Scrum pour la gestion de projet
–! Mise au point des pratiques XP avec Ron Jeffries –! Décembre 1999 : 1e "XpImmersion" à ObjectMentor
•! Correspond à la somme des influences vues précédemment –! 31 Décembre 1999 : Création du groupe de discussion XP sur
•! Octobre 1998 : Article dans Distributed Computing magazine sur C3 et Yahoo!
XP –! Juin 2000 : 1e conférence internationale sur XP
•! De l’utilisation du Wiki Wiki Web –! Septembre 2000 : "Extreme Programming Installed" écrit entre autre
–! Ward Cunningham a mis au point ce site collaboratif par Ron Jeffries
–! Utilisé par la communauté XP pour affiner et discuter le processus –! Juillet 2001 : Première conférence "XpUniverse"

7 8
Le Manifeste Agile Mythe des phases
•! Réunion organisée par Kent Beck en Février 2001 •! Processus séquentiels
•! 17 personnalités, dont les créateurs de Crystal, Scrum, –! La plupart dérivés du cycle en V
Adaptive Software Development, etc. –! Variantes... intégrant parfois des sous-cycles itératifs
http://www.agilemanifesto.org/
Nous cherchons de meilleures manières pour développer des logiciels en 1.! Cahier des charges
aidant les autres et en développant nous mêmes. À travers ce travail 2.! Document de spécifications
nous en sommes venus à valoriser : 3.! Document de conception générale
Personnes et interaction plutôt que processus et outils 4.! Document de conception détaillée
Logiciel fonctionnel plutôt que documentation complète 5.! Plans de tests
6.! …
Collaboration avec le client plutôt que négociation de contrat
7.! Et l’application ?
Réagir au changement plutôt que suivre un plan
En fait, bien que les éléments de droite soient importants, nous pensons
que les éléments de gauche le sont encore plus.
9 10

Mythe des phases Utopie des spécifications immuables


•! Constats •! Faits
–! 1994 : Rapport CHAOS (étude sur 8000 projets) –! Sources principales de problèmes dans les spécifications :
•! 16% finalisés dans les temps et le budget prévus •! Erreurs
•! 32% interrompus en cours de route •! Oublis
–! Diagnostic courant des dérapages : •! Changements
•! Spécifications ambitieuses et Conception poussée –! Définir un logiciel a priori est un exercice difficile
•! Puis, enlisement de la construction –! Sauf dans le cas :
–! Remise en cause de choix initiaux •! D’applications extrêmement simples
–! Mise à mal de la conception proposée
•! De rares contextes connus et maitrisés
–! Effet Tunnel –! Le client a du mal à imaginer ce que sera l’application
–! Le processus correspond il aux besoins du projet ?
•! Conséquences
–! Remises en question des spécifications
–! Risques pour la conception liés au changement

11 12
Valeurs XP (1/2) Valeurs XP (2/2)
•! Communication •! Retour d’information (Feedback)
–! Développement = Effort collectif de création –! Boucles de feedback pour réduire les risques
•! Avoir une vision commune et pouvoir se synchroniser •! Connaître l’état du projet
!!Qualité de la communication •! Rectifier le tir si nécessaire
–! Communication directe et le contact humain –! Facteur de qualité
•! Faiblesse pour la traçabilité et la structuration •! Acquisition d’expérience
•! Augmentation de la réactivité •! Amélioration constante du travail
–! Communication écrite présente, en général par du code •! Courage
•! Simplicité –! Se lancer dans un projet non entièrement spécifié
–! « La chose la plus simple qui puisse marcher » –! Accepter de remanier une portion de code devenue complexe
–! Simple ! Simpliste –! Appliquer les valeurs de feedback et de communication
–! Eviter la complexité inutile dans le code •! Accepter de montrer ses propres limites
–! Toute duplication doit être éliminée •! Maintenir une transparence complète

13 14

Principes XP Plan
•! Le client (maîtrise d'ouvrage) pilote lui-même le projet, et ce de très
près grâce à des cycles itératifs extrêmement courts (1 ou 2 semaines)
•! Introduction
•! L'équipe livre très tôt dans le projet une première version du •! Equipe et rôles XP
logiciel, et les livraisons de nouvelles versions s'enchaînent ensuite à un
rythme soutenu pour obtenir un feedback maximal sur l'avancement des –! Technique : programmeur
développements
–! Domaine : client, testeur
•! L'équipe s'organise elle-même pour atteindre ses objectifs, en
favorisant une collaboration maximale entre ses membres –! Organisationnel : tracker, manager, coach
•! L'équipe met en place des tests automatiques pour toutes les
fonctionnalités qu'elle développe, ce qui garantit au produit un niveau •! Processus XP
de robustesse très élevé
•! Les développeurs améliorent sans cesse la structure interne du
•! Pratiques XP
logiciel pour que les évolutions y restent faciles et rapides
•! Autres considérations

15 16
Programmeur (1/3) Programmeur (2/3)
•! Deux hypothèses dans XP pour justifier l’importance du •! Conception pour un codage durable
code –! Elle est très importante!
–! En génie logiciel, l’activité correspondant à la fabrication est la –! Elle a un but différent :
compilation, pas la programmation •! Pas montrer ce que l’on a codé
–! Code clair, structuré et simple modifié autant de fois que nécessaire •! Pas fournir des documents remplis de schémas
pour qu’il soit compréhensible et non redondant est la meilleure •! Garantir le long terme
forme de conception –! Eviter ainsi :
•! Tests et proximité du client •! Fragilité (modification " régression)
–! Tests (cf. Feedback) •! Rigidité (petite modification " nombreuses modifications)
•! Eviter les décalages entre ce que l’on veut coder et le comportement •! Immobilité (factoriser " tout casser)
réel •! Interventions sur la conception
–! Ce qui n’est pas testé n’existe pas (cf. Courage) –! Collectivement lors des séances de planification
–! Ecouter le client (cf. Communication) –! Lors de l’écriture des tests unitaires
•! Lui seul sait comment le logiciel doit fonctionner
–! Par le remaniement (refactoring)

17 18

Programmeur (3/3) Client (1/3)


•! Responsabilisation •! Pratiques XP •! Qui est-il ?
–! Retour du programmeur –! Programmation en binôme –! Pas nécessairement le client contractuel
comme rôle central –! Tests unitaires •! Assistant à maîtrise d’ouvrage
–! A la fois : codeur, testeur, –! Conception simple •! Représentant des utilisateurs
concepteur et analyste –! Remaniement –! A défaut quelqu’un pour agir comme client « artificiel »
–! Apprentissage " Qualités –! Responsabilité collective du •! Chef de projet
humaines nécessaires code •! Ingénieur chargé des spécifications
–! XP : Ecole de l’excellence –! Règles de codage •! Client sur site et feedback
–! Responsabilisés pour donner –! Intégration continue –! Intégré à l’équipe de développement
le meilleur d’eux même
–! Rythme durable •! Plus de cahier des charges vague ou incompréhensible
ex. : estimation des charges et
•! Plus de démo truquée
délais
–! Explique se qu’il souhaite aux développeurs
" Vision plus rapide du résultat
" Prise de conscience en cas d’erreur

19 20
Client (2/3) Client (3/3)
•! Scénarios clients •! Tests de recette •! Pratiques XP
–! Description informelle d’une fonctionnalité ou d’une interaction avec –! But : préciser les contours des –! Planification itérative
l’utilisateur scénarios •! Rédaction des scénarios
–! Le plus simple possible –! Données concrètes levant les clients
ambiguïtés •! Séances de planification
•! Démarrage du projet
–! Preuve que le système fait ce –! Tests de recette
–! Des scénarios initiaux sont dégagés et présentés
qu’il demandait –! Intégration continue
–! Ils sont classés par priorité et répartis en itérations
–! A chaque fin d’itération tous –! Rythme durable
•! A chaque itération... les tests de recette doivent
–! Grâce au feedback introduit (logiciel fonctionnel) : passer avec succès
•! Il peut revoir le contenu des itérations
•! Modifier ses scénarios
–! Il est garant des fonctionnalités du logiciel

21 22

Testeur Tracker (1/2)


•! Le bras droit du client •! Compétences requises •! Missions
–! Définit et automatise les tests –! Programmeur hétéroclite –! Suivre les tâches en cours d’itération
de recette (maîtriser l’outillage de test) –! Interroger les programmeurs
•! Conseille le client sur la –! Rigoureux et intègre •! Savoir où ils en sont
testabilité d’une fonctionnalité
•! Utilisation d’outils différents
•! Pratiques XP •! Ne pas les mettre sur des charbons ardents
•! Attention à ne pas dériver en discussion technique
pour scripter –! Suivi des tests (planification
itérative) –! Détecter les problèmes avant qu’il ne soit trop tard
–! Garant du sentiment de
–! Tests de recette •! Révélateur
réussite sur le projet
•! Pas de prise d’initiative
•! Test fonctionnel réussi " –! Intégration continue
Progression –! Il fait en sorte que la tâche de 3 jours en prenne 4 et non 6
–! Rythme durable
•! Communiquer pour motiver
(graphique de progression...)

23 24
Tracker (2/2) Manager
•! Qui est-il ? •! Position dans l’organisation
–! Pas un supérieur hiérarchique –! Supérieur hiérarchique des programmeurs
–! Quelqu’un a qui on peut se confier –! Ne fait pas partie intégrante de l’équipe
–! De préférence pas un programmeur, mais quelqu’un d’extérieur –! Chef du service auquel appartient l’équipe
•! Pour éviter les discussions techniques –! Chef de projet global (dans le cadre d’un sous-projet)
•! A défaut, ce rôle peut tourner entre les programmeurs à chaque itération
•! Responsabilités
•! Pratiques XP –! Il s’occupe matériellement de l’équipe
–! Planification itérative –! Il demande des comptes (sur les engagements pris)
–! Interface avec l’extérieur (dans le cadre d’un sous-projet)
•! Pratiques XP
–! Scénarios client
–! Planification itérative
–! Rythme durable

25 26

Coach Répartitions des rôles


•! Garant du processus •! Plusieurs rôles pour une personne
–! Il réunit tout les autres rôles –! Attention aux combinaisons possibles
–! Vérifie que chaque rôle est respecté –! Toutefois, pas de règle absolue
–! Ses buts ultimes : –! S’assurer qu’une cumulation ne pousse pas à sacrifier une
•! Equipe autonome composante importante d’un rôle
•! Chaque programmeur est en amélioration continue •! Plusieurs personnes pour un rôle
–! Ses qualités –! Programmeur, le plus grand nombre
•! Expert de la méthode XP
–! Tracker, une seule personne... à un moment donné
•! Expert technique
–! Coach, une personne unique
•! Programmeur chevronné
–! Manager, une personne unique
•! Architecte
•! Pédagogue et sensible –! Client+Testeur, d’une personne à une équipe
•! Sang-froid
•! Pratiques XP
–! Toutes !
27 28
Compatibilité des rôles Précautions
•! Comportements contre-indiqués

Programmateur
–! S’attribuer les mérites ou rejeter la faute sur les autres

Manager
–! Un codeur (même très compétent)

Tracker
Testeur

Coach
Client
•! faisant des choses que personne ne comprend
•! refusant de travailler avec quelqu’un de moins compétent
Programmateur ! ! ! ! ! –! Chercher à se rendre indispensable
Client ! " ! ! !
•! Eviter la spécialisation
Testeur ! " ! ! !
–! Tendance naturelle à la constitution de sous-groupes
Tracker ! ! ! ! ! •! Avec XP, pas de conséquences tant que le groupe est petit
Manager ! ! ! ! •! Envisager des mécanismes de rotation pour les binômes
Coach ! ! ! ! ! –! Cas particulier du consultant
1.!Le consultant est appelé pour un problème précis
« " » bonne combinaison
2.!Il travaille toujours accompagné par un programmeur
« ! » envisageable mais risquée
« ! » mauvaise combinaison 3.!L’équipe souhaitera probablement refaire le travail

29 30

Plan Cycle de vie XP

•! Introduction
•! Equipe et rôles XP
•! Processus XP
•! Pratiques XP
•! Autres considérations

31 32
Itération Développement

33 34

Le code appartient à tous

35 36
Plan Règles lors du cycle de vie XP
http://www.extremeprogramming.org/rules.html
•! Planning •! Coding
•! Introduction –! User stories are written. –! The customer is always available.
–! Release planning creates the schedule. –! Code must be written to agreed
•! Equipe et rôles XP –! Make frequent small releases. standards.
–! Code the unit test first.
–! The Project Velocity is measured.
•! Processus XP –!
–!
The project is divided into iterations.
Iteration planning starts each iteration.
–! All production code is pair programmed.
–! Only one pair integrates code at a time.
–! Integrate often.
•! Pratiques XP –!
–!
Move people around.
A stand-up meeting starts each day. –! Use collective code ownership.
–! Fix XP when it breaks. –! Leave optimization till last.
–! Règles et pratiques •! Designing –! No overtime.
•! Testing
–! Programmation –!
–!
Simplicity.
Choose a system metaphor. –! All code must have unit tests.
–! All code must pass all unit tests before it
–! Collaboration –!
–!
Use CRC cards for design sessions.
Create spike solutions to reduce risk. –! can be released.
–! When a bug is found tests are created.
–! Gestion de projet –!
–!
No functionality is added early.
Refactor whenever and wherever –! Acceptance tests are run often and the
possible. score.
•! Autres considérations
37 38

Pratiques XP Pratiques XP
Développement piloté par les tests
Programmation Conception simple
Remaniement
Programmation en binôme
Responsabilité collective du code
Collaboration
Règles de codage
Intégration continue
Client sur site
Rythme durable
Gestion de projet
Livraisons fréquentes
Planification itérative

39 40
Développement piloté par les tests (1/3) Développement piloté par les tests (2/3)
•! Automatisation •! Tests Fonctionnels
–! Tests d’un logiciel sont généralement automatisables –! Dans le cas général, la recette permet de vérifier que :
–! Automatisation " moins de temps consacré aux tests •! Le logiciel n’a pas d’anomalie constatée
–! Temps nécessaire à l’automatisation plus long, mais... •! Les fonctionnalités livrées sont bien celles demandées
•! Moins de défauts dans le code –! Dans le cas XP :
•! Moins de régressions •! Tests de recettes spécifiés par le client
•! Tests fonctionnels écrits par le testeur
•! Ecrire les tests en premier
" Livraison possible lorsque tous les tests réussissent
–! Position a priori paradoxale, mais...
•! Elimination du dilemme habituel en fin de projet •! Test Unitaires
•! Code plus facilement testable –! Ecrits avant le code à tester
•! Moins d’enchevêtrement " Meilleure conception –! Plusieurs rôles :
–! Tests fonctionnels " Forme de spécification •! Rythmer la programmation (progression « d’alpiniste »)
–! Tests unitaires " Forme de conception détaillée •! Guider la conception
•! Documenter le code produit (cf. notion de « contrat »)

41 42

Développement piloté par les tests (3/3) Conception simple (1/2)


•! Test Unitaires (nouvelle implémentation) •! Eviter la spéculation
1.! Identifier une sous-partie du problème –! Conception = Investissement (en temps et/ou complexité)
2.! Ecrire un test indiquant si le problème est résolu •! Identifier toutes les classes ou modules dont sera constitué le système,
3.! Exécuter le test... qui doit échouer héritage...
•! Implémenter un système générique pour facilement implémenter chaque
4.! Ecrire le code fonctionnalité spécifique
5.! Exécuter le test pour vérifier que le code fonctionne correctement –! Cet investissement peut-être bénéfique...
•! Test Unitaires (modification de conception) •! Mais si on a mal « spéculé » ?
1.! Modifier le test concerné –! XP : Se concentrer sur une et une seule fonctionnalité
2.! Exécuter le test... qui doit échouer •! Obtenir la meilleure conception possible... ...
3.! Modifier le code –! sans aller au-delà
–! « Do the simplest thing that could possibly work »
4.! Exécuter le test pour vérifier que le code fonctionne correctement –! « You Aren’t Gonna Need It » (YAGNI)
•! Implémenter le strict nécessaire
–! Complètement et correctement
–! Tests unitaires compris
43 44
Conception simple (2/2) Remaniement (1/2)
•! Simplicité ! Facilité •! Définition
–! Le plus simple n’est pas forcément le plus facile « Procédé consistant à modifier un logiciel de telle façon que, sans
–! Par exemple, dupliquer le code d’une méthode pour avoir une altérer son comportement vu de l’extérieur, on en ait amélioré la
version légèrement modifiée est facile... structure interne »
•! Méthode ayant des anomalies " Rechercher toutes les variantes pour •! Transformations de code
les corriger
–! Martin Fowler en a répertorié plusieurs dizaines
–! Toutefois, ne pas oublier de progresser
–! Décrites avec grande précision
•! Règles de simplicité XP •! Présentation proche des « Design Patterns »
–! Tous les tests doivent être exécutés avec succès •! Beaucoup peuvent être appliqués mécaniquement
–! Chaque idée doit être exprimée clairement et isolément •! Certains IDE commencent même à en automatiser certains (i.e. Eclipse)
–! Tout doit être écrit une fois et une seule •! Exemples de résultats
–! Le nombre de classes, de méthodes et de lignes de code doit être –! Elimination du code dupliqué
minimal –! Séparation des idées
–! Elimination de code mort
45 46

Remaniement (2/2) Métaphores


•! Lien avec les tests •! Dans un projet classique
–! Chaque modification apportée par une transformation est minime –! On cherche à communiquer
–! Grâce aux tests on peut être certain qu’aucune erreur n’a été •! Sur ce que l’on attend du projet
introduite •! Sur ce que l’on a réalisé
–! On peut facilement revenir en arrière –! D’où un effort de rédaction non négligeable
–! Comme dans la nature : –! But : obtenir une vision commune
•! Chaque remaniement est une mutation isolée –! Souvent noyée dans une documentation trop détaillée
•! Les tests font office de sélection naturelle
•! XP se focalise sur la vue d’ensemble
•! Les mutations nocives sont éliminées
–! Conserver uniquement le strict nécessaire
•! La robustesse du code est accrue
–! Eviter la redondance
•! En général quelques pages suffisent
•! Utilisation de métaphores
–! Eviter le jargon technique
–! Utiliser des « images »

47 48
Programmation en binôme (1/3) Programmation en binôme (2/3)
•! Fonctionnement du binôme •! Répartition des tâches
–! Toujours deux développeurs devant une machine –! Chaque développeur est responsable de ses tâches
–! Pilote : Ecriture du code, manipulation des outils... –! Alors, à tout instant :
–! Co-Pilote : Relecture continue du code, propositions... •! Il travaille sur une de ses tâches
–! Dialogue permanent pour réaliser la tâche en cours •! Il aide quelqu’un d’autre à réaliser sa tâche
–! NB: Une tâche pourra être réalisée en plusieurs fois
•! Formation des binômes
–! Changement fréquent des binômes (plusieurs fois par jour) •! Une pratique « rentable » ?
–! Sélection libre : –! Un binôme est plus rapide sur une tâche donnée qu’un programmeur
•! On demande l’aide de quelqu’un d’autre seul
•! Il ne peut refuser ou seulement temporairement –! Amélioration de la qualité du code " Réduction du coût de
–! Exemples de critères de choix : maintenance
•! (Faire) Profiter de l’expérience –! Partage des connaissances, Cohésion d’équipe
•! Intérêt pour la tâche à réaliser

49 50

Programmation en binôme (3/3) Responsabilité collective du code (1/2)


•! Précautions •! Modèles actuels : Responsabilité individuelle
–! Rester clair : –! Chaque développeur évolue dans une partie réservée
•! Collaboration active et continue •! Nécessite de se mettre d’accord sur les interfaces
•! Pas « un qui code l’autre qui sur veille » •! Limite les interférences
–! Qualités humaines de l’équipe déterminantes •! Garantie une certaine autonomie
–! S’assurer que le co-pilote ne « décroche » pas –! Notion de « responsable » souvent entâchée de « faute »
–! Gérer les différences de niveau (pas de marginalisation) –! Séparation des connaissances
–! S’ouvrir sur le reste du groupe en cas de problème •! Duplication de code
–! Rester réaliste... •! Pas de progression dans les compétences
•! Il est difficile de fonctionner en binôme 100% du temps •! Modèles actuels : Absence de responsabilité
•! Espace de travail –! Code appartenant à toute l’équipe et à personne à la fois
–! Eviter le cloisonnement pour favoriser les échanges –! Tout le monde peut modifier l’application selon les besoins
–! Concept de « War Room » •! Développement opportuniste
•! Design « plat de spaghettis »

51 52
Responsabilité collective du code (2/2) Règles de codage
•! Modèle XP •! Pourquoi ?
–! Chaque binôme peut inter venir sur n’importe quelle partie –! Homogénéisation nécessaire (responsabilité collective)
–! Mais chacun est responsable de l’ensemble •! Prise en main plus rapide du code écrit par d’autres
–! Par ex. un binôme peut revoir une partie peu claire du code •! A définir avant le démarrage du projet
–! Fonctionne bien uniquement dans un cadre XP –! Parfois mal perçues, mais
•! Tests unitaires •! Adaptation assez rapide
•! Intégration continue •! Prise de conscience du travail en équipe
•! Remaniement –! Peut s’inscrire dans une démarche qualité
•! Règles de codage •! Aspects couverts
•! La fin des spécialistes? " Non! –! Présentation du code (indentation, espaces...)
–! Ils doivent devenir polyvalent –! Organisation des commentaires
–! Mais agissent comme consultant interne –! Règles de nommage (classes, méthodes, constantes...)
•! Mise en commun des connaissances –! Système de noms (vocabulaire commun, métaphore...)
•! Interlocuteurs privilégiés dans leur domaine –! Idiomes de codage (parcours de liste, singletons...)
53 54

Intégration continue Client sur site


•! Pourquoi éviter des périodes d’intégration? •! Notion d’équipe
–! Profiter immédiatement des efforts de chacun –! Client intégré à l’équipe de développement
–! Coût de l’intégration augmente très vite avec l’éloignement dans le –! Equipe
temps des intégrations successives !!Ensemble des développeurs
•! Fréquence d’intégration "classique" : 1/semaine =!« Whole Team » (client et programmeurs)
•! Fréquence XP : 1/jour à n/heure
•! Avantages
•! Méthode de travail : Gestion de versions –! Spécifications fonctionnelles généralement floues, ici :
–! Test Unitaires = Tests de non-régression •! Client disponible pour apporter ses compétences métier
–! Processus suivi : •! Maitrise d’ouvrage conservée par le client
1.!Récupération d’une copie locale –! Définition des tests de recette par le client
2.!Modification de la copie
•! Une pratique inaccessible ?
3.!Mise à jour de la copie locale lorsqu’elle passe les tests
–! Très difficile de trouver quelqu’un de suffisamment disponible
4.!Correction des éventuels problèmes
5.!Mise en dépôt de la copie locale lorsqu’elle passe les tests

55 56
Rythme durable Livraisons fréquentes (1/2)
•! Maintenir un niveau optimal •! Rythment le projet
–! Savoir travailler... mais aussi se reposer ! –! Livraisons régulières comme point de synchronisation
–! Beaucoup d’énergie nécessaire pour : –! Le client fixe ces dates, par exemple :
•! Trouver des solutions de conception simples •! Pour un projet de six ou sept mois
•! Ecrire du code propre •! On pourra espacer les livraisons d’environ un mois et demi
•! Penser à des tests unitaires •! La première livraison arrivant au bout de deux mois
•! Explorer avec son binôme les problèmes rencontrés –! La première livraison doit arriver le plus tôt possible
–! On peut faire des heures supplémentaires •! Dissiper d’éventuels malentendus
•! Sur une cour te période de temps •! Donner consistance au projet
•! Suivie d’une période de relâchement –! Les livraisons doivent être aussi proches que possible
•! Traiter les problèmes réels •! Pilotage précis du projet
–! Règle : « Pas d’heures sup’ deux semaines de suite » •! Donner des preuves de son avancement
•! Ne pas la respecter est le signe d’un problème plus profond
•! Plutôt le résoudre que le masquer par un sur plus de travail

57 58

Livraisons fréquentes (2/2) Planification itérative


•! Un « feedback » pour le client •! Rythme
–! Mieux cerner ses besoins –! Environ 2 ou 3 itérations entre deux livraisons
–! Etre rassuré sur l’avancement réel du projet –! Pour un projet de six ou sept mois
•! Un « feedback » pour l’équipe •! Itérations de deux semaines environ

–! Sentiment régulier de « travail fini » •! Séances de planification (« Planning Game »)


–! Confrontation du produit à un environnement réel –! Livraisons et itérations sont des cycles imbriqués
–! Deux niveaux de granularité pour le pilotage
•! Livraisons " Fonctionnalités
•! Itérations " Tâches à réaliser par les développeurs
–! Ces deux cycles sont découpés en trois phases
1.!Exploration, identifier le travail et estimer son coût
2.!Engagement, sélectionner le travail pour le cycle en cours
3.!Pilotage, contrôler la réalisation de ce qui est demandé

59 60
Planification itérative : Livraisons (1/3) Planification itérative : Livraisons (2/3)
•! Exploration (de plusieurs jours à quelques heures) •! Engagement (quelques heures seulement)
–! Définir les scénarios client –! Trier les scénarios (9 tas)
•! Granularité fine (plus fine que les Use Cases) •! Par priorité (client) : Indispensable, Essentiel, Utile
•! Doit être testable •! Par risque (programmeurs) : Fort, Moyen, Faible
•! Généralement notés sur des fiches A5 –! Annoncer la « vélocité » de l’équipe
–! Plus simples à manipuler •! Nombre de points que peut traiter l’équipe en une itération
–! Estimer les scénarios client •! Pour la première itération le coach fourni sa propre estimation
•! Attribution d’un nombre de « points » (jours théoriques) –! Répartir les scénarios parmi les livraisons à venir
•! Tenir compte du codage des tests et de la validation •! Le client « achète » les scénarios en fonction de la vélocité
•! En cas d’inconnue technique " prototypage rapide •! Création du plan de livraison provisoire
•! Scinder/Fusionner des scénarios si nécessaire

61 62

Planification itérative : Livraisons (3/3) Planification itérative : Itérations (1/2)


•! Pilotage (jusqu’à la date de livraison) •! Exploration
–! Suivre les tests de recette –! Analyser les scénarios pour les scinder en tâches
•! Nombre de tests réalisés par le client et les testeurs –! Activité de conception (même superficielle)
•! Nombre de tests validés –! Questions au client et discussion en sa présence
–! Gérer les défauts " Scénarios supplémentaires –! Tâche : réalisable par un binôme en une ou deux journées
1.!Intégrer au mécanisme général de planification
•! Engagement
2.!Priorité absolue
–! Choisir et estimer des tâches
•! Et ensuite ?
–! Equilibrage des choix dans l’équipe
–! Livrer sans délai " Reporter les scénarios manquants
–! Fusion/Scission de tâches (si nécessaire)
–! Célébrer l’événement et prendre du recul
–! Avancement/Report de scénarios (si nécessaire)
•! Repas hors du lieu de travail par exemple
–! Production du plan d’itération
•! Bonne occasion pour se détendre
–! Démarrage d’un nouveau cycle
•! Amélioration de la fiabilité des estimations

63 64
Planification itérative : Itérations (2/2) Plan
•! Pilotage •! Introduction
–! Réalisation des tâches (mise à jour du plan d’itération)
–! Tournée du Tracker (au moins deux fois par semaine) •! Equipe et rôles XP
•! Déceler tout dérapage au plus tôt
•! Prendre des mesures correctives (alléger une charge...)
•! Pratiques XP
–! Stand-up meetings •! Processus XP
•! Chaque matin un point sur la situation ou les difficultés
•! Pas une réunion technique ni un suivi des tâches •! Autres considérations
•! Permet d’organiser la journée (binômes...)
•! Et ensuite ?
–! Petite livraison informelle au client de l’équipe
–! Mise à jour des coûts des scénarios réalisés
–! Célébrer l’événement...
•! Un pot pour repartir sur de bonnes bases

65 66

XP et la modélisation XP et la documentation (1/2)


•! Can you use UML with XP? •! Au centre des débats
–! Yes. You can apply the artifacts of the UML – activity diagrams, –! « On n’écrit pas de documentation dans XP » : Faux !
class diagrams, collaboration diagrams, component diagrams, –! XP tend à éliminer la paperasse... mais restons nuancés
deployment diagrams, sequence diagrams, statechart diagrams, and
use case diagrams – when you are taking an XP approach to
•! Documentation utilisateur
development. –! Manuel utilisateur, Procédure d’installation...
•! How do you use UML with XP? –! Ils doivent être écrits, mais planifiés comme les tâches techniques
–! Minimally you should apply Agile Modelling and use UML artifacts on •! Documents liés au projet
your XP project only where appropriate. Ideally you should apply all –! Comptes rendus, Plannings...
of the principles and practices of Agile Modelling when doing so. –! Le client étant présent dans l’équipe, l’importance de ces documents
est réduite

67 68
XP et la documentation (2/2) Principaux facteurs de succès (1/2)
•! Documentation technique •! Sur le plan Humain
–! Document de conception, Diagrammes... –! Présence d’un coach potentiel
–! Tests fonctionnels " Spécification –! Quelques développeurs expérimentés... et ouverts
–! Tests unitaires " Conception détaillée –! Une équipe capable de travailler... en équipe
–! Remaniement " Modification aisée de la conception •! Sur le plan Organisationnel
–! Le code est de la documentation (génération automatique ?) –! Environnement de travail adapté (« War Room »)
•! Autour du programmeur –! Hiérarchie consentante
–! Code source comme principale production du projet –! Culture d’entreprise adaptée
–! Programmeur comme acteur essentiel •! Pas de mérite basé sur les heures supplémentaires
–! Contrairement à certaines autres méthodes •! Pas de jeu politique (gagnant-gagnant)
•! Il n’est pas un simple exécutant •! Pas d’attachement aux méthodes linéaires, ou aux tonnes de
documents comme reflet de la qualité
•! Il dispose de pratiques pour être plus efficace
•! Il accède à une certaine reconnaissance

69 70

Principaux facteurs de succès (2/2) Le problème du contrat... (1/3)


•! Sur le plan Technique •! Aujourd’hui en France...
–! Possibilité de travailler sur des portions réduites de l’application –! Mise en œuvre d’XP encore peu présente en entreprise
•! Valable dans le cas d’une reprise d’un gros projet –! Parfois pour des développements internes
•! Redécouper le logiciel dans un tel cas
•! Contrats forfaitaires
–! Langage de programmation permettant des mécanismes
–! Un fournisseur s’engage à un résultat donné, dans un délai donné
d’abstraction et de factorisation
pour un prix fixé
•! La plupart des langages objets entrent dans cette catégorie
–! Limites du modèle
–! Disposer d’un outil de gestion de versions efficace
•! Périmètre fonctionnel rarement clair
" Rapports conflictuels
" Tout le monde perd
–! Fige un maximum de paramètres (cahier des charges...)
•! Difficile de pratiquer XP dans ces conditions
•! Sauf pour deux entreprises ayant une relation partenariale
•! Impose l’utilisation d’avenants au contrat

71 72
Le problème du contrat... (2/3) Le problème du contrat... (3/3)
•! Contrats d’assistance technique (« régie ») •! Contrats d’assistance forfaitée
–! Un fournisseur met à disposition du personnel compétent –! Combinaison des deux modèles
•! Le client assure maîtrise d’ouvrage et maîtrise d’œuvre •! Facturation au temps passé
•! Le fournisseur facture au client le temps passé •! Mais le fournisseur reste maître d’œuvre
–! Limites du modèle –! Généralement difficile à faire accepter au client
•! Repousse simplement la question de la maîtrise d’œuvre –! Nécessite une relation de confiance entre les deux parties
•! Quelle est l’expérience du client dans ce domaine ?
•! Difficultés spécifiques à la France
•! Motivation des collaborateurs « mis à disposition » peut être un
problème –! Culture institutionnelle française
•! XP est une méthode privilégiant les réalités du terrain
–! La possibilité d’appliquer XP dépendra donc du client
•! En France, les décisions partent du management pour se répercuter sur
•! S’il est capable de le faire en interne
les opérationnels
•! Sinon une intervention extérieure peut permettre la transition vers XP
–! Directions financières attachées au contrat forfaitaire
•! Budget prévisionnel dans un périmètre bien défini
•! Besoins réels de l’utilisateur financièrement inexistants

73 74

Avoir l’œil critique Autres méthodes agiles (1/2)


•! Critiques possibles à l’encontre d’XP
–! Trop anarchique
–! Pas assez de documentation
–! Trop extrême...
–! Culte du super programmeur
•! Une utopie ?
–! Méthode profondément humaniste (cf. manifeste agile)
–! Tout le monde est-il honnête ?
•! Maîtriser XP...
... c’est savoir quand ne pas utiliser XP
... c’est savoir adapter XP aux besoins courants
http://www.devx.com/architect/Article/32836

75 76
Autres méthodes agiles (2/2) Pour plus d’informations sur XP
•! L’eXtreme Programming
J.L. Bénard, L. Bossavit, R. Médina, D. Williams
Editions Eyrolles
•! Extreme Programming Explained
Kent Beck, Cynthia Andres
•! XProgramming.com
http://xprogramming.com/
•! Extreme Programming: A gentle introduction
http://www.extremeprogramming.org/
•! eXtreme Programming France
http://www.devx.com/architect/Article/32836 http://xp-france.net/
•! Design Up
http://www.design-up.com/
77 78

Vous aimerez peut-être aussi