Quelques slides sur l`eXtreme Programming

ISL/PS
Graduat en Informatique
Projet de développement
eXtreme Programming
eXtreme
Programming
Ces transparents sont basés sur une libre interprétation
de l'ouvrage suivant :
L'eXtreme Programming
avec deux études de cas
J.L. Bénard, L. Bossavit, R. Médina, D. Williams
paru aux éditions Eyrolles
18/11/03
Eric Schmitz
1
ISL/PS
Projet de développement
eXtreme Programming
Graduat en Informatique
XP?
Limites des démarches par phases.
Rupture par rapport au cycle en V.
Dans les approches classiques, on cherche à définir
de manière détaillée ce que l'on souhaite
construire.
Ceci fonctionne pour des ponts, des immeubles...
MAIS pas pour du « construire » des logiciels.
18/11/03
Eric Schmitz
2
ISL/PS
Projet de développement
eXtreme Programming
Graduat en Informatique
Causes d'échecs
On ne connaît pas, a priori, les détails des specs.
Cet exercice à lieu au début du projet, au moment
où les différents intervenants en savent le moins
sur le contexte de l'application.
Ceci entraîne une remise en cause fréquente des
specs => perte de temps.
UML n'est pas une solution, même s’il n'est pas à
rejeter.
18/11/03
Eric Schmitz
3
ISL/PS
Projet de développement
eXtreme Programming
Graduat en Informatique
Effet tunnel
Visibilité réduite du client pendant la phase
de construction.
En XP, le client peut intervenir
fréquemment pendant la construction de
l'application et a un pouvoir pour influer sur
le cours du projet.
18/11/03
Eric Schmitz
4
ISL/PS
Projet de développement
eXtreme Programming
Graduat en Informatique
Equipes compartimentées
Souvent, les développeurs sont isolés,
travaillant seuls sur leur machine et
communiquent en étoile.
Ceci entraine :
Une mauvaise distribution de l'info.
Une spécialisation abusive des développeurs.
Le code est soumis à une paralysie
progressive.
18/11/03
Eric Schmitz
5
ISL/PS
Projet de développement
eXtreme Programming
Graduat en Informatique
Paralysie progressive
La qualité interne (le code) est noyée sous/par les
efforts sur la qualité externe (docs, specs, tests).
La qualité du code dépend uniquement du
développeur.
Plus le code dégénère, plus les modifications
prennent du temps et risquent d'engendrer des
erreurs.
C'est au cours de l'implémentation que la validité des
spécifications et de la conception est mise à
l'épreuve.
18/11/03
Eric Schmitz
6
ISL/PS
Graduat en Informatique
Projet de développement
eXtreme Programming
Evolution du coût du changement
Approche traditionnelle
Il est logique de définir
complètement le logiciel avant
d'entamer sa construction.
Coût
T1
T2
T3
T4
MAIS : si on applique certains
principes de conception et de
programmation, il est possible
de garder l'application
suffisamment souple.
18/11/03
Eric Schmitz
Approche "XP"
Coût
T1
T2
T3
T4
T5
7
ISL/PS
Projet de développement
eXtreme Programming
Graduat en Informatique
Evolution du coût du changement
La stratégie gagnante ne consiste plus à
figer tout dès le début, mais tout au
contraire, à diffuser la prise de décision
tout au long du projet.
XP propose un ensemble de pratiques
concrètes pour obtenir plus de souplesses et
exploiter celles-ci pour servir au mieux le
client et l 'équipe de développement.
18/11/03
Eric Schmitz
8
ISL/PS
Projet de développement
eXtreme Programming
Graduat en Informatique
Les pratiques d'XP
18/11/03
Eric Schmitz
9
ISL/PS
Projet de développement
eXtreme Programming
Graduat en Informatique
Pratiques de programmation
Conception simple (tjs la solution la plus
simple).
Remaniement. (nettoyage de code)
Développement piloté par les tests
unitaires. (d'abord écrire les tests !)
Tests de recettes, précisés par le client.
18/11/03
Eric Schmitz
10
ISL/PS
Projet de développement
eXtreme Programming
Graduat en Informatique
Pratiques de collaboration
Programmation en binôme -> les binômes
changent fréquemment.
Responsabilité collective du code.
Règles de codage.
Métaphore.
Intégration continue (au moins 1x par jour).
18/11/03
Eric Schmitz
11
ISL/PS
Projet de développement
eXtreme Programming
Graduat en Informatique
Pratiques de gestion de projet
Livraisons fréquentes.
Planification itérative.
Client sur site.
Rythme durable.
18/11/03
Eric Schmitz
12
ISL/PS
Projet de développement
eXtreme Programming
Graduat en Informatique
Les quatres valeurs d'XP
18/11/03
Eric Schmitz
13
ISL/PS
Projet de développement
eXtreme Programming
Graduat en Informatique
La communication pour une
meilleure visibilité
Projet de développement ?
Effort collectif de création
Dont le succès dépend :
De la vision commune de ce qui doit être produit.
De la capacité à synchroniser les actions
individuelles.
Ces deux conditions dépendent de la qualité de
la communication.
18/11/03
Eric Schmitz
14
ISL/PS
Projet de développement
eXtreme Programming
Graduat en Informatique
La communication pour une
meilleure visibilité
XP met l'accent sur la communication
directe.
Communication orale
Pour sa simplicité.
Pour des interactions rapides entre les
interlocuteurs.
Plus personnelle.
18/11/03
Eric Schmitz
15
ISL/PS
Projet de développement
eXtreme Programming
Graduat en Informatique
La communication pour une
meilleure visibilité
La communication écrite :
toutes les informations ayant trait à
l'implémentation et à la conception se retrouvent
dans le code.
La clarté du code fait l'objet de nombreux efforts.
Les tests servent également à consigner
formellement les besoins des clients.
18/11/03
Eric Schmitz
16
ISL/PS
Projet de développement
eXtreme Programming
Graduat en Informatique
La simplicité comme garantie de
productivité
Mantras exprimant la simplicité :
La chose la plus simple qui puisse marcher. (The
simplest thing that could possibly work)
Tu n'en auras pas besoin. (You ain't gonna need
it)
Une fois et une seule. (Once and only once)
Débarrasser le code de toute complexité
superflue.
18/11/03
Eric Schmitz
17
ISL/PS
Projet de développement
eXtreme Programming
Graduat en Informatique
La simplicité comme garantie de
productivité
L'effort de simplicité s'applique également
au client.
Il doit définir ses besoins avec une grande
précision pour éviter d'implémenter des choses
inutiles.
La simplicité est également recherchée
dans le choix des outils et dans la méthode
de travail elle-même.
18/11/03
Eric Schmitz
18
ISL/PS
Projet de développement
eXtreme Programming
Graduat en Informatique
Le feedback comme outil de
réduction de risque
XP : Processus de réduction de risque.
Risque contrôlé par la mise en place de
boucles de feedback.
Permets à tout moment de savoir dans quel
état se trouve le projet.
Et donc de pouvoir rectifier le tir au fur et
à mesure.
18/11/03
Eric Schmitz
19
ISL/PS
Projet de développement
eXtreme Programming
Graduat en Informatique
Le feedback comme outil de
réduction de risque
Un exemple en est le principe de livraisons
fréquentes.
La planification itérative permet de tirer
parti des informations recueillies, pour
améliorer la planification et faire converger
le produit vers une solution mieux adaptée
aux besoins.
18/11/03
Eric Schmitz
20
ISL/PS
Projet de développement
eXtreme Programming
Graduat en Informatique
Le feedback comme outil de
réduction de risque
Divers mécanismes de feeback interviennent dans
l'activité de programmation :
Tests unitaires.
Feeback du binôme.
Intégré à la conception.
Le feeback est un facteur de qualité, car les
intervenants améliorent sans cesse leur travail en
profitant de l'expérience qu'ils accumulent.
18/11/03
Eric Schmitz
21
ISL/PS
Projet de développement
eXtreme Programming
Graduat en Informatique
Le courage de prendre les bonnes
décisions.
Courage pour se lancer dans un projet sans
avoir tout spécifié.
Courage pour se borner à réaliser des
choses simples.
Courage pour appliquer les principes de
communication et de feedback.
Courage de mettre en place des méthodes
nouvelles.
18/11/03
Eric Schmitz
22
ISL/PS
Projet de développement
eXtreme Programming
Graduat en Informatique
Les principaux rôles d'XP
18/11/03
Eric Schmitz
23
ISL/PS
Projet de développement
eXtreme Programming
Graduat en Informatique
Liste des rôles
Le programmeur
Le client
Le coach
Le testeur
Le tracker
Le manager
18/11/03
Eric Schmitz
24
ISL/PS
Projet de développement
eXtreme Programming
Graduat en Informatique
Le programmeur
Va écrire, connaître, modifier, gérer
l'existence, la sauvegarde, les versions, la
transformation en exécutable du CODE.
Va TESTER le code pour en obtenir un
feedback.
Va faire preuve de COURAGE, toute
fonctionnalité qui n'a pas été suffisamment
testée doit être considérée comme
n'existant pas.
18/11/03
Eric Schmitz
25
ISL/PS
Projet de développement
eXtreme Programming
Graduat en Informatique
Le programmeur
Va poser des questions au client et écouter
ses réponses. C'est le client qui détient la
connaissance de ce que doit faire le
système.
Va aider le client à définir ses besoins.
XP fournit un cadre méthodologique pour
cela.
18/11/03
Eric Schmitz
26
ISL/PS
Projet de développement
eXtreme Programming
Graduat en Informatique
Le programmeur
Va concevoir :
Collectivement lors des séances de
planification.
En écrivant les tests unitaires du code.
En pratiquant le refactoring (remaniement).
Est responsabilisé :
Il est codeur, testeur, concepteur, analyste.
Il a la volonté d'apprendre.
18/11/03
Eric Schmitz
27
ISL/PS
Projet de développement
eXtreme Programming
Graduat en Informatique
Le programmeur
Est le seul à avoir la reponsabilité des délais
(ni le client, ni le manager, ni le coach ne
peuvent influencer le programmeur dans
ses estimations)
A donc un rôle varié.
18/11/03
Eric Schmitz
28
ISL/PS
Projet de développement
eXtreme Programming
Graduat en Informatique
Charte des droits du programmeur
Le développeur a le droit :
De savoir ce qui est demandé, avec des priorités
clairement déclarées.
De fournir un travail de qualité en toute
occasion.
De demander et recevoir de l'aide de la part de
ses pairs et du client.
D'émettre et de réviser ses propres estimations
de coûts.
18/11/03
Eric Schmitz
29
ISL/PS
Projet de développement
eXtreme Programming
Graduat en Informatique
Le programmeur
Charte des droits du programmeur
D'accepter des responsabilités, mais qui ne
peuvent lui être imposées.
De travailler à un rythme de travail durable.
18/11/03
Eric Schmitz
30
ISL/PS
Projet de développement
eXtreme Programming
Graduat en Informatique
Pratiques XP du programmeur
Programmation en binôme.
Tests unitaires.
Conception simple.
Remaniement.
Responsabilité collective du code.
Règles de codage.
Intégration continue.
Rythme durable.
18/11/03
Eric Schmitz
31
ISL/PS
Projet de développement
eXtreme Programming
Graduat en Informatique
Le client
Le client sur site.
Le client spécifie par des scénarios client...
En commençant par en faire la liste.
En donnant des priôrités aux scénarios.
Nécessité de feedback pour le client -> le
feedback assure une bonne communication
entre le programmeur et le client.
18/11/03
Eric Schmitz
32
ISL/PS
Projet de développement
eXtreme Programming
Graduat en Informatique
Le client
Le client spécifie par des tests de recette.
Pratique XP du client
Planification itérative.
Tests de recettes.
Intégration continue.
Rythme durable.
18/11/03
Eric Schmitz
33
ISL/PS
Projet de développement
eXtreme Programming
Graduat en Informatique
Charte des droits du client
Le client a le droit :
A un plan d'ensemble, montrant ce qui peut être
accompli, pour quand, à quel coût.
D'obtenir le plus de valeur possible de chaque
semaine de programmation.
De voir des progrès sur une application qui
marche, comme doivent le prouver les tests
répétables qu'il spécifie.
18/11/03
Eric Schmitz
34
ISL/PS
Projet de développement
eXtreme Programming
Graduat en Informatique
Charte des droits du client
De changer d'avis, de substituer des fonctionnalités
et de changer ses priorités sans en payer un prix
exorbitant.
D'être informé des modifications portées au
calendrier de réalisation, assez tôt pour avoir la
possibilité de réduire le périmètre fonctionnel et
retomber ainsi sur la date de livraison initiale.
D'annuler le projet à tout moment et de disposer
d'une application utile et utilisable en contrepartie
de son investissement.
18/11/03
Eric Schmitz
35
ISL/PS
Projet de développement
eXtreme Programming
Graduat en Informatique
Le coach
Garant du processus.
Organise et anime les séances de planification.
Aide le client à rédiger ses premiers scénarios.
Doit avoir le courage de dire les choses telles
qu'elles sont.
Objectifs du coach : que l'équipe fonctionne bien,
sans lui...
18/11/03
Eric Schmitz
36