Tarmax.com : Sélestat, course à pied, géocaching, questions existentielles, fun...

Nouvelles technologies, Sélestat, Course à pied, Biosphères maison, Géocaching, Questions existentielles, Fun et divers. Rédacteur : Maximilien G.

Keyword - sprint

Scrum : petit bilan après 12 sprints déjà écoulés

bilan-scrum.jpgCela fait déjà 12 sprints de 2 semaines, soit près de 6 mois, que nous avons mis en pratique Scrum dans l'équipe informatique où je travaille. Qu'est ce que ça nous apporté ? Quelles difficultés avons nous rencontrées ? Il est temps de faire un premier bilan.


Nos légères adaptations

Au sujet de Scrum, nous avons apporté quelques adaptations. Notamment, nous avons rapidement mis de côté la notion de release car elle ne s'adaptait pas à notre projet ni au rythme de notre entreprise. Je reste persuadé toutefois que la faute vient d'un problème d'organisation interne. Nos difficultés à gérer cette notion n'ont fait que dévoiler ce problème qu'il va nous falloir corriger.

Sinon, en première instance, j'ai été tenté de mettre en place directement un mix entre Kanban et Scrum (c'est la forte tendance du moment) mais nous nous sommes rendus compte qu'il valait mieux d'abord se concentrer uniquement sur Scrum pour bien l'assimiler et attendre plus de temps avant de le mixer avec une autre méthodologie. Finalement ce mix "Kanban Scrum" n'est plus apparu comme une priorité ces derniers temps et a donc été reporté dans l'attente d'en ressentir réellement le besoin.


Outils utilisés

Pour ce qui est de l'outil de gestion du backlog j'ai fait le choix d'utiliser ScrumNinja qui s'avère très pratique et suffisant tant que l'on essaye pas de tout gérer avec. On s'en sert au niveau stories sans aller jusqu'à celui des tâches.


Les points positifs

Tout d'abord Scrum a profondément modifié notre manière de travailler et de nous organiser. L'une des meilleurs choses est que ça nous a restructurés et nous a permis d'installer un vrai rythme régulier dans notre quotidien. Planifications de sprint, scrums quotidiens, revues de sprint, rétrospectives de sprint, tous ces jalons font désormais parti de notre vie professionnelle et ont complètement été assimilés par l'ensemble de l'équipe.

La notation en points de chaque story nous a permis de mieux nous connaître et de faire des prévisions de plus en plus juste avec le temps. Le tableau des tâches est un outil idéal pour savoir ce qu'il nous reste à faire et est aussi fort utile à la direction quand celle-ci passe nous voir pour prendre des nouvelles. L'archivage à chaque sprint de nos divers documents permet d'avoir un réel historique, simple d'accès, de tout ce que nous faisons. Les scrums quotidiens nous forcent à communiquer quotidiennement et la prise de note systématique lors de ces derniers permet aux personnes qui reviennent de vacances de savoir exactement tout ce qu'il s'est passé durant leur absence. Enfin, comme déjà expliqué dans un autre article, les rétrospectives de sprint, tous les 15 jours dans notre cas, sont l'occasion idéale de faire des mini bilans et de définir des pistes d'amélioration.


Les points négatifs

Il a fallu que les autres services et que la direction "se plient" à notre nouvelle organisation mais heureusement cela s'est fait sans grande difficulté. Tous ont rapidement détecté tout ce que Scrum nous a apporté et personne n'est venu remettre en cause notre décision de l'adopter.

Scrum implique de la rigueur et fonctionne mal dès que l'on n'y consacre pas du temps où dès qu'on le laisse de côté pour cause de vacances ou de surmenage. Si par exemple des scrums quotidiens sont sautés ou le burndown chart de sprint non mis à jour pendant un laps de temps, toute la revue et la rétrospective du sprint en question vont s'en voir pénalisées.

Enfin si une personne de l'équipe met de la mauvaise volonté ou fait preuve de mauvaise humeur de manière récurrente, les contacts réguliers avec l'ensemble de l'équipe font qu'il est impossible de l'isoler et de protéger les autres membres de cette source de démotivation.


