Sprint : définition, du planning à la rétrospective

Chargement de votre vidéo
"Sprint : définition, du planning à la rétrospective"

Sprint : définition, du planning à la rétrospective [SPRINT AGILE] Conceptualisé par la méthode agile Scrum, un sprint informatique désigne le cycle de développement au cours duquel vont s'enchaîner un certain nombre de tâches pour, à terme, s'achever par la conception d'un produit final.

Un sprint agile, c'est quoi ?

S'inscrivant comme son nom l'indique dans le vocabulaire des méthodes agiles, un sprint agile renvoie à une phase séquentielle de développement d'un produit. On entend par sprint des itérations de courtes durées décomposant un processus de développement souvent complexe afin de le rendre plus simple et plus facile à réadapter et à améliorer en fonction du résultat des évaluations intermédiaires (voir le schéma ci-dessous).

Dans la logique des méthodes agiles, l'objectif est de commencer petit pour ensuite améliorer la première version d'un produit par petites itérations. Ce qui évite toute prise de risque trop importante. On sort de l'effet tunnel des projets de cycle en V qui se découpent en phases successives d'analyse, de spécification, de conception, de codage, et de test. Des chantiers qui se caractérisent par une livraison unique en bout de course, sans allers-retours intermédiaires avec les utilisateurs métier. Résultat : le produit risque de ne plus coller aux besoins du terrain qui auront pu évoluer dans l'intervalle.

Pourquoi travailler en sprint agile ?

Travailler par sprints de développement successifs présente plusieurs avantages. D'abord, ce process offre une meilleure  maîtrise de la valeur ajoutée et de la qualité du produit ou service final. Les itérations permettant de rectifier le tire à tout moment en fonction des retours clients. Un premier produit étant lancé rapidement, le retour sur investissement est aussi souvent plus rapide. 

Au final, le mode sprint contribue à accroître la satisfaction du client, qu'il soit utilisateur interne du produit ou client final. Ce dernier se sent pris en compte tout au long du process de développement.

Quand un sprint est-il terminé ?

En règle générale, la durée d'un sprint oscille entre une et quatre semaines.  La durée impartie pour la réalisation de chaque cycle va dépendre des tâches définies comme étant prioritaires et du temps jugé nécessaire par les membres de l'équipe de projet pour pouvoir les effectuer.

Un sprint a pour objectif de réaliser un composant du produit ou service ciblé, qui sera détaillé au sein d'un backlog. Au terme du sprint, l'élément en question devra avoir été réalisé.

Pourquoi parle-t-on de sprint Scrum ?

Si la notion de sprint est bien connue des équipes de développeurs, c’est parce qu’elle est la pierre angulaire de Scrum, la méthode agile actuellement la plus utilisée. D'où le qualificatif de sprint Scrum. Dans le cadre de cette méthode, le délai d'un sprint est déterminé par le Scrum master en concertation avec les autres membres de l'équipe.

Mais Scrum n'est pas la seule méthode agile à s'appuyer sur des itérations courtes de développement. D'autres méthodes agiles comme l'Extreme programming, le Feature-driven development ou le Crystal Clear fonctionnent également à partir de cycles de développement rapides équivalents aux sprints.

Les quatre étapes du sprint agile

1. Le sprint planning ou planification de sprint 

Le sprint planning renvoie à la réunion qui précède le début d’un sprint. Il s’agit d’une sorte de cérémonial assez codifié lors duquel le cycle de développement est organisé et les objectifs à atteindre clairement exposés.

En sortant de cette réunion de planification, chaque membre de l’équipe doit savoir quelles tâches il doit accomplir, comment et pourquoi. Les informations relatives au processus de développement doivent être connues de tous les membres afin de faciliter leur communication.

2. Le daily meeting

Le daily scrum meeting est une réunion intermédiaire qui intervient en cours de sprint. Elle réunit les membres de l'équipe de développement. Objectif : faire le point sur les tâches réalisées la veille, et celle prévue pour la journée.  

Ne devant pas dépasser 15 minutes, le daily scrum meeting est aussi l'occasion d'évoquer les difficultés. Si un débat est lancé sur un point de blocage, il est alors recommandé de prévoir une réunion dédié à la question se limitant aux personnes concernées.

3. La sprint review ou revue de sprint

A la fin de chaque sprint, une revue de sprint est organisée pour que l'équipe de développement puisse présenter les incréments apportés au produit en cours d'élaboration. C'est à cette occasion que les nouvelles fonctionnalités sont évaluées par des utilisateurs finaux qui sont généralement invités à toutes les conclusions de sprint.

La réunion est l'occasion de faire le point sur l'état d'avancement du produit. Est-il toujours en phase avec les besoins des métier ? Est-il nécessaire le cas échéant de faire des adaptations ? Lors de la sprint review, le périmètre du prochain sprint est aussi évoqué ainsi que le nombre de sprints restants pour parvenir jusqu'au produit final.

4 La sprint retrospective

La rétrospective de sprint intervient dans la foulée de chaque sprint review. Les utilisateurs métier n'y sont généralement pas invités. Elle offre à l'équipe de développement un espace d'échange pour tirer les enseignements du sprint, plancher sur des axes d'amélioration des processus et outils. C'est aussi l'occasion de revenir sur les relations entre les membres de l'équipe et les problèmes éventuellement rencontré. 

Dans le langage agile, la sprint retrospective s'inscrit dans le principe d'amélioration continue. L'objectif est que le prochain sprint soit plus efficace que le précédent et ainsi de suite. C'est une méthode empirique, c'est-à-dire basée sur l'expérience et sur l'auto-apprentissage.

Dans un sprint, le product owner est le garant de la vision produit. Il se charge d'alimenter le backlog du projet en items métier à réaliser. Quant au Scrum master, il accompagne l'équipe de dev dans l'adoption et la mise en œuvre des sprints et le développement des fonctions applicatives correspondant aux items métier. © Achmad Fahmi Rosyad / 123RF

Comment utiliser le sprint backlog ?

Le backlog sprint regroupe l'ensemble des user stories (c'est-à-dire les demandes fonctionnelles des utilisateurs métier) que l'équipe de développement s'est engagée à achever lors d'un sprint. L'état d'avancement de ces demandes sera représenté à travers un tableau kanban (ou scrum board). Chaque membre de l'équipe aura ainsi une vision commune du sprint en cours. 

Les user stories sont de plusieurs types : développement de fonctionnalités, d'environnements techniques, corrections de bugs, etc. Il s'agit des unités de travail les plus fines. Elles sont toujours décrites du point de vue de l'utilisateur final. Elle rapporte donc l'unité de travail du développeur à la valeur ajoutée qu'il apportera à à ce dernier. 

Quelle différence entre sprint et design sprint ?

Là où le sprint agile renvoie aux cycles de développement d'un produit, le design sprint désigne, lui, le processus de création qui se situe en amont. Inspiré du design thinking, il a pour but de passer à la loupe un maximum d'idées en équipe. S'étalant en général sur un période de cinq jours, il permet de valider rapidement un concept de produit ou de service. Objectif : parvenir à un ou deux prototypes qui seront ensuite éprouvés sur des utilisateurs réels le dernier jour. 

Capitalisant sur l'intelligence collective, le design de sprint vise à répondre rapidement à une problématique business en définissant une politique produit claire et éprouvée, accompagnée d'une feuille route de développement. In fine, la logique est évidemment d'accélérer le time to market tout en réduisant le risque commercial. Les principaux fondamentaux du design sprint : équipe pluridisciplinaire, unité de temps et de lieu, prototypage rapide et test en condition réelle.