Mon client n'est pas agile

1 113 vues

Publié le

Publié dans : Business
0 commentaire
2 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
1 113
Sur SlideShare
0
Issues des intégrations
0
Intégrations
26
Actions
Partages
0
Téléchargements
0
Commentaires
0
J’aime
2
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Mon client n'est pas agile

  1. 1. Agile dans un contexte traditionnel ?<br />Retour d’expérience<br />Nicolas De Loof<br />7 Octobre 2010<br />
  2. 2. Who’sthatguy ?<br />www.agiletour.com<br />05/05/09<br /> Nicolas De loof<br />Architecte Agile<br />Techno veilleur<br />Committer<br />Fondateur du <br />http://blog.loof.fr<br />twitter.com/ndeloof<br />nicolas@apache.org<br />
  3. 3. www.agiletour.com<br />05/05/09<br />Agile ?<br />
  4. 4. Ce témoignage ne concerne pas mon employeur actuel (Orange Business Services IT&Labs)<br />Les exemples cités sont des « tranches de vie » présentées hors contexte.<br />Ils ne peuvent tenir lieu de témoignage représentatif, ni du projet, ni du client, ni du lieu où ils se sont déroulés.<br />www.agiletour.com<br />05/05/09<br />
  5. 5. Dans une vie antérieure …<br />Client <br />Organisation dispersée et très hiérarchisée<br />Contractualisation forte<br />Distant et dispersé<br />Management<br />Culture figée<br />Syndrome « N.I.H. »<br />www.agiletour.com<br />05/05/09<br />
  6. 6. Peut on être agile dans ce contexte ?<br />www.agiletour.com<br />05/05/09<br />
  7. 7. … mais on peut tout de même essayer<br />www.agiletour.com<br />05/05/09<br />
  8. 8. Comment ?<br />Interactions plutôt que Processus et outils<br />Réactivité plutôt que Planification<br />Produit opérationnel plutôt que Documentation<br />Collaboration plutôt que Contrat<br />www.agiletour.com<br />05/05/09<br />
  9. 9. Interactions plutôt que Processus et outils<br />www.agiletour.com<br />05/05/09<br />
  10. 10. Constat<br />L’information passe difficilement<br />Scope et priorités du projet<br />Dates clé<br />Tâches en cours<br />Les devs ne sont pas impliqués<br />Flagrant sur les calculs de RAF<br />www.agiletour.com<br />05/05/09<br />
  11. 11. « Multiplier les réunions d’avancement de projet »<br />Mieux que rien<br />Trop long<br />Scope trop large<br />Monologue<br />Rapidement parasitée<br />Gantt illisible<br />www.agiletour.com<br />05/05/09<br />L’idée qui fait plouf<br />
  12. 12. Koffee Stand-up<br />Facile à mettre en œuvre<br />Résultats concrets et rapides<br />Délicat à « cérémonialiser »<br />www.agiletour.com<br />05/05/09<br />
  13. 13. Management visuel<br />KanBan<br />www.agiletour.com<br />05/05/09<br />
  14. 14. Le Kanban<br />Simple<br />Appropriation rapide<br />Bon support pour mettre en place un cérémonial<br />Bien adapté en gestion d’anomalies<br />Visuel = effet démo auprès des autres équipes<br />www.agiletour.com<br />05/05/09<br />
  15. 15. Bilan<br />Simple et progressif à mettre en œuvre<br />Pas de remise en cause violente de l’existant<br />Effets rapides<br />Bonne appropriation par l’équipe<br />www.agiletour.com<br />05/05/09<br />
  16. 16. Réactivité plutôt que Planification<br />www.agiletour.com<br />05/05/09<br />
  17. 17. Introduire la priorisation des tâches<br />Ajouter une colonne « priorité » et un user « unasigned »<br />Laisser l’équipe se répartir les tâches<br />Commencer sur la gestion d’anomalies pendant un période de crise !<br />www.agiletour.com<br />05/05/09<br />
  18. 18. Utiliser un chiffrage « à la louche »<br />Perte de temps induite par trop de planification<br />Permet de conserver l’approche traditionnelle « Gantt »-based<br />Faire appel à l’ami Fibonacci<br />www.agiletour.com<br />05/05/09<br />
  19. 19. Bilan<br />Responsabilisation de l’équipe<br />Libère le chef d’équipe de tâches barbantes<br />« ça ne marche pas plus mal »<br />www.agiletour.com<br />05/05/09<br />
  20. 20. Pilotage par les exigences<br />Délicat : conflit/surcoût avec les pratiques contractuelles<br />Profiter des limites du système :)<br />1 doc de spécification<br />Des exigences du client<br />3 « lots » en cours<br />Des changements de lotissement fréquents<br />www.agiletour.com<br />05/05/09<br />
  21. 21. Soft fonctionnel plutôt que doc exhaustive<br />www.agiletour.com<br />05/05/09<br />
  22. 22. Builder une version d’intégration …<br />www.agiletour.com<br />05/05/09<br />http://emmanuelchenu.blogspot.com/<br />
  23. 23. Un logiciel qui marche à tout moment<br />Automatisation<br />ROI facile à mesurer<br />Avantages nombreux<br />Intégration continue<br />Pratique simple et peu intrusive<br />ROI délicat à mesurer…<br /> Passer outre « pour gagner du temps »<br />Ne pas oublier les IQ dans la boucle !<br />www.agiletour.com<br />05/05/09<br />
  24. 24. Risques<br />Syndrome du flicage<br />Gérer les « Mauvais élèves »<br />www.agiletour.com<br />05/05/09<br />
  25. 25. Solutions<br />Feedback visuel<br />IC Game et autresastuces positives de « team-building »<br />www.agiletour.com<br />05/05/09<br />
  26. 26. Bilan<br />Responsabilise les développeurs<br />Le projet devient un élément <br />concret, <br />vivant<br />commun<br />www.agiletour.com<br />05/05/09<br />
  27. 27. Développement Dirigé par les tests<br />Gros travail d’évangélisation sur les tests<br />Test-first très peu appliqué<br />Vécu comme un « surcoût »<br />Ne se substitue pas aux documents de spec détaillée<br />Accompagnement indispensable<br />www.agiletour.com<br />05/05/09<br />
  28. 28. Bilan<br />Des progrès, mais un gros investissement<br />Survit difficilement à la phase de livraison<br />Considéré comme un coût dans la version N+1<br />Nécessite une mutation organisationnelle<br />www.agiletour.com<br />05/05/09<br />
  29. 29. Mon ami Word …<br />Inscrit dans le formalisme contractuel <br />Mais pas dans la documentation technique / méthodologique « hors livrable »<br />www.agiletour.com<br />05/05/09<br />
  30. 30. Documentation « agile »<br />Collaborative<br />Incrémentale<br />Navigable<br />« Juste ce qu’il faut »<br />www.agiletour.com<br />05/05/09<br />
  31. 31. Vive le wiki !<br />Mon choix : xWiki<br />Via Office pour les « fonctionnels »<br />Via Eclipse pour les « techos »<br />En ligne pour les autres<br />www.agiletour.com<br />05/05/09<br />
  32. 32. Collaboration plutôt que Contrat<br />www.agiletour.com<br />05/05/09<br />
  33. 33. Pas d’agilité sans implication client ?<br />www.agiletour.com<br />05/05/09<br />
  34. 34. Dé-contractualiser le dialogue<br />Proposer spontanément des « points de visibilité »<br />Dé-formaliser les échanges, quitte à synthétiser les décisions<br />www.agiletour.com<br />05/05/09<br />
  35. 35. Pièges à éviter<br />www.agiletour.com<br />05/05/09<br />
  36. 36. Prononcer le mot « agilité »<br />Chaque chose en son temps …<br />Eviter les amalgames<br />Parler au mieux de « pratiques »<br />www.agiletour.com<br />05/05/09<br />
  37. 37. Prononcer le mot « binôme »<br />Deux développeurs sur un poste, quelle hérésie !<br />Parler de « coaching », d’ « entraide » …<br />Exploiter les chaises à roulette !<br />www.agiletour.com<br />05/05/09<br />
  38. 38. Critiquer le système en place<br />C’est déjà assez compliqué comme ça …<br />Eviter le conflit<br />Insister sur les gaspillages,plutôt que sur leurs causes<br />Proposer des « compléments »,  le superflu disparaitra de lui-même<br />www.agiletour.com<br />05/05/09<br />
  39. 39. Faire des rapprochements hasardeux<br />Mapper les rôles Scrum sur l’équipe en place<br />« Team » <br />Product Owner<br />Chef de Projet<br />Managers<br />Client<br />www.agiletour.com<br />05/05/09<br />
  40. 40. Oublier les indicateurs<br />Assurer le reporting au management<br />Donne des éléments de comparaison / RoI<br />Evite l’amalgame Agile = Sans contrôle<br />www.agiletour.com<br />05/05/09<br />
  41. 41. Conclusion<br />Comment amener mon client et/ou mon management à envisager l’agilité <br />www.agiletour.com<br />05/05/09<br />
  42. 42. Proposer des « aménagements » progressifs, à petite échelle<br />Montrer de la discipline dans les pratiques<br />Essaimer, diffuser, accompagner<br />Laisser le temps à chacun de s’approprier les pratiques<br />Fournir des preuves de la plus-value<br />www.agiletour.com<br />05/05/09<br />
  43. 43. A vous de jouer !<br />www.agiletour.com<br />05/05/09<br />

×