Dans les livres et les sites qui parlent de la méthodologie Scrum, on constate qu’il y a beaucoup d’associations avec le rugby. D’ailleurs, le terme « scrum », qui signifie « mêlée » est directement emprunté à ce sport. Au rugby, les membres d’une équipe doivent unir leurs efforts pour atteindre le même but, soit celui d’avancer avec le ballon. En Scrum, les membres d’une équipe mettent le focus sur un même objectif afin de livrer un projet. La méthode a d’abord été conçue pour le développement de logiciels et s’est peu à peu étendue à d’autres secteurs d’activités dont le Web.

Voici un résumé des principales caractéristiques de la méthode Scrum :

Principes Scrum

Expérience :

Le principe de base de Scrum est l’acquisition de connaissances par l’expérience. Selon cette théorie, l’expérience favorise la prise de décision car celle-ci est basée sur ce qui est connu. Cet aspect de la méthodologie se concrétise par des meetings entre les membres d’une équipe pour faire une rétrospective après chaque livrable. L’équipe discute alors des aspects positifs et négatifs d’un projet dans le but de s’améliorer.

Approche progressive :

Un autre aspect important, et qui à mon avis est le plus difficile à maitriser, est l’approche itérative et incrémentale. La façon d’aborder un projet en Scrum est très différente de ce à quoi nous étions habitués. Au lieu de travailler en étapes successives (design, intégration, programmation), on doit aborder un projet comme une série de fonctionnalités progressives. On commence par définir les fonctionnalités requises d’un site en fonction des besoins du client. Avec notre ancienne méthode, une fois que nous avions défini les fonctionnalités, nous les livrions au client une fois qu’elles étaient terminées. Le client ne voyait pas l’évolution du travail et n’était pratiquement pas impliqué pendant l’exécution de son projet. Nous le tenions au courant de l’évolution des travaux mais il ne pouvait pas commencer à faire des tests avant que tout soit pratiquement fini. En Scrum, le client est plus impliqué dans le processus car un projet contient plusieurs livrables que le client doit approuver. Par exemple, pour un site Web qui nécessite six mois de développement, nous nous engageons à livrer une fonctionnalité à toutes les deux semaines. Il est certain qu’en ce court laps de temps, nous ne pouvons pas livrer une fonctionnalité complète. On livre alors une fonctionnalité partiellement terminée et à chaque livrable, cette même fonctionnalité est en amélioration continue. Le client voit régulièrement l’évolution des travaux et si un aspect du livrable ne lui convient pas tout à fait, il est plus facile pour nous de rectifier le tout et de s’ajuster pour satisfaire les besoins du client. Le but de cette approche est d’optimiser la prévisibilité d’un projet et de mieux contrôler les risques.

Transparence :

Quand une équipe commence à travailler sur un projet, tous les membres doivent s’entendre sur ce qu’il y a à faire et sur les objectifs du produit. Si une seule personne est au courant de l’ensemble du projet et que les différents membres de l’équipe de production connaissent seulement la partie qui les concerne, le risque d’erreur est plus élevé. Si au contraire, tous les membres d’une équipe connaissent les objectifs du client et tous les aspects du projet, ils auront alors un sentiment d’appartenance et s’impliqueront d’avantage.

Inspection :

En cours de projets, plusieurs réunions sont prévues afin de passer en revue l’avancement des travaux. Si l’équipe n’a pas les informations nécessaires pour avancer ou si des obstacles surviennent, nous pouvons alors réagir plus rapidement et aviser le client qu’il doit nous fournir les éléments manquants pour que nous puissions respecter notre échéancier.

Adaptation :

Quand un projet web nécessite des semaines ou des mois de travail, il arrive constamment que les besoins du client évoluent en cours de route, ce qui est tout à fait normal. Au début d’un mandat, le client a une bonne idée de ce qu’il veut mais au fur et à mesure qu’il voit son site évoluer, il peut arriver que de nouvelles idées surgissent et que cela nécessite des ajustements au projet. La structure mise en place en Scrum permet de s’adapter et d’être plus flexible lorsque des changements surviennent.

Les rôles

En Scrum, les rôles occupent une place importante et sont différents de ce à quoi nous sommes habitués en web.

Scrum master :

