AGILE & SCRUM

Bonjour,
Certains d’entre vous sont très certainement au fait de la méthodologie Agile SCRUM, mais est-ce le cas de tout le monde ? C’est pour cela que nous aimerions vous sensibiliser à cette méthode afin que vous participiez de bon coeur à nos rituels (Sprint Review et Sprint Planning).
Je ne vais pas ici vous énumérer l’ensemble des points cités sur la page Wikipédia dédiée au sujet. Je vais simplement vous informer de la manière dont nous fonctionnons chez ISTEX (ISTEX-API, ISTEX-DATA et ISTEX-RD).

Les méthodes agiles consistent à travailler en cycle itératifs courts. SCRUM est, depuis 1996, une des nombreuses méthodes agiles existantes. L’agilité, comme nous l’appelons, est l’alternative moderne au cycle en V.
Plutôt que de constituer un cahier des charges, nous constituons un « Product Backlog », qui liste de manière exhaustive, mais grossière, les fonctionnalités du projet. Contrairement au cahier des charges, ce Product Backlog n’est pas figé ! En tant qu’utilisateur, vous pouvez vous adresser au « Product Owner », afin qu’il ajoute votre besoin sous forme de fonctionnalité que vous désirez voir dans le projet, au Product Backlog. De la même manière, si durant la vie du projet, une fonctionnalité n’est plus jugée utile par nos utilisateurs, nous pouvons décider la retirer du Product Backlog. Une fonctionnalité est décrite en « User Story » sous cette forme :

En tant que chercheur de l’API ISTEX, je souhaite pouvoir interroger cette dernière afin d’obtenir la liste des ressources possédant des références bibliographiques natives, non enrichies.

Le Product Owner est le représentant des utilisateurs au sein de l’équipe. C’est lui qui synthétise et priorise les fonctionnalités, en fonction des besoins des utilisateurs (vous), et c’est lui qui maintient le Product Backlog. C’est également lui qui maintient le cap de l’équipe afin qu’elle reste focalisée sur les objectifs qu’elle s’est fixée.
Un « Sprint » est une itération au cours de laquelle nous développerons un MVP (Minimum Valuable Product : Produit Minimum Viable), ce qui signifie qu’à la fin de chaque sprint, nous apportons une plus-value utilisable en l’état. Pour l’équipe ISTEX-API, cela s’illustre par une nouvelle version de l’API à la fin de chaque Sprint. Voici comment illustrer au mieux l’itération dans la vie du projet, certains d’entre vous on peut-être déjà vu ce schéma très populaire :

Un Sprint dure de 3 à 4 semaines en général, mais ceci varie d’une équipe à l’autre, et en fonction des User Stories qui composent le « Sprint Backlog ».
Le Sprint Backlog est composé des User Stories issue du Product Backlog qui auront été priorisées par le Product Owner, conjointement avec les utilisateurs (vous) au cours du « Sprint Planning ». Le Sprint Backlog, lui, est figé. Dans un autre contexte, c’est cet élément qui peut être contractualisé.
Le Sprint Planning c’est le moment où les utilisateurs rencontre l’équipe, soit en face-à-face, soit en visioconférence pour les plus éloignés, afin d’exprimer leurs besoins et leurs souhaits pour le Sprint suivant. Ils s’appuient sur le Product Backlog afin de conserver la même ligne directrice. Dans la foulée, la Scrum Team (nous) va se réunir pour la seconde partie du Sprint Planning : Le découpage et l’estimation.
Le découpage et l’estimation consistent à découper l’ensemble des User Stories prévues au cours du Sprint en tâches, le plus finement possible, et de leur attribuer une valeur en fonction de leur complexité, en termes de temps et d’efforts. Le Product Owner priorise et l’équipe de développement découpe et estime. Les équipes qui n’en sont pas à leur premier Sprint connaissent ainsi leur Vélocité, c’est à dire, la quantité de complexité de l’ensemble des tâches qu’ils peuvent réaliser en un Sprint. Si les Sprints sont à durées variables, mieux vaut se baser sur une vélocité journalière afin que le Product Owner n’engage pas l’équipe sur un objectif de Sprint trop ambitieux. Si l’équipe estime que le Product Owner voit trop gros, alors un nouvelle personne intervient : Le « Scrum Master » :

Le Scrum Master est le garant de la méthode SCRUM. Son rôle peut se résumer assez simplement : Il protège son équipe et l’aide à se focaliser sur leur objectif. Il possède pour cela d’outils comme la rétrospective. Si le Scrum Master est un serveur d’intégration continue, alors la rétrospective est le “build” qui permet la non-régression. En termes moins barbares, la rétrospective c’est le moment où l’équipe se focalise sur ses forces et ses faiblesses afin de s’améliorer et d’être plus performante, et plus soudée. Le Scrum Master aide également le Product Owner à ne pas se transformer en chef de projet qui met la pression à son équipe. Oui, car dans l’agilité, il n’y a pas de hiérarchie… Enfin dans l’idéal. Le Product Owner n’ordonne pas, il prévoit, il prépare. Le Scrum Master n’est pas non plus au dessus de son équipe, tout au contraire, il la préserve et lui permet de se focaliser sur ses objectifs sans être perturbée, y compris par le Product Owner. Je n’entrerais pas plus dans les détails dans ce billet. Je retourne donc à l’essentiel et il s’agit là de la principale raison de ce billet.
Une fois le Sprint terminé et que l’objectif que l’équipe s’était fixé lors du Sprint Planning a été réalisé, l’équipe le présente aux utilisateurs (vous) lors de la Sprint Review. La Sprint Review, ou « revue de sprint » est un moment particulièrement important, car c’est l’instant où nous allons pouvoir récolter vos Feedback : vos commentaires et vos suggestions. Ceci nous confortera ou nous réorientera dans nos objectifs ou notre façon réaliser nos développements.
Voilà pour le petit tour d’horizon de la méthodologie de travail au sein d’ISTEX. Mais je n’ai pas écrit ce billet de manière désintéressée. Il est primordial pour l’avenir du projet ISTEX que nos utilisateurs se manifestent et soient actifs à l’aide de petits retours concrets et réguliers durant la phase de développement. C’est pourquoi nous avons besoin de vous lors des Sprint Planning, afin de nous dire ce que VOUS voulez dans ISTEX. Mais, plus important encore, nous avons également besoin de vous lors des Sprint Review afin de savoir ce que vous pensez de notre travail et comment nous améliorer.
Une grande partie de notre méthodologie de travail repose sur vous, nos utilisateurs, elle a été créée pour vous. La fréquence de nos Sprint Planning et Sprint Review est telle que nous vous donnons le maximum d’opportunité de rectifier le tir si nous allons dans la mauvaise direction.
Merci pour votre temps, nous espérons vous voir le 5 juillet 2016 à 9:30 à l’INIST-CNRS ou en visio-conférence.

• agile
• scrum