En conclusion

Scrum est un réel "plus" qui a métémophosé notre organisation. Vu le rapport avantages/inconvénients très positif que nus tirons de ce bilan il n'y a aucune raison que nous ne continuions pas dans cette voie. Reste à voir si l'avenir le permettra.

L'importance des résolutions prises lors des rétrospectives de sprint

L'un des points les plus positifs de Scrum est le bilan que l'on fait à chaque fin de sprint à l'occasion de la rétrospective de sprint. Une occasion unique de mettre en valeur ce qui a bien marché et ce qui a moins bien marché.

Cela permet de faire le point de manière régulière sur les méthodes de travail et l'organisation mises en places. Tous les 15 jours dans notre cas. Je propose systématiquement de terminer une rétrospective de sprint par un retour sur les résolutions prises lors des 2-3 derniers sprints et de définir en commun avec tous les membres de l'équipe les nouvelles résolutions que l'on pourrait mettre en place.


liste-de-resolutions-de-fin-de-sprint.jpg


Comprendre ce qui a échoué ou ce qui pourrait être amélioré et y apporter des réponses, voilà la clé de la réussite. Les avis personnels de chaque membre de l'équipe et les burndonw charts de sprint font parti des outils essentiels pour analyser et comprendre ce qui n'a pas bien fonctionné.

