Demandez à un développeur le nom de la méthode agile qu’il connaît le mieux, sa réponse sera sans aucun doute « Scrum ». Si elle n’est pas la seule méthode agile, elle est celle qui est la plus utilisée pour les projets de développement informatique. Comme dans les autres méthodes agiles, les phases de développement sont itératives et de courtes durées (généralement entre deux et quatre semaines). En scrum, une itération de développement s’appelle un « sprint ». Nous allons donc voir ici comment se définit un sprint agile, son organisation, de sa préparation à sa conclusion, et nous nous arrêterons sur le cas particulier du « sprint 0 ».
Comment définir le sprint agile ?
Le Guide Scrum décrit le sprint agile comme étant le cœur de la méthode scrum. Cette qualification lui correspond plutôt bien, puisque tous les développements incrémentaux menant petit à petit au produit final du projet sont réalisés au sein des sprints.
Un périmètre de développement (liste de fonctionnalités, évolutions, corrections à apporter au code existant…) est définit au début d’un sprint et doit être entièrement réalisé lorsqu’il se termine. Ainsi, lorsque l’équipe projet arrive à la conclusion d’un sprint, un autre commence, et ainsi de suite jusqu’à qu’un produit fini répondant parfaitement aux besoins du client puisse être livré.
Préparation du sprint
La préparation du sprint se fait en présence de l’ensemble de l’équipe projet et du « product owner ». La première action consiste à se mettre d’accord sur un planning. C’est à ce moment que débute réellement le sprint.
Durant cette réunion de préparation, l’équipe doit s’assurer que le « product backlog » est suffisamment fourni et détaillé. C’est le rôle du « product owner » de structurer efficacement le « product backlog » et d’opérer à une première sélection des fonctionnalités demandées. Les objectifs à réaliser durant le sprint peuvent ensuite être discutés et décidés avec l’ensemble de l’équipe.
Afin de sélectionner les fonctionnalités présentes dans le backlog qu’il faudra réaliser durant le sprint, elles sont examinées et leur description affinée si besoin.
Pour mener à bien cette sélection, il est important que l’équipe ait conscience de sa vélocité, c’est-à-dire de la capacité de travail et de développement qu’elle pourra absorber durant le sprint. Cette connaissance est basée notamment sur l’expérience acquise durant les sprints précédents. Il est évident qu’elle sera plus difficile à évaluer au début d’un projet pour une équipe qui ne se connaît pas. Ce n’est qu’au bout de plusieurs sprints, les membres de l’équipe ayant appris à se connaître et à travailler ensemble, que l’on sera capable de déterminer une vélocité moyenne stable et réaliste. Elle s’affinera au fur et à mesure des sprints jusqu’à se stabiliser.
Astuce : Le graphique de vélocité de Nutcache aide l’équipe de développement lors des séances de planification de sprint à évaluer la quantité de travail qu’elle peut sélectionner pour le nouveau sprint.
Périmètre et planification du sprint
Chaque sprint doit apporter des fonctionnalités supplémentaires à l’application en cours de développement qui doivent être livrées lorsqu’il se termine. C’est au « product owner » de définir le périmètre du sprint et d’organiser le « backlog product » de façon à faciliter la construction du produit au fur et à mesure des sprints, en définissant des priorités de réalisation.
La décision d’inclure telle ou telle fonctionnalité dans le sprint courant est ensuite prise collectivement, durant la réunion de planification du sprint. De cette façon, la cible à atteindre pour la livraison à la fin du sprint est parfaitement définie. Néanmoins, pour arriver à cette définition du périmètre du sprint courant, il est impératif que l’effort nécessaire à la réalisation de chaque fonctionnalité ait été estimé auparavant par l’équipe scrum. Il sera alors possible de le comparer à la vélocité de l’équipe. L’ensemble des fonctionnalités embarquées dans le sprint doit être cohérent pour ne pas obtenir simplement des fonctions déconnectées les unes des autres, mais bien une partie testable et évaluable de l’application finale.
A l’issue du sprint, il doit être possible de présenter une démonstration des fonctionnalités développées, et de leur intégration dans les parties issues des sprints précédents.
Le sprint agile : une méthode de travail
Il ne s’agit pas uniquement de piocher des éléments dans le « backlog » pour constituer un sprint. Il faut avant tout définir une planification pour déterminer de quelle façon les objectifs fixés pourront être atteints. La sélection et l’organisation des tâches à réaliser sont donc deux étapes clés de la méthode de travail en sprints. L’équipe de développement doit donc établir une véritable stratégie pour la réalisation technique des différentes fonctionnalités en se basant sur les estimations effectuées en amont. Si le « product owner » ne participe pas directement à l’élaboration de cette stratégie, il doit néanmoins être disponible à cette étape afin de répondre à toute question que pourrait encore se poser les développeurs.
A l’issue de l’étape de planification, l’équipe projet dispose d’une estimation réaliste de la quantité de travail nécessaire à la réussite du sprint. Les travaux peuvent démarrer immédiatement et chacun a une vision claire de l’effort à fournir jusqu’à la fin du sprint. L’ensemble des fonctionnalités embarquées dans l’itération courante constitue le « sprint backlog ».
Durant tout le déroulement du sprint, le « sprint burndown » va permettre à tous de suivre l’évolution des différents travaux attribués individuellement aux membres de l’équipe de développement. Chacun peut ainsi s’assurer que les différentes tâches sont terminées dans les temps. Tout développeur dispose de son propre tableau d’avancement et le « sprint burndown » indique le travail qu’il reste à faire avant la fin de l’itération.
Le déroulement d’un sprint agile
Dès le démarrage du sprint, après la réunion de planification, l’équipe de développement va pouvoir se consacrer entièrement à la réalisation des fonctionnalités définies dans le « sprint backlog ».
Un certain nombre de réunions vont venir ponctuer le sprint de façon à contrôler plus facilement son déroulement.
Une réunion quotidienne (ou « daily scrum ») est organisée. Elle ne doit pas durer plus de 15 minutes et se déroule debout. C’est sans aucun doute la meilleure façon pour que la réunion ne dure pas plus longtemps. Chacun à son tour explique ce qu’il a accompli la veille, les problèmes éventuels qu’il rencontre, et ce qu’il a prévu de réaliser le jour même. C’est une méthode très efficace pour faire un point complet sur l’avancement des travaux en cours. Tout le monde est au même niveau d’information, et si quelqu’un a une solution à un problème exposé, il peut apporter son aide pour le résoudre. De cette façon, un développeur ne restera pas longtemps bloqué, car n’importe quel membre de l’équipe en aura connaissance et sera à même de l’aider.
Cette réunion quotidienne va également permettre d’identifier rapidement tout retard dans la réalisation des tâches. Si ce retard risque de mettre en péril la livraison prévue à la fin du sprint, des fonctionnalités moins prioritaires peuvent être retirées du « sprint backlog ». Elles pourront alors être réintégrées dans le sprint suivant. De la même façon, si certaines tâches sont terminées plus rapidement que prévu, des fonctionnalités du « product backlog » peuvent être ajoutées au « sprint backlog ».
Le sprint comprend l’ensemble des phases de réalisation des fonctionnalités, de la conception jusqu’aux tests unitaires et fonctionnels. Contrairement à une méthode classique, où l’ensemble des fonctionnalités sont spécifiées et décrites avant le début des développements, la conception se fait au fur et à mesure des sprints. Il est donc beaucoup plus simple de prendre en compte des changements dans les besoins du client, ou de trouver des contournements à d’éventuels blocages techniques. Chaque tâche doit être terminée, testée et documentée avant qu’une autre ne débute. La parallélisation des développements et la programmation par paire sont des solutions particulièrement efficaces pour le bon déroulement du sprint.
Un outil indispensable : le scrum board, ou tableau des tâches
Ce tableau, qu’il soit physique (un tableau blanc ou un grand espace libre sur un mur séparé en colonnes) ou numérique (affichage sur un grand écran), est positionné de façon à être visible en permanence par l’ensemble de l’équipe de développement. Son but est d’offrir à tout moment une vision claire du travail à faire, des tâches en cours, de leur répartition entre les membres de l’équipe, et des développements terminés.
Il est généralement séparé en trois ou quatre colonnes : les tâches à faire, les tâches attribuées et en cours de réalisation, les développements réalisés à tester et les développements terminés.
Chaque tâche du sprint est modélisée par un post-it (physique ou virtuel). Plusieurs couleurs peuvent être utilisées pour refléter différentes catégories (il peut s’agir de notions d’architecture, de technologies, d’urgence…).
Au début du sprint, la première colonne est évidemment la plus remplie. Au fur et à mesure que les développeurs progressent dans leurs tâches, ils déplacent le ou les post-it correspondants de colonne en colonne. Lorsqu’une tâche arrive dans la dernière colonne, elle est terminée, et il est possible d’en commencer une autre. Si pour une raison ou pour une autre, une tâche est bloquée, une autre pourra être menée en parallèle. L’important est qu’à la fin du sprint, l’ensemble des tâches placées à l’origine dans la première colonne, se retrouvent dans la dernière (à moins qu’une ou plusieurs tâches n’aient été reportées à un sprint suivant).
Si le changement de statut des tâches peut être réalisé à tout moment par un développeur, c’est généralement lors de la réunion quotidienne, le « daily meeting » ou « daily scrum », que le tableau est mis à jour.
Le tableau permet d’avoir une vision globale de la progression des développements dans le sprint courant. L’affectation des tâches est simplifiée, et les décisions reviennent aux membres de l’équipe de développement, et non pas à un chef de projet comme avec une méthode de gestion classique. Ce sont les développeurs qui s’assurent de l’avancement des travaux et qui conservent le pouvoir de les organiser.
La conclusion d’un sprint
A la fin du sprint, une réunion de démonstration est organisée. C’est l’occasion pour l’équipe de présenter ce qui a été réalisé durant le sprint. Les experts métier et les utilisateurs finaux sont naturellement conviés, et peuvent ainsi vérifier et valider que ce qui a été développé correspond bien à ce qui était demandé. Ils peuvent à ce moment-là faire différentes remarques et demandes de modifications qui pourront être prises en compte ou non dans les prochains sprints.
Une dernière réunion a lieu en toute fin de sprint : la rétrospective agile. C’est l’occasion pour tous de s’exprimer librement et d’expliquer ce qui s’est bien passé et ce qui s’est moins bien passé durant le sprint. Il peut s’agir des conditions de travail, de la façon de communiquer entre l’équipe et le client ou au sein même de l’équipe, des choix technologiques, des outils de travail… Cette réunion est la pierre angulaire de ce qui fait l’une des forces de la méthode agile scrum : l’amélioration continue. Des actions peuvent alors être décidées pour renforcer ce qui s’est bien passé, et pour corriger les éventuels problèmes rencontrés, afin que les prochains sprints soient encore plus efficaces et productifs.
Un cas particulier, le sprint 0
Le sprint 0 est un peu particulier. Tout premier sprint du projet, aucune fonctionnalité ne sera livrée à son terme. Il faut plutôt le voir comme la construction d’un modèle sur lequel seront basés tous les sprints qui suivront.
Durant cette étape, l’ensemble des utilisateurs potentiels de la solution seront identifiés afin de collaborer avec eux pour dessiner le produit final. Les échanges entre le client et l’équipe scrum sont donc particulièrement intenses durant le sprint 0 car ils vont permettre de définir ce que sera l’application attendue à la fin du dernier sprint. L’ergonomie, les attentes en termes de sécurité et de fiabilité seront définies.
C’est à cette occasion également que la durée des sprints suivants va être définie, généralement de 2 à 4 semaines, chaque sprint ayant la même durée. De cette façon, il sera plus simple de mettre en place un rythme de travail, de faire adopter un certain nombre d’automatismes à l’ensemble de l’équipe projet, et de produire des indicateurs fiables pour le pilotage du projet. Les livraisons seront planifiées et le backlog produit pourra être rempli, avec une première estimation et priorisation des fonctionnalités attendues.
Les environnements de développement, de tests, d’intégration et de livraison sont mis en place à ce stade de façon à être pleinement opérationnels dès le début du sprint 1.
Le sprint 0, même s’il ne produit rien en termes de fonctionnalités, est le socle sur lequel vont s’appuyer l’ensemble des autres sprints, et le projet au final. On comprend donc qu’il a une place spéciale dans un projet agile et que son importance est cruciale.
La plupart du temps, le sprint 0 dure entre 3 et 4 jours.
Pour résumer
Un sprint est une itération de développement de la méthode Scrum. Il dure généralement entre deux et quatre semaines. Les fonctionnalités réalisées durant le sprint sont sélectionnées dans le « product backlog » renseigné par le « product owner ». L’équipe de développement se base sur leur estimation de la difficulté de réalisation des fonctionnalités pour définir des priorités. Un scrum master a pour rôle de faciliter le travail de l’équipe et de s’assurer qu’elle puisse avoir une productivité maximale en réglant les éventuels problèmes rencontrés. L’équipe de développement gère elle-même la répartition des tâches et la progression des travaux. Un sprint est ponctué de réunions au début pour la planification des tâches, quotidiennes pour l’avancement et à la fin, pour le bilan de ce qui s’est plus ou moins bien déroulé (revue de sprint dans le cadre d’un processus d’amélioration continue).
La solution de gestion de projet Nutcache fournit tous les outils nécessaires pour gérer au mieux les sprints agiles.
