idées reçues sur l’extreme programming en particulier et sur l’agilité en générale
TRANSCRIPT
© 2006 Hewlett-Packard Development Company, L.P.The information contained herein is subject to change without notice
IdIdIdIdéééées rees rees rees reççççues sur ues sur ues sur ues sur llll’’’’eXtremeeXtremeeXtremeeXtreme ProgrammingProgrammingProgrammingProgrammingen particulier et sur en particulier et sur en particulier et sur en particulier et sur llll’’’’agilitagilitagilitagilitéééé en gen gen gen géééénnnnééééraleraleralerale
Virgile Delécolle - 6 mai 2008
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
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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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