Cela fait maintenant plus de six ans que j’ai découvert XP, et j’ai depuis eu de nombreuses occasions d’en parler autour de moi, que ce soit avec des collègues, des amis ou des recruteurs. Selon le profil des personnes (développeurs, testeurs, managers ou ressources humaines) la vision qu’ils ont d’XP et de l’agilité est différente, mais au sein d’un groupe on retrouve bien souvent les mêmes idées reçues qui sont malheureusement autant de freins à l’adoption. Cette session aura pour but de reprendre les plus répandues afin de les analyser pour voir si elles sont vraies, fausses ou s’il faut nuancer le propos.

2. © 2006 Hewlett-Packard Development Company, L.P.
The information contained herein is subject to change without notice
IdIdIdIdéééées rees rees rees reççççues surues surues surues sur
llll’’’’eXtremeeXtremeeXtremeeXtreme ProgrammingProgrammingProgrammingProgramming
en particulier et suren particulier et suren particulier et suren particulier et sur
llll’’’’agilitagilitagilitagilitéééé en gen gen gen géééénnnnééééraleraleralerale
Virgile Delécolle - 6 mai 2008

3. L’agilité au sein de HP

4. 4 4 May 2008
HP et l’agilité
• Principalement dans le logiciel, mais globalement encore
peu pratiquée
• Adoption des pratiques les plus répandues
• Lean, Scrum et XP sont les 3 méthodologies les plus
connues et les plus utilisées
• Non adoption par manque d’information
• Groupe agile interne depuis 2003
− Newsletter mensuelle
− Forum de discussion
− Site web
− Conférences

5. Idées reçues…

6. 6 4 May 2008
XP c'est ce qui a été remplacé par Vista
• XP est l’abréviation d’eXtreme Programming
Conseil:
• Ne pas utiliser l’abréviation tant que le contexte
n’est pas clair pour votre interlocuteur

7. 7 4 May 2008
XP c'est pour les développeurs
• Beaucoup de pratiques techniques
• Souvent adopté en premier par les développeurs
Cependant:
• D’autres rôles que celui de développeur
• Spectre plus large que le codage

8. 8 4 May 2008
XP ne s'intéresse pas à la gestion de projet
• Souvent réduit aux aspects techniques
Mais:
• Planification des développements
• Planification des livrables
• Implication du client
• Gestion des risques

9. 9 4 May 2008
Une équipe XP est incontrôlable
• Forte notion d’équipe
• Responsabilité collective
• Estimations faites collectivement
• Rythme durable
Mais:
• Visibilité permanente
• Qualité accrue
• Souplesse aux changements

10. 10 4 May 2008
Avec XP les changements sont gratuits
• Le client décide ce qui doit être fait
• Possibilité de changer les choses avant qu’il ne soit trop
tard, quand cela n’a pas trop d’impacts
• Volonté de satisfaire les demandes du client
Attention:
• Danger de vouloir « prouver » la réactivité d’une équipe XP
• Tout ce qui vient en plus doit être pris en compte dans le
planning global

11. 11 4 May 2008
Le client gagne juste le droit de choisir
les fonctionnalités à retirer
Ce que gagne aussi le client:
• Gestion des priorités
• Meilleure visibilité – plus d’effet tunnel
• Meilleure adéquation entre ce qu’il a en tête et ce qu’on lui
délivre
• Possibilité de mettre en production à chaque fin d’itération
• En cas de retard ou de changement, c’est lui qui choisit sur
quel facteur il faut jouer pour compenser

12. 12 4 May 2008
Le coach est un responsable d'équipe
• Il faut trouver une place aux responsables d’équipes
Rappels:
• Aucun rôle hiérarchique entre le coach et l’équipe
• Rôle clef de facilitateur au sein de l’équipe mais aussi vis-à-
vis du monde extérieur
• Garant de la relation entre le client et l’équipe
• Garant du respect de la méthode
• Convaincu par XP

13. 13 4 May 2008
L'itératif c'est une réunion régulière pour
faire le point
Ce que l’agilité entend par itératif:
• Réunion à intervalle régulier
• Objectifs réalisables
• Métriques claires, utilisables et mesurées
honnêtement
• Rétrospective de l’itération précédente
• Changement/action à prendre pour l’itération
suivante
• Planification de l’itération suivante

14. 14 4 May 2008
Une itération de 4 semaines c'est trop
court
• Volonté de ne pas perturber les habitudes
• Risque d’effet tunnel
• Pas de démarche de découpage des besoins
• Perte d’agilité, car tout le processus devient beaucoup plus
long
• Qualité non garantie tout au long de l’itération
Personnellement:
• 4 semaines maximum

