Ce diaporama a bien été signalé.
Le téléchargement de votre SlideShare est en cours. ×

ATR2011 - Scrum dans les tranchées Normandes

Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Prochain SlideShare
Corescrum fr-v1.1
Corescrum fr-v1.1
Chargement dans…3
×

Consultez-les par la suite

1 sur 44 Publicité

ATR2011 - Scrum dans les tranchées Normandes

Télécharger pour lire hors ligne

Cette session est le retour d’expérience de 8 mois de mise en place de scrum au sein d’une équipe de développement logiciel en haute-normandie.
Le scrum master et l’architecte de l’équipe vous feront des retours terrains sans langue de bois.

Cette session est le retour d’expérience de 8 mois de mise en place de scrum au sein d’une équipe de développement logiciel en haute-normandie.
Le scrum master et l’architecte de l’équipe vous feront des retours terrains sans langue de bois.

Publicité
Publicité

Plus De Contenu Connexe

Diaporamas pour vous (20)

Les utilisateurs ont également aimé (17)

Publicité

Similaire à ATR2011 - Scrum dans les tranchées Normandes (20)

Plus par Normandy JUG (20)

Publicité

Plus récents (20)

ATR2011 - Scrum dans les tranchées Normandes

  1. 1. Scrum dans les tranchées normandes Youen Chene, Anthony Hurot Rouen - 13 octobre 2011 13 octobre 2011
  2. 2. Partenaires Gold Partenaires logistique 13 octobre 2011
  3. 3. Vos intervenants Anthony Hurot Youen Chéné Scrum Master Architecte Masternaut Masternaut
  4. 4. Mise en place de l'agilité
  5. 5. Contexte initiale Un bilan mitigé au sein de l'entreprise : ● une équipe de développement hétérogène techniquement et fonctionnellement, ● une gestion de projet basé sur le cycle en V et avec des manques sur les premières étapes, ● frustation des développeurs de ne pas être impliqué, ● frustation des MOA dû à des retards à la livraison et une qualité inappropriée.
  6. 6. Contexte initiale La solution ? ● arrivé d'un nouveau projet de refonte, ● sélection d'une nouvelle approche/ méthode, ● sélection d'une équipe pilote au seins du service développement, ● nouvelle direction dans l'entreprise.
  7. 7. Gains espérés Gain Objectif Compétence de l'équipe Meilleur homogénéité Augmentation des compétences. Time To Market Implication des développeurs Transparence Traitement des Focalisation sur la résolution plutôt problèmes que sur les coupables.
  8. 8. Pratiques cibles Scrum
  9. 9. Les 3 premiers mois Mise en place d'un ScrumMaster débutant (ex développeur). Mise en places de l'ensemble des cérémoniaux scrum remanié par le ScrumMaster en version light. Mise en place d'un Product Owner et d'un super Product Owner.
  10. 10. Les 3 premiers mois Dashboard
  11. 11. Les 3 premiers mois Burn Down Chart
  12. 12. Les 3 premiers mois Le bilan Dérive des artefacts scrum (manque le burndown chart, pas de reporting). Vision positive de l'agilité. Apport bénéfique sur l'équipe, le Product Owner et les contacts extérieurs.
  13. 13. Les 3 premiers mois Plan d'action Mise en place de reporting et d'indicateur. Intervention extérieur coach agile. Changement de scrum master.
  14. 14. De 3 à 6 mois Mise en place d'un ScrumMaster plus rigide. Application des cérémoniaux scrum intégralement. Mise en place d'un outil en ligne (IceScrum puis Jira/ Greenhopper). Travail sur le Definition of Done, le formalisme d'une story / tâche. Changement dans l'équipe (éviction des éléments perturbateurs).
  15. 15. De 6 mois à un 1 an Dashboard
  16. 16. De 6 mois à un 1 an Burn Down Chart
  17. 17. De 6 mois à un 1 an Burn Down Chart
  18. 18. De 3 à 6 mois Le bilan Remise en cause de l'agilité par l'équipe. Coups de mou, la méthode est dans le dur. Turn over dans les équipes. Mise en place de scrumban. Mutualisation scrum master Réflexion sur un contrat Scrum
  19. 19. De 6 à 9 mois Débat et intégration de l'équipe sur la méthode de travail. Clarification des rôles de chacun. Sortie régulière d'éléments livrables.
  20. 20. De 6 à 9 mois Dashboard Scrumban
  21. 21. De 6 à 9 mois Burn Down Chart
  22. 22. De 6 à 9 mois Rien n'est jamais acquis
  23. 23. De 6 à 9 mois Burn Down Chart
  24. 24. De 6 à 9 mois Le bilan 3ème scrum master. Equipe rodée. Perte du product owner. Non adoption au niveau entreprise (manque de visibilité planning pour la direction). Mieux expliquer les intérêts et les limites.
  25. 25. Dans le monde de l'entreprise
  26. 26. La gestion des anomalies et des urgences Les bug et les demandes urgentes. Ajout d'une ligne Bugfix sur le dashboard (Scrumban). Remplissage des sprints entre 50% et 80%. Point de contention. Pédagogie nécessaire pour expliquer le fonctionnement des sprints.
  27. 27. Les livraisons à l'exploitation Difficile sur les premiers sprints. Ajout d'un tâche récurrente de packaging sur chaque sprint. Capacité à livrer à chaque sprint sur les 3 derniers mois. Nécessité d'un rôle à part de type "Devops" pour le support à l'exploitation.
  28. 28. L'architecture En cycle V : mise à l'épreuve au bout de 4 à 6 mois. En scrum, c'est au bout de 2 sprints (1 mois). Une plus grande implication des développeurs. Plus de débats, plus d'ajustements. Une architecture améliorée. Davantage de place pour du refactoring.
  29. 29. Au sein de l'organigramme Conflits entre Chef de projet MOA et Product Owner. Conflits entre Chef de projet PMO et Scrum Master. Des dates versus un engagement sur une première itération. Conflit permanent entre les scolaires GANTT/PERT et Scrum. 1er règle de Claude Emond : "Ne jamais donner de date."
  30. 30. Bilan
  31. 31. Le point de vue des développeurs Les avantages La responsabilisation des développeurs : ○ Une plus grande marge de manoeuvre. ○ Pas de sur-spécifications. Un meilleur esprit d'équipe : ○ Plus d'intéractions. ○ Equipe plus facile à intégrer pour les nouveaux. ○ Equipe plus homogène. Un meilleur pragmatisme : ○ Les dérives sont détectés au plus tôt. ○ Capacité de corriger au plus vite. Confort d'un périmètre stable sur un sprint.
  32. 32. Le point de vue des développeurs Les inconvénients Lourdeurs des cérémoniaux. Manque de formalisation/spécifications. Difficulté d'intégration des développeurs sur un autre site ou en télétravail. Plus difficile quand un développeur est sur un autre projet.
  33. 33. Le point de vue des développeurs Bilan Les interactions avec le Product Owner est le point le plus important. Quid de l'opportunité de Kanban?
  34. 34. Le point de vue du directeur Les avantages Fin des effets tunnels sur les projets. Evaluation rapide des résultats, moins de gaspillage de ressources. Constitution d'une équipe cohérente après plusieurs mois.
  35. 35. Le point de vue du directeur Les inconvénients Exacerbation des tensions existantes au sein de l'équipe. Règle des cérémoniaux trop strict. Gros impact si le product owner et/ou le scrum master sont défaillants (pas propre à Scrum). Gros besoin d'évangéliser les autres services pour faire comprendre le changement d'habitude.
  36. 36. Le point de vue du directeur Bilan et Conseils Meilleur résultat qu'un cycle en V. Ne pas subir l'auto-gestion de l'équipe mais imposer des règles. Choisir un Scrum Master et un Product Owner avec de l'expérience (ou se faire accompagner). Ne pas hésitez à remplacer les membres de l'équipe qui n'adhèrent pas.
  37. 37. Notre point de vue Les difficultés L'adoption dans la durée et dans toutes les strates. La communication transparente sur les gains possibles et les limites. La mise en place sur un existant. La gestion des égos dans l'équipe.
  38. 38. Notre point de vue Les points positifs Responsabilisation des équipes. Une meilleure homogénéité des compétences. Davantage de confiance dans les relations MOA/MOE. Des livraisons régulières.
  39. 39. Conclusion et perspectives
  40. 40. Gains espérés versus obtenus Gain Objectif Obtenu Compétence de Meilleur homogénéité Augmentation des compétences. Homogénéisation. l'équipe Time To Market Plus de livraisons. Mais pas synchro. Implication des Au bout de 8 mois. développeurs Transparence Echec vis à vis des autres services Traitement des Focalisation sur la résolution plutôt que sur les coupables. Meilleur réactivité problèmes avec Scrumban.
  41. 41. Leçons apprises Rien n'est acquis. Constituer une équipe est difficile. L'agile doit aller au delà du service informatique. Scrum n'est pas l'unique méthode agile (adaptez au contexte).
  42. 42. Conseils Une pause d'une semaine pour relâcher la pression après une série de sprints. La technique "En tant que .., je .." marche très bien pour les demandes avec UI mais pas pour du middleware. Evangéliser, Evangéliser, Evangéliser!
  43. 43. Perspectives Kanban ? Scrumban ?
  44. 44. Crédits Images Equipe de France - Grève des joueurs | Reuters/© Charles Platiau / Reuters http://www.flickr.com/photos/paddymccann/417406760/ http://www.flickr.com/photos/photorobw/2673808472/ http://www.flickr.com/photos/thomaslevinson/3602997478/ http://www.flickr.com/photos/catmurray/1687104755/ http://www.flickr.com/photos/maxiwalton/5060384810/ 13 octobre 2011

×