Ci-dessous quelques exemples de résolutions que nous avons prises à l'occasion de nos 4 premiers sprints :

  • Utilisation comme support des post-it d'un tableau assez grand (1m20 sur 90cm) mais "portatif" (non fixé au mur) afin de pouvoir le transporter avec nous dans nos différentes lieux de réunions.
  • Extinction de tous les moniteurs pendant les scrums quotidiens, cela afin de ne pas se laisser perturber pendant le scrum. Seul celui qui tape le résumé du scrum pour archivage a le droit d'avoir son écran allumé.
  • 1 scrum quotidien = 2.5 minutes maximum par personne. Chronométrer et stopper l'intervention de la personne si le temps est dépassé. Résolution mise en place après avoir constaté que les scrums prenaient de plus en plus de temps. Après avoir été interrompue une ou deux fois la personne prendre l’habitude de préparer son intervention à l'avance et du coup saura résumer plus facilement en 2 minutes 30 sa journée d'hier, ces problèmes et ce qu’elle compte faire aujourd'hui. Au bout d'1 seul sprint, tout le monde a pris l'habitude de respecter le temps qui lui est donné et cette mesure nécessaire au départ devient donc obsolète.
  • Fermer les rideaux des cloisons intérieures lors des réunions. La multiplication des réunions de notre service (planification de release, planification de sprint, revue de sprint, rétrospective de sprint...) a tendance à faire "jaser" les personnes en dehors de l'équipe qui ont parfois du mal à intégrer leurs bienfaits malgré nos explications. Qu'à cela ne tienne, c'est en parti compréhensif. Il suffit de ne pas faire ses réunions à la vue de tout le monde.
  • Utiliser des couleurs différentes pour les post-it du tableau en fonction des types de tâches. Afin de permettre une meilleure analyse de la situation et une meilleure rétrospective nous avons décidé d'utiliser plusieurs couleurs de post-it sur notre tableau : vert pour les tâches initiales définies lors de la planification de sprint, bleu pour les bugs critiques ou majeurs intégrés au sprint, rose pour les demandes extérieurs impossible à refuser, jaune pour les ajouts fait volontairement en cours ou en fin de sprint en fonction du déroulement de ce dernier. La visibilité et la compréhension du sprint s'en voient grandement accrues.
  • Mise en place de gomettes sur tâches nécessitant une intervention ou un besoin extérieur à l'équipe (document, contact, information). Cette résolution a été prise après avoir constaté que certaines tâches n'étaient pas terminées en fin de sprint car on n'avait pas reçu en temps et en heure certains éléments. Afin d’anticiper les retards indépendant de notre volonté les tâches avec gomette sont traitées en début de sprint indépendamment de la priorité de leur story par rapport aux autres.
  • Ajout de la légende des couleurs des post-it au tableau. Plus besoin de réfléchir pour se rappeler la signification des couleurs.
  • Tirage au sort en début de chaque scrum quotidien pour désigner la personne qui va jouer le rôle de secrétaire (résumer ce qui est dit à l'écrit dans un fichier) et d'organisateur (définir l'ordre de passage des participants, touche personnelle...). Moins de monotonie et donc plus de motivation.
  • Mieux définir l'état "fini" des tâches lors de la planification de sprint.


Bien entendu les résolutions prises par une équipe sont propre à cette équipe, à son fonctionnement et à son ressenti. Il ne serait bien évidemment pas judicieux de prendre ces exemples comme "vérité absolue" et de vouloir les imposer à une équipe différente de la nôtre. C'est à chaque équipe de définir ses propres résolutions, petite à petit (ne pas tout révolutionner d'un coup), en fonction de son expérience.

Premier sprint SCRUM lancé ce matin

C'est parti !

Aujourd'hui est un grand jour. Nous avons lancé au travail notre tout premier sprint SCRUM. Vous ne connaissez pas SCRUM ? Pas de panique, je prévoie prochainement un article de présentation. Sachez juste pour le moment que SCRUM est une méthode dite "Agile" de gestion de projets présentant de nombreux avantages.

Pourquoi SCRUM ?

Après avoir expérimenté sans trop de résultat une méthode plus proche de Kanban ces dernières semaines, c'est dans SCRUM que nous nous lançons désormais.

Première planification de release il y a quelques jours, mise en place des scrums quotidiens, première planification de sprint ce matin et enfin premiers burndown charts cet après midi, le programme est chargé mais plein de promesses.

Malgré mon rôle de Responsable Développement Informatique, j'avoue ne pas avoir pris le temps d'instaurer une vraie méthode de gestion de projets depuis mon arrivée dans ma boite actuelle il y a presque un an. Pourquoi ? Simplement afin de faire face aux premières actions urgentes à mener nécessitant mon implication à 100% dans le développement avec le reste de l'équipe. Je me suis contenté de mettre en place des réunions hebdomadaires et divers processus inspirés de méthodes variées. Cela est bien évidemment une erreur et il était temps d'y remédier.

Suite à la suggestion d'un membre de l'équipe de mettre en place SCRUM et après en avoir étudié de manière avancée le fonctionnement et l'avoir comparé de manière pratique ou théorique avec d'autres méthodes de gestion de projets (Kanban, eXtreme Programming..) j'ai décidé de le mettre en place en cette toute fin d'année 2010.

Ce nouveau départ se fait sans avoir suivi de formation spécifique pour le moment, même si j'espère pouvoir en faire organiser une prochainement dans nos locaux après qu'on se soit fait une première expérience sur quelques sprints pour mieux en profiter. L'excellent ouvrage SCRUM : Le guide pratique de la méthode agile la plus populaire rédigé par Claude Aubry nous sert de "référence" et divers autres documents glanés ici ou là sur Internet viennent compléter ce guide de mise en route.

Notre premier sprint en quelques chiffres

Durée de 2 semaines, 4 développeurs, 2 stories représentant à elles deux 9 tâches auxquelles il faut ajouter 3 tâches storyless et 7 tâches répétitives, soit un total de 19 tâches.

L'ensemble des tâches ont un Reste A Faire initial de 169 heures à répartir sur un temps de travail effectif réduit à 29 jour/homme au lieu de 34 à cause des congés pris par divers membres de l'équipe. Le poids total des stories est de 20 points, ce qui nous donne une vélocité de 23 points sur un sprint sans congé ni jour férié (25 si aucun membre de l'équipe n'était à temps partiel).

On verra dans le futur si nos premières estimations s’avéreront précises.


tableau_sprint_01.jpg

Vue du tableau après la planification de Sprint


A suivre...