Idées reçues sur l’eXtreme Programming en particulier et sur l’agilité en générale

28

Transcript of Idées reçues sur l’eXtreme Programming en particulier et sur l’agilité en générale

© 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

L’agilité au sein de HP

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

Idées reçues…

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

Des questions?