View
782
Download
3
Category
Preview:
DESCRIPTION
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.
Citation preview
Scrum dans les tranchées normandes
Youen Chene, Anthony Hurot
Rouen - 13 octobre 2011
13 octobre 2011
Partenaires Gold
Partenaires logistique
13 octobre 2011
Vos intervenants
Anthony Hurot
Scrum MasterMasternaut
Youen Chéné
ArchitecteMasternaut
Mise en place de l'agilité
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.
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.
Gains espérés
Gain ObjectifCompétence de l'équipe Meilleur homogénéité
Augmentation des compétences.Time To Market
Implication des développeursTransparence
Traitement des problèmes
Focalisation sur la résolution plutôt que sur les coupables.
Pratiques cibles
Scrum
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.
Les 3 premiers moisDashboard
Les 3 premiers moisBurn Down Chart
Les 3 premiers moisLe 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.
Les 3 premiers moisPlan d'action
Mise en place de reporting et d'indicateur.
Intervention extérieur coach agile.
Changement de scrum master.
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).
De 6 mois à un 1 anDashboard
De 6 mois à un 1 anBurn Down Chart
De 6 mois à un 1 anBurn Down Chart
De 3 à 6 moisLe 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
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.
De 6 à 9 moisDashboard
Scrumban
De 6 à 9 moisBurn Down Chart
De 6 à 9 mois
Rien n'est jamais acquis
De 6 à 9 moisBurn Down Chart
De 6 à 9 moisLe 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.
Dans le monde de l'entreprise
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.
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.
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.
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."
Bilan
Le point de vue des développeursLes 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.
Le point de vue des développeursLes 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.
Le point de vue des développeursBilan
Les interactions avec le Product Owner est le point le plus important.Quid de l'opportunité de Kanban?
Le point de vue du directeurLes 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.
Le point de vue du directeurLes 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.
Le point de vue du directeurBilan 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.
Notre point de vueLes 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.
Notre point de vueLes 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.
Conclusion et perspectives
Gains espérés versus obtenus
Gain Objectif ObtenuCompétence de l'équipe
Meilleur homogénéitéAugmentation des compétences.
Homogénéisation.
Time To Market Plus de livraisons. Mais pas synchro.
Implication des développeurs
Au bout de 8 mois.
Transparence Echec vis à vis des autres services
Traitement des problèmes
Focalisation sur la résolution plutôt que sur les coupables.
Meilleur réactivité avec Scrumban.
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).
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!
Perspectives
Kanban ?Scrumban ?
Crédits Images
Equipe de France - Grève des joueurs | Reuters/© Charles Platiau / Reutershttp://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
Recommended