Scrum : comprendre et appliquer la méthode de gestion de projet

Souvent considérées comme démodées, les méthodes de gestion de projet agile sont parfois instaurées sans préparation ni transition, et seuls leurs aspects ludiques sont appliqués. La méthode Scrum n’y déroge pas. Malgré sa souplesse et son apparente simplicité, le concept demande pourtant à être étudié afin d’en exploiter tout le potentiel.

 

Les 3 principes fondamentaux de la méthode Scrum

Scrum repose sur trois piliers. Il est primordial de les connaître et de les comprendre pour adopter « l’état d’esprit Scrum » et agir en cohérence avec ce cadre méthodologique.

La transparence

Ce premier principe signifie que toute information doit être accessible et compréhensible pour n’importe quel membre du projet. Dans l’optique d’une bonne communication et d’une collaboration optimisée, chacun doit savoir de quoi il est question, et rapidement.

Les parties prenantes doivent aussi partager un langage et des définitions de base. Par exemple, la « définition de fini » (DOD, definition of done) est un indicateur essentiel à la livraison d’une nouvelle version du projet, qui doit être compris de tous.

Enfin, la transparence fait également référence à un savoir-être, des attitudes indispensables à la cohésion d’une équipe Scrum : oser dire les choses difficiles à entendre, reconnaître et apprendre de ses erreurs, savoir dire non, etc.

L’inspection

L’inspection est menée par tous les membres de l’équipe, et non pas par un auditeur externe. Elle intervient à un rythme régulier et raisonnable, par exemple lors des mêlées quotidiennes ou à la fin d’une phase opérationnelle, pour vérifier que le livrable attendu est conforme aux objectifs définis en début de période.

Ce principe peut bien entendu être appliqué au produit, mais également aux processus, aux aspects humains, aux pratiques et à l’amélioration continue.

L’adaptation

Le troisième pilier est inscrit dans l’ADN de la méthode agile Scrum. Si l’inspection révèle un problème sur l’ensemble des tâches réalisées, le fonctionnement doit être ajusté afin d’atteindre les objectifs de la phase en cours. La méthode offre plusieurs occasions d’opérer cet ajustement, qui seront détaillées par la suite.

Cette volonté d’amélioration doit être continuellement à l’œuvre durant la réalisation du projet, et partagée par toutes les personnes impliquées. L’idée est que chacun se demande régulièrement si l’étape de l’inspection a permis d’optimiser son travail, ou si ce dernier pourrait encore être facilité d’une quelconque manière.

Quand utiliser la méthode Scrum ?

La méthode Scrum est particulièrement adaptée aux projets nécessitant de faire preuve d’une grande flexibilité. Par exemple, si vous développez un logiciel pour un client, il y a de grandes chances que ses besoins ne soient pas immuables, et ses demandes seront probablement amenées à évoluer. C’est typiquement dans ce cas de figure que l’évolutivité de la gestion de projet Scrum prend tout son sens : il n’y a pas de contrainte de planification trop rigide, mais le cadre reste suffisamment clair pour ne pas perdre de vue vos objectifs.

Là où certaines méthodes sont davantage orientées vers la mise à disposition de services, Scrum tire son épingle du jeu dans le cadre de l’élaboration d’un produit. En effet, il est plus logique et profitable de motiver l’équipe si elle est en charge d’un unique produit et qu’elle partage un même but sur la phase en cours. Il serait même contreproductif d’essayer de construire une logique d’ensemble si chacun des membres est affairé à un produit ou un domaine complètement différent.

Les éléments clés à connaître dans la méthode Scrum

Les rôles

Un groupe projet Scrum comporte trois rôles.

Le product owner (PO), ou propriétaire du produit, représente le client et l’utilisateur. Il ou elle porte la vision du projet et veille à la conformité de celui-ci avec le product backlog, ou carnet du produit, comparable à un cahier des charges. Son rôle est présent à chaque nouvelle étape.

L’équipe de développement traduit les besoins exprimés en fonctionnalités techniques. Elle se compose de moins de dix personnes aux compétences complémentaires, toutes nécessaires à la réalisation et à la livraison du projet dans ses versions successives. Ses membres collaborent sur un pied d’égalité, en autonomie et portent la responsabilité commune de l’incrément.

