Scrum : une approche facile à comprendre mais difficile à maîtriser ?
Qu’est-ce que la méthode Scrum ?
Définition de la méthode Scrum
Scrum veut dire la mêlée. Ceci fait référence au rugby. Ce sont les valeurs d’équipe, de confiance et de communication entre ses membres qui priment.
Il s’agit d’un cadre de travail ou encore d’un canevas, pour rester dans le vocabulaire français. En anglais, on parle de Framework.
Scrum est itératif et incrémental. Elle se découpe en plusieurs périodes courtes de durées égales et répétitives, formant ainsi des itérations. Ces itérations se terminent toutes par des livraisons. Chaque livraison constitue un incrément qui sera complété, modifié ou affiné lors de la prochaine itération.
Scrum est un processus empirique. Il se base sur l’expérience de l’équipe et s’appuie sur 3 piliers.
Transparence
L’importance d’un langage commun, non seulement entre les membres de l’équipe Scrum, mais également les parties prenantes pour faciliter la communication et la compréhension.
Inspection
De façon régulière, Scrum propose de faire le point sur les différents artéfacts afin de détecter au plus vite les écarts éventuels. Les inspections trop rapprochées génèrent le gaspillage ; trop éloignées, elles créent le risque d’écarts non désirables (effet tunnel).
Adaptation
Les différentes cérémonies – ou dit autrement : événements – permettent aux membres de l’équipe d’adapter le processus limitant les risques.
Outre les 3 piliers, Scrum respecte les principes énoncés dans le Manifeste des méthodes agiles. Voir notre article : Méthode agile : Best practices pour une mise en place réussie
A quoi sert la méthode scrum ?
A l’instar des autres méthodes agiles, Scrum présente pour principal avantage d’aboutir rapidement à une première version du produit ou du service testable et utilisable.
Les sprints sont validés au fur et à mesure par le client, la gestion de projet se traduit alors par un processus nettement plus productif.
Avec cette méthode, on en termine avec l’effet tunnel des projets utilisant les méthodes classiques, cycle en V, partant de l’analyse des besoins pour enchaîner spécifications, conception, développement et recette. Des projets qui se caractérisent par une livraison unique en bout de course dont le principal danger est de ne plus coller avec les problématiques métier qui auront forcément évolué en cours de développement.
À qui s’adresse cette méthode scrum ?
La méthodologie Scrum, un cadre de travail agile pour des projets complexes.
Scrum n’est pas une méthode agile limitée aux équipes d’ingénieurs et aux développeurs, Elle peut être très utile pour n’importe quelle gestion de projet.
Scrum peut être très utile pour n’importe quel projet complexe, et fonctionnera d’autant mieux si c’est un produit concret qui est développé.
Scrum est largement utilisée, quelle que soit la structure et la nature de l’entreprise. À partir du moment où elle décide de développer son produit, que ce soit un software, un site web, une application ou une campagne marketing, la méthodologie Scrum peut aider à mieux organiser l’équipe, à produire plus, de meilleure qualité et à gagner du temps.
Cette façon d’avancer sur un projet, par itération, assure également, de manière plus aisée, la mise en place d’un Minimum Viable Product (MVP) permettant de tester vos hypothèses rapidement tout en ayant la possibilité d’ajuster selon les besoins. Voir : Minimum Viable Product : définition et exemples concrets
Les start-up sont particulièrement adeptes de cette méthodologie qui leur permet de développer un produit en un temps record et avec un budget restreint. Elles sont le plus souvent en quête d’investisseurs et ces derniers doivent décider de la suite à donner en fonction de la pertinence et du potentiel d’une idée, d’un concept. Leur engagement en dépend.
Il est donc très intéressant et presque vital de pouvoir les convaincre rapidement avec un produit livré même minimaliste pour accrocher ces investisseurs.
Il serait contre-productif de travailler pendant des mois sur un projet pour ne présenter que l’unique solution aboutie. Pour convaincre, se caler à la demande, aux besoins des utilisateurs et s’adapter au fur et à mesure rassurera toutes les parties prenantes.
Pendant la phase de recherche de levée de fonds, les startups ne doivent donc pas imaginer leur nouvelle solution dans son ensemble. Cela serait du temps et de l’argent perdus. Mais plutôt se concentrer simplement sur les fonctions essentielles à développer pour leurs cibles. Un product owner appeler cela « Killer features ».
Une fois développées, ces fonctionnalités sont livrées, testées, adaptées et améliorées directement auprès des clients pour aboutir à un résultat final.
Cette méthode est aujourd’hui très appréciée lors du développement d’applications. Elle comprend deux phases :
- La validation du concept avec un PoC, « Proof of Concept » (« preuve de concept ») et la création d’un prototype. Comment mener une proof of concept efficace ?
- La réalisation d’un MVP, « Minimum Viable Product » (« produit minimum viable »). Minimum Viable Product : définition et exemples concrets
Dans quel cas utiliser la méthode Scrum ?
Comment mettre en place la méthode Scrum ?
Les différents rôles au sein du SCRUM
Le Scrum Master
Il s’assure que le cadre de la méthode soit correctement compris et appliqué par tous les intervenants au projet, facilite toute l’organisation et le respect des événements prévus.
Le Product Owner
C’est le propriétaire du produit. Il représente les clients et les utilisateurs qui vont l’exploiter après la livraison.
Son rôle est de maximiser la valeur du produit et du travail de l’équipe de développement. Son approche est donc ROIste. A la différence du chef de projet dont le rôle est de livrer le projet dans les différentes limites budgétaires et les deadlines qui ont été fixés dès le départ.
Il oriente l’activité de l’équipe en priorisant les fonctionnalités à livrer selon les priorités. Il explicite les éléments (Items) du carnet de produit (Backlog) et met à jour le carnet de produit et le rend visible. Dans les faits, le carnet de produit est souvent présenté sous forme de tableaux de post-it contre un mur à la vue de tous avec 3 colonnes :
- “Todo” pour les tickets à faire, en attente
- “Work” pour les tickets en cours de développement
- “Done” pour les tickets traités
Un ticket pour une user story sur un post-it.
Le Porduct Owner participe avec l’équipe à définir les objectifs de chaque sprints. Ceux-ci peuvent être fonctionnels, techniques ou organisationnels bien qu’il est souvent question d’expression fonctionnelle car elle est la plus facile à comprendre par tous. On peut estimer qu’un objectif technique peut être transformé en objectif fonctionnel.
Il arrive de façon exceptionnelle qu’un Product Owner soit amené à annuler un Sprint si l’objectif de celui-ci devient obsolète. Le Product Owner est le seul à pouvoir prendre cette décision.
Enfin, le Product Owner est un individu unique et ne peut être un groupe de personnes.
L’équipe de développement
Constituée de 3 à 9 personnes, l’équipe doit être solidaire car elle est responsable de toutes les livraisons. La fin de chaque itération donne une version enrichie du produit complétée par de nouvelles fonctionnalités issues du carnet de produit (product backlog) tout en respectant un haut niveau de qualité.
Avec la méthode Scrum, aucun rôle précis n’est défini aux membres de l’équipe de développement ou à des sous-groupes. Cette règle permet d’assurer la pluridisciplinarité et la solidarité de l’équipe dans son engagement.
Occupée par un seul projet à la fois, l’équipe est auto-organisée, autonome et pluridisciplinaire. Cette dernière condition assure à l’équipe la possibilité de réaliser le projet sans faire appel à des personnes externes à l’équipe.
L’objectif de l’équipe est de livrer le produit par incrément, tout en s’assurant que ce dernier soit livrable à tout moment. Ceci explique notamment l’exigence de qualité toujours soutenue.
C’est l’équipe de développement qui se charge d’estimer le coût des Items à développer. Elle laisse à la charge du Product Owner l’estimation de leur valeur Business.
Les événements
La méthode Scrum repose sur la mise en place de sprints. Le sprint encapsule tous les événements qui sont : la planification de Sprint (Sprint Planning), la mêlée quotidienne (Daily Meeting ou Daily Scrum), la Revue de Sprint (Sprint review) et enfin la Rétrospective (Sprint Retrospective).
Tous les événements, y compris le sprint, obéissent au principe de timeboxing. Il s’agit du temps maximum imparti au-delà duquel tout événement se termine quel que soit son état d’avancement.
La durée d’un sprint est généralement d’une à 2 semaines, et ne peut pas dépasser les 4 semaines.
Le Sprint Planning
Toute l’équipe (Product Owner, Scrum Master et les développeurs) est présente à cette réunion.
Son objectif est de décider des éléments du backlog à développer dans la limite du temps imparti. Elle prévoit également la façon de s’organiser pour y parvenir.
Dans la pratique, le Product Owner présente au reste de l’équipe le but du sprint qui démarre.
Les membres peuvent ensuite clarifier ensemble tous les éléments et ils procèdent au découpage des Items en tâches techniques et opérationnelles.
Le découpage doit être aussi précis que possible pour permettre une meilleure estimation et le meilleur engagement de l’équipe sur les fonctionnalités à produire. Leur estimation prend en compte les tests et la documentation.
Chaque sprint est considéré comme un mini-projet indépendant. A la fin de ce projet, l’équipe doit être en mesure de présenter un produit potentiellement livrable.
La durée de Sprint Planning ne peut pas dépasser 8 heures pour un Sprint de 4 semaines ou d’un mois calendaire. La durée est adaptée de façon proportionnelle quand le sprint est plus court.
Il est possible de résumer cette réunion en 3 questions :
- Quel est l’objectif spécifique du Sprint qui démarre ?
- Quels éléments prioritaires du Product Backlog peuvent être convertis en incrément potentiellement livrable avant la fin de l’événement ?
- Comment l’équipe doit-elle s’organiser pour convertir les éléments sélectionnés en un incrément potentiellement livrable ?
La mêlée quotidienne (Daily Scrum)
Comme son nom l’indique, cette réunion a lieu tous les jours. Sa durée maximale est de 15 minutes.
Son objectif est de permettre à l’équipe Scrum de synchroniser et d’ajuster son action pour les 24 heures et de répartir les tâches à traiter.
En pratique, tour à tour, les membres de l’équipe de développement prennent la parole pour répondre à 3 questions :
- Qu’ai-je fait hier qui a aidé l’équipe de développement à atteindre l’objectif du sprint
- Que vais-je faire aujourd’hui qui aidera l’équipe de développement à atteindre l’objectif du sprint ?
- Est-ce que je vois des obstacles qui pourraient m’empêcher ou empêcher l’équipe de développement d’atteindre l’objectif du sprint ?
Cette réunion quotidienne appartient avant tout aux développeurs, il ne s’agit pas de la considérer comme un reporting.
La mêlée quotidienne se pratique debout afin de rappeler son caractère synthétique. La constance du lieu et de l’heure du démarrage de la réunion est indispensable car ceci permet de faciliter sa pratique. Tout problème identifié et nécessitant un approfondissement est traité en dehors de cette réunion.
La revue de Sprint (Sprint review)
A la fin du Sprint, toute l’équipe Scrum ainsi que les parties prenantes se réunissent pour passer en revue l’incrément développé durant le sprint.
Cette démonstration se focalise uniquement autour des éléments finis, les autres ne sont pas présentés. Ceci donne lieu à un bilan de livraison et de validation d’éléments présentés. Les éléments présentés ne correspondant pas aux exigences ne sont pas validés. Ils seront reprogrammés dans un autre Sprint. A l’issue de cette réunion, le backlog est mis à jour.
La durée de cette réunion pour un sprint de 4 semaines ne doit pas dépasser 4 heures.
La Rétrospective (Sprint Retrospective)
Cet événement intervient après la Revue de Sprint et clôt ainsi chaque itération. Le client n’y participe pas.
La durée de cette réunion pour un sprint de 4 semaines ne doit pas dépasser 3 heures.
La rétrospective permet de relever les difficultés rencontrées, les choses à améliorer, les points positifs et principes à conserver pour faciliter le développement des futurs sprints.
Les artefacts de la méthode Scrum
Il en existe 3 et sont les points clés que toute l’équipe et les clients doivent avoir en esprit. Ils concernent le produit et son évolution réelle :
- Le Backlog Produit
Le Backlog Produit constitue une liste ordonnée et unique des exigences propres à un produit. Cette liste comporte des estimations (coûts) et des valeurs (business value). C’est le Product Owner qui en est l’unique responsable Il doit le faire évoluer, l’affiner (Product Backlog Refinement) et le rendre disponible à tout moment.
Le travail de raffinement ne doit pas dépasser 10 % de la capacité de l’équipe également invitée à son amélioration.
- Le Backlog Sprint
C’est un ensemble d’éléments ou d’exigences sélectionnées dans le Backlog Produit selon leur priorité. Chaque membre de l’équipe met à jour régulièrement le Backlog du Sprint au cours de son activité pour assurer une vision en temps réel de l’avancement. À n’importe quel moment, la somme totale du travail restant dans le Backlog Sprint peut être calculée.
- Incrément
Un incrément est la partie d’un travail réalisé qui permet de s’approcher de la vision du produit final.
À la fin d’un sprint, le nouvel incrément doit être « Fini », ce qui implique qu’il est publiable et qu’il correspond à la définition de « Fini » (Definition of Done).
Définition de « Fini » ou Definition of Done doit donner aux membres de l’équipe une compréhension commune de ce que cela signifie. Cette définition varie d’une équipe à l’autre mais sa connaissance permet d’améliorer la transparence.
Le Burndown chart
A n’importe quel moment du sprint la somme totale du travail restant dans le Backlog Sprint puisse être calculée. Burndown chart permet de visualiser le restant à faire de l’équipe tout au long d’un Sprint.
Autres notions utilisées dans SCRUM
Le sprint 0
Bien qu’appelé Sprint, le sprint 0 n’a pas de durée définie. Son objectif est de permettre de construire les bonnes bases d’un nouveau projet et de former une équipe Scrum ajustée pour sa réussite.
Les impératifs du Sprint 0 :
- Préparer l’environnement de développement
- Partager une vision claire autour du projet : objectifs des clients, le périmètre et les contraintes, une première version d’architecture technique ainsi que des deadlines globales
- Roder l’équipe sur le Backlog naissant et trouver la tâche « étalon »
La notion d’User Story
On appelle User Story une fonctionnalité minimale et précise à développer. Elle est toujours exprimée selon un même énoncé : En tant que [Qui- le rôle], je peux [Quoi] afin de [Pourquoi]
Le pourquoi permet de préciser l’intérêt concret de la User Story à développer.
Enfin, toute User Story s’accompagne des critères d’acceptation (on dit également d’acceptance). Ils permettront de vérifier sa validité.
Le Planning Poker
Il s’agit d’une méthode d’estimation de complexité des User Stories à développer.
Lors de la réunion de Sprint Planning, l’équipe de développement décompose les User Stories en tâches techniques. Afin d’estimer la complexité de ces dernières, le Planning Poker (un jeu de cartes) sera utilisé. De façon simultanée, chaque membre montre aux autres la carte qui désigne son estimation personnelle. Les valeurs indiquées sur les cartes suivent la suite de Fibonacci : 1, 2, 3, 5, 8, 13, 21, etc.
La vélocité
La vélocité est la capacité de l’équipe de développement à livrer les fonctionnalités prévues dans le Backlog. Seules les fonctionnalités correspondant aux critères d’acceptance seront comptabilisées. Toutes celles non achevées ou non conformes aux exigences seront rejetées et seront traitées dans un prochain sprint.
Exemple : une User Story est estimée à 5 points.
Elle comprend 4 éléments à développer mais à la fin du sprint, 3 éléments peuvent être livrés, le dernier n’a pas répondu aux exigences. Pour le calcul de Vélocité, cette User Story n’apporte aucun point.
Vision globale du framework Scrum
