La méthodologie Scrum vue d’avion

Nous vous proposons aujourd’hui un survol de la méthodologie Scrum qui va vous permettre de mieux appréhender cette méthode de gestion de projet. Vous y verrez les différentes étapes d’un projet Scrum et le rôle des différents protagonistes.

Extrait de la vidéo de formation : Challenge Scrum Master

Dans cette vidéo, je vais vous proposer de vous donner une vue d’avion du cadre méthodologique Scrum. Nous aborderons toutes étapes du projet Scrum, à savoir :

• le product backlog et son fonctionnement
• la planification du sprint
• l’incrément et la revue de sprint

La centralisation des éléments dans le product backlog

Au coeur de la méthodologie Scrum, on trouve le product owner qui va centraliser ses besoins ou ses exigences dans un product backlog. Chacun des éléments du product backlog va ensuite être estimé par une équipe de développement qui peut elle aussi suggérer, voire imposer, des exigences non fonctionnelles ou techniques, qui sont les pré-requis aux fondations ou au socle sur lequel va s’appuyer le produit.

Mais c’est toujours le product owner qui a le dernier mot sur ce que va contenir le product backlog. Donc souvent, l’équipe de développement doit expliquer ou vulgariser les raisons d’être des éléments du product backlog.

Une fois que l’estimation a été faite, le product owner va pouvoir, grâce à la valeur de chaque élément (on parlera de valeur ajoutée plutôt que de ROI), juger que tel ou tel item est plus important qu’un autre. C’est cet élément de valeur associé à l’estimation va permettre au product owner d’ordonnancer le product backlog en positionnant :

• en haut ce qui a le plus de valeur ajoutée et qui idéalement coûte le moins cher ;
• en bas les éléments qui ont le moins de valeur ajoutée et qui coutent idéalement le moins cher.

De cette façon, on traitera en premier lieu les éléments du haut du product backlog, lorsque l’on va commencer l’implémentation.

Survol de Scrum : la planification du Sprint

Une fois le product backlog prêt, on va passer à la deuxième phase de SCRUM que l’on appelle la planification du sprint.

SPRINT = ITERATION

L’identification des éléments entrant dans le sprint

Alors concrètement, il va s’agir de solliciter l’équipe de développement et le product owner pour planifier le sprint. Ensemble, ils vont identifier les éléments ordonnés en haut du product backlog pouvant entrer dans un sprint, dont on a préalablement fixer la durée. Cette durée sera en moyenne de 2 à 4 semaines maximum qui sont les durées de sprint les plus courantes. Par contre, à partir du moment où l’on a fixé une durée, on va faire attention à ce qu’elle soit toujours la même. Cela va créer un rythme régulier qui va faciliter l’analyse de indicateurs d’avancement du projet.

Une fois que l’on a identifié puis sélectionné les éléments du product backlog pouvant entrer dans un sprint, on va découper ces éléments en sous-tâches de développement. Cela devra permettre à l’équipe de se répartir plus facilement le travail. On est donc là sur des strates plus fines, donc des tâches de granularité plus affinées et plus facile à répartir.

La planification et la mise en oeuvre du sprint

Ces tâches fines vont se retrouver dans le sprint backlog et certains vont les estimer individuellement. En général en heure, puisque le but est idéalement d’avoir des tâches qui peuvent s’accomplir en moins de 8 heures (1 journée). Cela permettra de répartir encore plus facilement les tâches dans l’équipe et se rendre compte de l’avancement du sprint.

A partir de ce moment là seulement, le sprint peut démarrer. Et quotidiennement, en général le matin, pendant 15 minutes maximum, l’équipe va se synchroniser et mesurer son avancement. Puis identifier les obstacles et voir comment les lever. On est sur une planification quasiment quotidienne. On passe d’une planification à moyen terme à une planification à court terme sur les prochaines 24 heures. C’est comme cela que ça doit fonctionner en terme de coordination et de planification au quotidien.

Du premier incrément à la revue de sprint

Une fois le sprint terminé, on aboutit à ce que l’on nomme un incrément. L’incrément est en fait la première version utilisable du logiciel. Mais il n’est pas forcément évident d’obtenir des fonctionnalités dès le premier incrément. On est souvent sur un minimum de fondations et de socle technique à proposer. Mais on essaye quand même de créer au moins une fonctionnalité, très basique potentiellement, comme par exemple la première page d’accueil d’un site ou d’une application web.

Une fois que le premier incrément est prêt, on va faire ce que l’on appelle la revue de sprint. Elle va permettre de présenter cette incrément et ses fonctionnalités au product owner, au représentant des utilisateurs et aux utilisateurs eux-mêmes s’ils sont présents. Ce peut être également le moyen de donner aux sponsors une visibilité concrète sur l’avancement du projet. La revue de sprint est vraiment une étape de transparence sur le produit concret, en train de se construire. Ce ne sont pas uniquement des maquettes d’écran ou des indicateurs d’avancement du projet. On montre le produit en l’état. Alors évidemment, plus on fait de sprint, plus on a de la matière à montrer. Les premiers sont évidemment assez pauvres, mais le but est d’avoir un maximum de choses à présenter.

L’étape suivante est la rétrospective où l’équipe Scrum se réunit pour voir comment elle peut améliorer son efficacité pour le sprint suivant, en terme de :

• coordination
• processus
• méthodes techniques
• pratiques

Après la rétrospective, on boucle et l’on recommence une nouvelle phase de planification du sprint, en laissant bien sûr passer une nuit entre les deux. Et puis on recommence à nouveau, jusqu’à finalisation du produit.

Conclusion

Voici donc une vue d’avion de la méthodologie Scrum, illustré par la vidéo et l’animation de Florent Lothon. Vous avez compris que l’on a comme gardien du temple le rôle de Scrum Master, placé un peu au-dessus de tout le monde. Non pas au sens hiérarchique, mais plutôt dans le sens où il doit avoir en permanence un vue d’ensemble du projet Scrum pour bien s’assurer que toutes les briques sont mises en place et maîtrisées. Il s’assurera également que l’équipe de développement et le product owner communiquent bien au quotidien, pour avancer dans le bon sens.