Le Scrum master a la responsabilité de s’assurer de la compréhension et de l’application de la méthodologie Scrum. La compréhension théorique de Scrum n’est pas compliquée mais pour la mettre en pratique, c’est tout un défi. Quand on l’implante dans une entreprise, ça implique d’adopter un nouvel état d’esprit et de changer les habitudes de travail. Pour que l’implantation de Scrum soit un succès, il faut que tout le monde y mette du sien et participe à ce grand changement. Il doit aussi veiller à ce que tous les objectifs des différents événements Scrum soient respectés Il aide les équipes à identifier les obstacles pour ensuite les aider à les surmonter dans le but de faire progresser les équipes.

Le PO :

Le PO (propriétaire du produit) représente le client et les utilisateurs au sein de son équipe. Sa fonction principale est de s’assurer de la qualité du produit qui sera livré au client. Un peu comme le chargé de projets, il est l’intermédiaire entre le client et les membres de son équipe. En début de projet, le PO définit les objectifs du projet et les transmet à son équipe. Il a également la responsabilité de gérer les priorités dans le calendrier de production. En théorie, les membres d’une équipe doivent tous travailler sur un même projet mais cet aspect de Scrum est utopique dans notre agence. Nous avons souvent plusieurs projets en simultanée et nous ne pouvons pas nous permettre de travailler sur un seul. Nous recevons régulièrement des demandes urgentes que nous devons faire rapidement.

Équipe de développement :

Dans notre cas, chaque équipe de développement est composée d’un designer, d’un intégrateur et de deux programmeurs. Les équipes sont composées afin d’avoir toutes les compétences nécessaires au développement d’un projet. Elles doivent s’auto-organiser et choisir la façon dont le travail à faire sera accompli. Il n’y a pas de concept de hiérarchie à l’intérieur d’une équipe, les décisions sont prises ensemble.

Les événements

Sprint :

Le sprint est un élément clé en Scrum. C’est une période durant laquelle une fonctionnalité (ou incrément du projet) est réalisée. Chez Reptiletech, les sprints ont une durée de deux semaines. Les sprints sont constitués d’une réunion de planification dans laquelle l’équipe évalue les tâches à effectuer, de réunions quotidiennes de 10 minutes (daily en langage Scrum), et d’une période de développement. À la fin de chaque sprint, une revue permet de valider en équipe le projet qui a été livré, suivi d’une rétrospective de sprint dont l’objectif est de regarder les erreurs commises dans le sprint et les éléments à améliorer pour que l’équipe s’améliore.

Réunion de planification de sprint :

Lors de cette réunion, l’équipe discute des objectifs du sprint et décide de ce qui sera accompli pendant cette période. Ensuite, on détermine la manière dont les objectifs seront atteints en évaluant toutes les tâches à accomplir. À la fin de la réunion, l’équipe s’engage à livrer une ou plusieurs fonctionnalités.

Mêlée quotidienne ou daily :

À tous les jours, l’équipe doit se réunir pour un maximum de 10 minutes. Tous les membres de l’équipe de développement doivent dire sur quoi ils ont travaillé le jour précédent et sur quoi ils vont travailler le jour même. Si un membre de l’équipe manque d’information pour accomplir ses tâches, il doit mentionner ce qui le bloque et l’équipe détermine les actions qui doivent être prises pour continuer. Si on doit obtenir des informations de la part du client, c’est le PO qui doit s’assurer de le contacter pour obtenir les réponses.

Revue de sprint :

Lorsque la période de développement de 14 jours est terminée, l’équipe se réunit pour valider la qualité du travail qui a été fait et s’assurer que les objectifs du sprint sont atteints.

Rétrospective :

La dernière réunion a pour but de faire un « post mortem » du sprint et de voir si des erreurs ont été commises ou si certains points sont à améliorer. Ce meeting est animé par le Scrum master qui oriente l’équipe sur les changements et améliorations à apporter. Un plan d’action concret doit ensuite être établi pour mettre en œuvre les points soulevés.

Les artéfacts de Scrum

Carnet de produit (backlog) :

C’est une liste de fonctionnalités à accomplir pendant un sprint. Chaque fonctionnalité doit contenir une description et une estimation du travail à accomplir. Elles doivent aussi être classées par priorité.

Carnet de sprint :

Nous avons vu précédemment qu’en début de sprint, un objectif est fixé. Le carnet de sprint contient les éléments du carnet de produit choisis par l’équipe et qui seront réalisés. Le carnet de sprint doit être mis à jour quotidiennement pour que tous les membres de l’équipe puissent suivre la progression des travaux.

-

À propos de l'auteur

Chargée de projet chez Reptiletech, Josée Legault est spécialisée en stratégie web, SEO et SCRUM.