Warning: include_once(ganalytics.php) [function.include-once]: failed to open stream: No such file or directory in /home/capsens/www/structure/header.inc.php on line 42

Warning: include_once() [function.include]: Failed opening 'ganalytics.php' for inclusion (include_path='.:/usr/local/php5.3/lib/php') in /home/capsens/www/structure/header.inc.php on line 42
.

De Sofyan Fortas

La méthode SCRUM : un mode opératoire de plus en plus reconnu

Sommaire

  1. La méthode SCRUM : un processus très rigoureux
  2. Avantages et limites du SCRUM
    1. Il existe aujourd’hui de nombreuses méthodes utilisées pour mener un projet web à son terme. Parmi les méthodes dites agiles, la plus remarquable et la plus aboutie est à l’heure actuelle la méthode SCRUM (Scrum est un mot anglais désignant la mêlée pratiquée au rugby). Cette forme de gestion de projet prend le contre-pied des méthodes traditionnelles laissant peu de place au changement, à tel point que l’on abandonne petit à petit le terme de gestion de projet au profit de « gestion de produit » .

      Elle considère que le besoin ne peut être figé et propose au contraire de s'adapter aux changements de ce dernier. Mais pas sans un minimum de règles que nous allons détailler ci-après.

      La méthode SCRUM : un processus très rigoureux

      Avant d’entrer dans le détail des règles précises régissant la méthode Scrum, il nous paraît important d’en clarifier les principes fondamentaux :

      En premier lieu, la méthode Scrum requiert une transparence totale entre les différents membres de l’équipe en charge du projet. Cela permet à tout membre de pouvoir intervenir rapidement en cas de problème.

      Ensuite, la notion d’inspection est également essentielle : il est indispensable de faire des points réguliers avec toute l’équipe afin de détecter toute variation indésirable vis à vis du produit et de l’échéancier.

      Enfin, comme le nom de « méthode agile » le suggère, l’adaptation est également au cœur de la méthode Scrum. Ainsi, si une dérive est détectée en cours de route, elle pourra être traitée dans les plus brefs délais grâce aux daily scrum (réunions d’équipe quotidiennes de 15 min).

      Pour commencer, nous allons présenter les différents rôles clés de l’équipe en charge du produit.

      Le Product Owner ou client est en charge de lister les différentes fonctionnalités dont le produit sera doté et l’ordre dans lequel il souhaiterait les voir développées. Il consigne ces fonctionnalités dans le « product backlog », sorte de tableau aux allures de cahier des charges afin qu’un produit commercialisable puisse émerger à la fin de chaque « sprint » (nous expliciterons ce terme plus bas). Les deux implications principales de ce rôle est de se rendre disponible vis à vis du reste de l’équipe et de s’assurer que cette dernière a bien compris toutes ses attentes.

      Le Scrum Master fait en sorte que le projet progresse comme souhaité et que chaque membre de l’équipe a les outils pour réaliser ses tâches en temps et en heure. Il est donc en charge de fixer les réunions d’équipe et de surveiller l’avancée globale du projet grâce à des graphiques et outils statistiques que nous étudierons plus bas. Il est en quelque sorte le « project manager » de l’équipe.

      Le reste de l’équipe est ensuite constitué de développeurs qui ajoutent une à une les fonctionnalités au produit au fur et à mesure des sprints.

      Enfin viennent les testeurs qui s’assurent de la qualité des fonctionnalités mises en place par l’équipe technique.

      Le réel point de départ de la méthode Scrum est le Product Backlog complété par le Product Owner. Chaque élément (ou « user stories ») du Product Backlog est ensuite classé par ordre de priorité. Il est également essentiel, pour chaque user story, d’estimer le temps nécessaire à sa réalisation. A noter qu’il est possible et même recommandé de diviser les plus grosses user stories en plus petites afin d’avoir une plus grande visibilité et précision dans l’estimation du temps nécessaire à leur réalisation. Lors de cette étape, il est important que tous les membres de l’équipe se réunissent afin de considérer chaque user story et de s’accorder sur un nombre de « points de difficulté » à lui attribuer. Cela permet et au client et au reste de l’équipe d’être sur la même longueur d’onde et d’éviter tout malentendu. Ce mode de fonctionnement permet également de mettre en place un échéancier crédible et convenant à tous.

      Dans l’optique d’estimer le temps de travail nécessaire à la réalisation de chaque tâche, il existe une méthode qui permet de minimiser les retards. Elle consiste à classer chaque user story dans des tranches de durée comme le récapitule le tableau suivant :

      Il est bien important de comprendre que chaque user story doit nécessairement être classée dans une de ces tranches de durée. Si par exemple une user story possède un temps de réalisation estimé à 4h, elle sera automatiquement placée dans la catégorie supérieure à savoir 5h. De la même manière, Si une autre user story est estimée à 6 jours, elle sera placée dans la catégorie 8 jours.

      Une fois que chaque user story a été classée, l’équipe peut s’atteler à planifier les sprints qui s’échelonnent de 2 à 30 jours. Il est généralement admis qu’un projet doit comporter entre 2 et 12 sprints maximum. Le but de chaque sprint est qu’à son terme, le produit soit utilisable, le sprint suivant servant à lui ajouter d’autres fonctionnalités et/ou d’ajuster les user stories préalablement formulées. L’autre intérêt des sprints est de pouvoir élaborer un « burn-down chart », sorte de graphique mesurant quotidiennement l’avancée de chaque sprint et permettant ainsi non seulement d’anticiper tout retard mais également d’avoir une représentation fidèle de la productivité de l’équipe. Ainsi, tout dysfonctionnement peut être pris en charge à temps pour éviter tout retard fâcheux. Ces graphiques peuvent être conçus par le scrum master à l’issue des « daily scrum » que nous avons évoqués plus haut et qui permettent de gagner en fluidité.

      Enfin, il est très important de mener une rétrospective à l’issue de chaque sprint dans l’optique de gagner toujours plus en productivité et en efficacité en vue des sprints à venir.

      Avantages et limites du SCRUM

      Les différentes et précises étapes de cette méthode Scrum font surgir un avantage indéniable de cette dernière vis à vis d’autres méthodes existantes : elle permet en effet d’organiser très rigoureusement le dialogue entre le product owner (= client) et l’équipe technique qui va développer le projet. Grâce à ce dialogue quotidien (lors des daily scrum), client et prestataire font donc en sorte d’être en permanence sur la même longueur d’onde : le client peut ainsi connaître à tout moment l’avancée de son projet ainsi que le retard pris par ce dernier (grâce au burn-down chart) mais également les moyens mis en œuvre pour rattraper ce retard. De la même manière, ce dialogue permet au client de savoir ce qui est réalisable ou non, sans avoir de bagage technique poussé. Ces vertus du dialogue permanent, permis par la méthode Scrum, permettent ainsi de minimiser la méfiance et la mésentente qui peuvent s’immiscer entre client et prestataire. Cet encadrement rigoureux du dialogue offre également l’opportunité aux développeurs de ne pas être interrompus lorsqu’ils sont en train d’accomplir les tâches du sprint en cours.

      Autre avantage déterminant offert par la méthode Scrum : le fait qu’un produit « viable » voit le jour à l’issue de chaque sprint. En effet, comme nous l’avons expliqué, le but de chaque sprint est d’apporter de nouvelles fonctionnalités au produit. Ce mode opératoire permet ainsi au client d’avoir constamment une vision d’ensemble de son produit et, s’il le désire, de l’ajuster ou de l’affiner au fur et à mesure.

      Par ailleurs, cette méthode est particulièrement avantageuse pour les agences adeptes du lean startup c’est à dire lorsque les spécifications du produit et ses fonctionnalités sont déterminées en fonction des envies du client.

      Toutefois, cette méthode est applicable si et seulement si le client fait montre d’une forte disponibilité ce qui peut s’avérer contraignant pour un entrepreneur sollicité par nombre de tâches à effectuer.

      Par ailleurs, la méthode scrum requiert une équipe technique qualifiée pour être appliquée ce qui peut être délicat pour des agences comptant de nombreux jeunes développeurs en cours de formation.

      De plus, si les burn-down charts permettent de visualiser concrètement ce qui a été accompli et donc le retard accumulé, ils ne permettent en revanche pas de fixer une date butoir à la sortie du produit mais seulement une fourchette ce qui peut dissuader certains clients d’adopter cette méthode.

      Ainsi, avec l’avènement de l’économie numérique et l’émergence de produits 100% web (applications, logiciels complexes, algorithmes, etc.) nous voyons émerger de nouvelles méthodes de développement technique. Parmi celles-ci la méthode Scrum nous paraît se démarquer des autres en raison de sa rigueur, de la relation client/prestataire qu’elle induit et des « rituels » qu’elle met en place afin de viser à créer le produit le plus performant possible.