15. 15 4 May 2008
Il faut planifier la charge d'une
personne pour toute l'itération
• Réflexe classique et humain
• Démarche individuelle qui va à l’encontre de la
gestion des priorités
• Fragilise la responsabilité collective et la notion
d’équipe
Remarque:
• Moins il y aura de spécialisations au sein de
l’équipe, plus il sera facile de prévoir la charge de
l’équipe de manière globale

16. 16 4 May 2008
Jours ou points c'est la même chose
• Risque d’incompréhension au sein de l’équipe
• Incertitude des estimations
• Risque de perdre la confiance du management
• N’implique pas la même méthode de planification
Conseil:
• Choisir un système auquel tout le monde adhère,
aussi bien pour les estimations que pour la
planification, et s’y tenir

17. 17 4 May 2008
Il n'est pas nécessaire d'avoir une version
livrable à la fin de chaque itération
• Impossible d’avoir du feedback
• Perte de confiance du client
• Risque de surcoût pour la stabilisation
Ceci doit aussi nous mettre en garde:
• Sur la qualité des développements
• Sur l’intégration continue
• Sur la qualité du produit

18. 18 4 May 2008
Il suffit de travailler le soir et le week-
end pour respecter les estimations
• Apport éventuel sur du court terme
Mises en garde:
• Diminution de la qualité
• Fausse toutes les estimations
• Invalide les différents plannings
• Use la motivation de l’équipe

19. 19 4 May 2008
La mêlée est une réunion où on raconte
sa journée
Durant la mêlée (stand-up), il faut:
• Être concis et clair
• Délivrer l’information utile de sa journée
• Faire un point sur la tâche en cours
• Annoncer le planning du lendemain
• (Demander de l’aide)
• (Prévoir une réunion)

20. 20 4 May 2008
La responsabilité collective est une
utopie
Plusieurs raisons possibles à cette notion:
• Individualisme
• Pas d’esprit d’équipe
• Elément perturbateur
• Hiérarchie concentrée sur la performance individuelle
• Recherche des coupables
• Besoin d’avoir un « contact »
« C’est étonnant ce que l’on peut accomplir lorsqu’on ne se
préoccupe pas de qui s’en voit attribuer le mérite»
Harry S. Truman

21. 21 4 May 2008
L'automatisation des tests de recettes est
géniale
• Oui ;-)
Conseils:
• Toujours plus facile quand le produit est pensé
pour
• Démarrer en même temps que le développement
du produit
• Optimum si les régressions sont analysées et
corrigées immédiatement

22. 22 4 May 2008
On ne peut pas découper toutes les
fonctionnalités en petits morceaux
• Pas toujours évident
• Plus ce qu’il faut estimer est gros, plus l’incertitude sera
grande
• Plus ce qu’il faut réaliser est long, plus la divergence est
possible
Remarque:
• Découper une fonctionnalité est bien souvent plus facile
quand on a plus le temps, que lorsque l’on démarre le
projet…

23. 23 4 May 2008
On ne peut pas toujours trouver une
valeur ajoutée cliente à chaque scénario
• Découpage très orienté technique
• Absence d’un « client »
Idée:
• Toujours se demander pourquoi on le fait. Même
un scenario demandé par l’équipe technique doit
avoir un apport pour le client, sinon pourquoi
dépenser pour sa réalisation?

24. 24 4 May 2008
Le binômage coûte deux fois plus cher
• À instant t figé dans le temps
• Si le copilote ne fait que suivre passivement
A prendre en compte:
• Une meilleure qualité
• Le partage des connaissances
• Le nivellement par le haut de l’équipe

25. 25 4 May 2008
S'il y a des tests de recette automatisés,
pas besoin de tests unitaires
• Pourquoi pas. Les tests de recette garantissent que le
produit répond aux besoins du client.
Remarques:
• Les tests de recettes et les tests unitaires n’ont pas la même
granularité. En cas de régression, le temps nécessaire pour
la détection, l’identification ne seront pas les mêmes.
• Jouer les tests de recette nécessite parfois un environnement
spécifique, il est alors impossible de les jouer avant
d’intégrer une nouveauté à l’existant.

26. 26 4 May 2008
Il n'est pas nécessaire d'écrire des tests
unitaires pour tout
• Réflexe que l’on rencontre régulièrement face à
une tâche simple
Mises en garde:
• Difficile de définir une règle sur le sujet
• Offre la possibilité de ne pas écrire de test
• L’écriture des tests unitaires joue un rôle dans la
conception

27. 27 4 May 2008
Il faut prévoir des tâches de remaniement
On rencontre généralement cette demande dans
deux cas:
• Le remaniement n’est pas pratiqué tout au long du
développement: il est préférable de rappeler que
c’est une activité permanente plutôt que d’entériner
cette démarche.
• L’équipe souhaite un changement d’architecture:
dans ce cas ce n’est pas du remaniement, c’est en
fait un scénario technique dont les motivations
peuvent et doivent être expliquées au client

28. Des questions?