gerer un projet en scrum

Qu'est-ce que le cadre Scrum ?

Le mot « scrum » trouve son origine en anglais et plus précisément dans le vocabulaire du rugby où il signifie « mêlée ». La vision qu’il y a derrière l’emploi de cette métaphore est qu’un groupe qui travaille ensemble est plus fort que la somme des individus du groupe : c’est une vision holistique.

Cet article a pour but de permettre une meilleure appréhension de ce qui cache derrière le mot « Scrum » pour les néophytes.

Scrum : un cadre agile pour gérer des projets

Le cadre scrum est une approche de gestion de projet agile.

Les avantages de développer un projet en scrum sont :

  • une meilleure estimation des fonctionnalités à développer
  • une priorisation et une prévision des délais nécessaires pour le développement plus précise qu’avec des méthodes classiques (cycle en V par exemple)
  • un fonctionnement en sprint qui permet de mieux gérer les problèmes rencontrés lors du développement et de réajuster en continu le temps requis pour le développement
  • d’avoir des livrables fonctionnels à la fin de chaque sprint

Scrum : quels rôles pour l’équipe projet ?

La gestion de projet en scrum commence par une répartition des rôles au sein de l’équipe chargée de développer le projet.

  • Product Owner : il représente le produit à réaliser. Ces derniers sont appelés des « user stories » qui correspondent aux fonctionnalités pour l’utilisateur final du produit.
  • Scrum Master : Il a pour rôle d’assurer la progression du projet en veillant à la bonne application du cadre scrum et au respect des objectifs définis. Il prend un rôle de « servant leader » et doit faire en sorte que chaque membre de l’équipe puisse lever les éventuels obstacles rencontrés pour que le projet avance efficacement.
  • Les membres de l’équipe : elle est constituée de développeurs, de testeurs, d’architectes logiciel. Ce sont eux qui réalisent les sprints et qui sont chargés de produire un livrable fonctionnel en fin de sprint. Les architectes logiciels travaillent sur la conception du logiciel afin qu’il puisse répondre aux spécifications demandées, les développeurs sont chargés de construire les produits, les testeurs d’assurer leur bon fonctionnement.

Gestion de projet scrum : comment jalonner le projet ?

Étape 1 : product backlog

Le « product backlog » est élaboré par les membres de l’équipe. Dans ce document, on rassemble la whislist complète des fonctionnalités souhaitées pour l’utilisateur final. C’est un moyen de formaliser le produit auquel on souhaite arriver en détaillant le plus possible les fonctionnalités qui composeront ce produit. Le product backlog doit vivre pendant le projet : on peut éliminer des idées dont on se rend compte qu’elles sont loin d’être indispensable tout comme l’on peut en rajouter d’autres en cours de route.

Le product owner est chargé d’assurer un niveau de détail important dans les user stories qui constituent le détail du product backlog.

A ce stade, une « user story » contient les informations suivante :

  • id : pour identifier la « user story »
  • nom : descriptif de la fonctionnalité attendue de manière concise mais précise pour éviter tout quiproquo.

Une fois que le product backlog est élaboré ; on passe à la priorisation et à l’allocation des ressources en temps pour chaque « user story » définie lors de la phase précédente.

L’allocation en temps se fait de la manière suivante :

  • les tâches qui durent moins de une journée sont découpées en tranche de 1h ; 2h ; 4h ou 8h. Une tâche qui est estimée durer 5h se verra allouée 8h de temps.
  • les tâches qui durent plus d’une journée sont découpées en tranche de : 2 jours, 3 jours, 5 jours ou 10 jours. Comme précédemment, une tâche estimée durer 4 jours se verra allouer 5 jours de temps.
  • les tâches qui durent plus d’un mois doivent être sous-divisées dans les deux catégories précédentes.

A ce stade, on complète chaque « user story » avec les champs suivants :

  • priorité : par exemple, une échelle de 1 à 5 avec 1 = priorité très haute et 5 = priorité faible
  • estimation : la durée estimé de réalisation (en heures ou jours)

Étape 2 : sprint backlog

Le sprint backlog divise le product backlog en sprints d’une durée comprise entre 2 jours et 1 mois. Chaque sprint correspond à un livrable fonctionnel à produire. C’est une étape essentielle de la planification scrum.

On complète chaque « user story » :

  • Test : quel test de validation permettra de vérifier si la fonctionnalité créée fonctionne ?
  • Notes : références documentaires, précisions etc

Étape 3 : daily scrum & burndown charts

Les sprints peuvent alors démarrer, on sait ce que l’on doit produire et l’on a une estimation du temps nécessaire.

Le scrum master met alors en place un temps essentiel chaque jour de sprint : le daily scrum. Lors de ce temps d’échange, chaque membre de l’équipe met en avant ses réussites de la veille, ce qu’il va faire le jour même et les éventuels obstacles qu’il a rencontré. L’idée de ce point commun à toute l’équipe est de faciliter la communication au sein de l’équipe, de synchroniser les avancés et de trouver des solutions communes aux problèmes rencontrés.

Aussi, pour ajuster l’effort à produire, le scrum master recourt à un « burndown chart ». En ordonné est indiqué le volume de travail restant (en heures ci-dessous) et en abscisse le temps restant. Cela permet d’avoir davantage de visibilité et permet de juger de l’avancée du sprint et des éventuels ajustements à réaliser. Le sprint est donc actualisé au jour le jour selon les progrès réalisés.

Étape 4 : sprint retrospective

A chaque fin de sprint, un point est fait sur ce qui a / n’a pas fonctionné. Cela dans une démarche d’amélioration continue.

Étape 5 : on entame le sprint suivant et ainsi de suite :)

 

Conclusion sur la méthode scrum

Trois mots-clés : adaptabilité, visibilité, amélioration continue au service d’un seul objectif : livrer un logiciel fonctionnel et répondant aux besoins du client à temps.

Les dernières actus