Le Scrum master, autrement appelé maître de mêlée, a pour mission d’huiler les rouages et d’assister au mieux chacun dans ses tâches. Il ou elle veille au respect de la méthodologie Scrum, à la bonne communication et aide à surmonter les difficultés.

Les sprints

Les sprints, ou itérations, sont les phases opérationnelles de développement du projet. À l’issue de chaque sprint, un incrément, c’est-à-dire une nouvelle version du projet, est proposé au client et sert de base à la phase suivante.

Les sprints durent de deux à quatre semaines. Ils sont encadrés par des temps de planification et d’évaluation du travail, mais aussi jalonnés de courtes mêlées quotidiennes.

Les artefacts

Le carnet du produit, qui liste l’ensemble des besoins et fonctionnalités du projet par ordre de priorité, le carnet de sprint, qui contient les tâches à effectuer lors de chaque itération, et l’incrément produit constituent, en jargon Scrum, les artefacts.

Les user stories

Ce terme désigne une façon de rédiger les besoins contenus dans le carnet du produit. Une user story est proposée par le PO et doit apporter de la valeur pour le client. L’équipe de développement doit, en outre, pouvoir l’estimer afin de la hiérarchiser et évaluer l’effort et le temps de travail requis.

Comment appliquer la méthode Scrum ?

Au-delà des principes fondamentaux, il est nécessaire de visualiser, dans le détail, comment fonctionne la méthode Scrum, qui signifie « mêlée » en anglais.

Définir et planifier les sprints

En méthode Scrum, un projet est découpé en une succession d’itérations durant lesquelles sont développées les différentes fonctionnalités. Chaque itération doit en apporter de nouvelles.

Ce fractionnement du travail en sprints constitue le cœur de la méthode, car il offre l’opportunité de retours de terrain pertinents pour le projet et plus de souplesse qu’une gestion traditionnelle en cas de dérive.

La première étape d’un projet est donc d’effectuer ce découpage, qui incombe au PO. Avant le lancement, ce dernier doit identifier les objectifs de chaque trimestre que durera le projet.

Il doit aussi définir et prioriser, en fonction de leur valeur métier, les exigences, que l’équipe de développement transformera en fonctionnalités. Elles sont consignées et explicitées dans le carnet du produit. Toujours incomplet en début de processus, il traduit la vision du produit et sert de base à la feuille de route du projet.

Enfin, le PO doit évaluer, avec leur aide, la vélocité des développeurs. Ce calcul dépend de l’estimation des éléments dans le carnet du produit et s’appuie sur les itérations antérieures, afin de prévoir la durée totale du projet. Il tient aussi compte du temps de présence effectif des collaborateurs. Plus délicat en début de projet, ce calcul reste un indicateur et non un outil de sanction.

À partir de ces paramètres, le propriétaire du produit arrête un calendrier, appelé plan de release, et les dates de livraison des incréments. Ces informations de cadrage doivent être établies clairement car le client doit pouvoir les consulter et les comprendre.

Définir les listes

L’image du tableau séparé en colonnes garnies de post-it multicolores est désormais bien connue de quiconque est confronté à la gestion de projet.

Cette pratique donne une vision globale du degré d’avancement par tâche et par collaborateur. Elle répond au besoin de lisibilité et de transparence du cadre Scrum.

Les colonnes correspondent généralement à des listes de tâches à réaliser, en cours, à vérifier ou terminées. Les intitulés sont choisis selon les besoins de l’équipe. Si toute l’entreprise fonctionne agilement, il peut être utile de créer un référentiel partagé, afin de faciliter une éventuelle collaboration entre services.

Le Guide Scrum préconise que l’équipe de développement partage un unique espace de travail. Si c’est le cas, un tableau physique des tâches (task board), régulièrement actualisé par le maître de mêlée, est l’outil adéquat. Si, en revanche, une partie de l’équipe est délocalisée, mieux vaut privilégier les outils digitaux reproduisant son organisation afin que tout le monde ait accès aux données du projet en cours. Il s’agit de logiciels ou applications web de gestion de projet, comme Trello par exemple.

Créer un backlog

Deux niveaux de backlog existent dans Scrum :

  • le product backlog, évoqué plus haut,
  • le sprint backlog.

Le Guide Scrum définit ce dernier comme « une vue en temps réel », très visible du travail que l’équipe planifie d’accomplir durant le « sprint ». Il s’agit donc de l’ensemble du périmètre à réaliser lors d’un sprint. Il appartient aux développeurs mais peut s’avérer utile au maître de mêlée pour tenir à jour le graphique d’avancement.

