© 2006 Hewlett-Packard Development Company, L.P.
The information contained herein is subject to change without notice
IdId...
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 prati...
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 utili...
7 4 May 2008
XP c'est pour les développeurs
• Beaucoup de pratiques techniques
• Souvent adopté en premier par les dévelop...
8 4 May 2008
XP ne s'intéresse pas à la gestion de projet
• Souvent réduit aux aspects techniques
Mais:
• Planification de...
9 4 May 2008
Une équipe XP est incontrôlable
• Forte notion d’équipe
• Responsabilité collective
• Estimations faites coll...
10 4 May 2008
Avec XP les changements sont gratuits
• Le client décide ce qui doit être fait
• Possibilité de changer les ...
11 4 May 2008
Le client gagne juste le droit de choisir
les fonctionnalités à retirer
Ce que gagne aussi le client:
• Gest...
12 4 May 2008
Le coach est un responsable d'équipe
• Il faut trouver une place aux responsables d’équipes
Rappels:
• Aucun...
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 à...
14 4 May 2008
Une itération de 4 semaines c'est trop
court
• Volonté de ne pas perturber les habitudes
• Risque d’effet tu...
15 4 May 2008
Il faut planifier la charge d'une
personne pour toute l'itération
• Réflexe classique et humain
• Démarche i...
16 4 May 2008
Jours ou points c'est la même chose
• Risque d’incompréhension au sein de l’équipe
• Incertitude des estimat...
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 fe...
18 4 May 2008
Il suffit de travailler le soir et le week-
end pour respecter les estimations
• Apport éventuel sur du cour...
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 clai...
20 4 May 2008
La responsabilité collective est une
utopie
Plusieurs raisons possibles à cette notion:
• Individualisme
• P...
21 4 May 2008
L'automatisation des tests de recettes est
géniale
• Oui ;-)
Conseils:
• Toujours plus facile quand le produ...
22 4 May 2008
On ne peut pas découper toutes les
fonctionnalités en petits morceaux
• Pas toujours évident
• Plus ce qu’il...
23 4 May 2008
On ne peut pas toujours trouver une
valeur ajoutée cliente à chaque scénario
• Découpage très orienté techni...
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 p...
25 4 May 2008
S'il y a des tests de recette automatisés,
pas besoin de tests unitaires
• Pourquoi pas. Les tests de recett...
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 fa...
27 4 May 2008
Il faut prévoir des tâches de remaniement
On rencontre généralement cette demande dans
deux cas:
• Le remani...
Des questions?
Idées reçues sur l’eXtreme Programming en particulier et sur l’agilité en générale
Prochain SlideShare
Chargement dans…5
×

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

425 vues

Publié le

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.

0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
425
Sur SlideShare
0
Issues des intégrations
0
Intégrations
5
Actions
Partages
0
Téléchargements
4
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

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

  1. 1. © 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
  2. 2. L’agilité au sein de HP
  3. 3. 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
  4. 4. Idées reçues…
  5. 5. 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
  6. 6. 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
  7. 7. 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
  8. 8. 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
  9. 9. 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
  10. 10. 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
  11. 11. 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
  12. 12. 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
  13. 13. 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
  14. 14. 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
  15. 15. 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
  16. 16. 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
  17. 17. 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
  18. 18. 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)
  19. 19. 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
  20. 20. 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
  21. 21. 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…
  22. 22. 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?
  23. 23. 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
  24. 24. 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.
  25. 25. 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
  26. 26. 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
  27. 27. Des questions?

×