Pour le créer, l’équipe de développement choisit des user stories qu’elle estime réalisables, dans le carnet du produit. Elle les classe par ordre de priorité et les traduits en tâches, qu’elle inscrit dans son carnet de sprint. Le plus souvent, il est représenté sous forme de tableau pour être visible par tous. Le maître de mêlée épaule l’équipe dans la rédaction de son carnet et dans l’utilisation des outils agiles pour avancer.

Tout comme le carnet du produit, celui du sprint peut être enrichi en cours d’itération, mais surtout entre les différentes phases. Cette évolution constante, basée sur les constatations de terrain et le test des incréments, poussant à questionner le fonctionnement de l’équipe, est le fondement de la philosophie Scrum.

Le carnet de sprint est rédigé lors de la réunion de planification qui inaugure chaque itération. Si le cadrage trace les grandes lignes, le sprint planning meeting permet, lui, de rentrer dans le vif du sujet.

Organiser la mêlée et les rétrospectives

Outre la réunion de planification, un projet Scrum comporte d’autres jalons, animés par le maître de mêlée.

La mêlée quotidienne permet à chacun de dresser le bilan des événements de la veille et ceux prévus le jour même. C’est aussi l’occasion de mettre en lumière les obstacles rencontrés et les solutions envisageables. Cette réunion est courte, quinze minutes au plus, et dynamique. L’une des astuces consiste à la mener debout pour qu’elle ne s’éternise pas.

L’itération achevée, il est temps d’organiser la revue du sprint, généralement le dernier jour. Les nouvelles fonctionnalités sont testées en présence du PO, avant que le destinataire, le client par exemple, ne valide définitivement cette étape.

La rétrospective s’apparente davantage à une analyse de la pratique. Le groupe fait le bilan de ce qui a fonctionné ou non, et pourquoi. Des adaptations sont proposées toujours en vue d’améliorer l’efficacité de l’équipe de développement.

Planifier le premier sprint

S’il est important d’appréhender la méthode Scrum, savoir se lancer l’est tout autant. Cela requiert néanmoins quelques dernières vérifications et étapes.

  • Constituer l’équipe : elle doit être autonome, c’est-à-dire posséder en son sein l’ensemble des compétences requises pour développer le produit. Cela implique la pluridisciplinarité, mais aussi d’inventorier les ressources disponibles et d’identifier les besoins pour y parvenir, que ce soit en termes de recrutement, formation, ou bien sous-traitance.
  • Initier l’équipe à la méthode : si les développeurs ne connaissent pas Scrum, le maître de mêlée devra les y former afin qu’ils s’en approprient les codes et les outils.
  • Ordonnancer le carnet de produit : c’est l’une des premières tâches du PO, pour que l’équipe puisse ensuite s’en saisir.
  • Définir la fréquence des sprints : le PO la détermine en fonction de l’ampleur du projet et du plan de release, qui correspond à la séquence des sprints à venir. Le plan de release schématise chaque sprint avec ses objectifs, son délai, ses user stories. Les sprints doivent être suffisamment longs pour permettre l’observation du processus et suffisamment courts pour simplifier les ajustements. Ils s’étendent généralement de deux à quatre semaines, une durée propre à chaque projet.
  • Choisir l’outil : la question a son importance, surtout si une partie de l’équipe travaille à distance. L’outil doit être accessible à chaque membre du projet. Il en existe plusieurs ; il revient au maître de mêlée, habitué à la méthode, d’effectuer un choix cohérent avec le groupe.

Après ces plusieurs jours de cadrage, parfois nommés « sprint 0 » et estimés en fonction de la durée totale du projet, la première phase de développement, le premier sprint donc, peut commencer.

Prochaine étape : le sprint planning meeting, généralement organisé le premier jour de chaque sprint, au cours duquel l’équipe de développement précisera ses tâches, leur répartition entre les différents collaborateurs et les moyens prévus. Somme toute, la stratégie qu’elle entend déployer pour atteindre son objectif.

Pour aller plus loin, téléchargez cet e-book gratuit et découvrez comment favoriser la fidélisation et la rétention de vos clients.

Développer un processus d'implementation client


Lire l’article sur le site Source

Ajouter un commentaire

Les champs requis sont indiqués *