La métho­do­lo­gie Scrum vue d’avion

Nous vous propo­sons aujour­d’hui un survol de la métho­do­lo­gie Scrum qui va vous permettre de mieux appré­hen­der 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 prota­go­nistes.

Extrait de la vidéo de forma­tion : Chal­lenge Scrum Master

Dans cette vidéo, je vais vous propo­ser de vous donner une vue d’avion du cadre métho­do­lo­gique Scrum. Nous abor­de­rons toutes étapes du projet Scrum, à savoir :

• le product back­log et son fonc­tion­ne­ment
• la plani­fi­ca­tion du sprint
• l’in­cré­ment et la revue de sprint

La centra­li­sa­tion des éléments dans le product back­log

Au coeur de la métho­do­lo­gie Scrum, on trouve le product owner qui va centra­li­ser ses besoins ou ses exigences dans un product back­log. Chacun des éléments du product back­log va ensuite être estimé par une équipe de déve­lop­pe­ment qui peut elle aussi suggé­rer, voire impo­ser, des exigences non fonc­tion­nelles ou tech­niques, qui sont les pré-requis aux fonda­tions ou au socle sur lequel va s’ap­puyer le produit.

Mais c’est toujours le product owner qui a le dernier mot sur ce que va conte­nir le product back­log. Donc souvent, l’équipe de déve­lop­pe­ment doit expliquer ou vulga­ri­ser les raisons d’être des éléments du product back­log.

Une fois que l’esti­ma­tion a été faite, le product owner va pouvoir, grâce à la valeur de chaque élément (on parlera de valeur ajou­tée plutôt que de ROI), juger que tel ou tel item est plus impor­tant qu’un autre. C’est cet élément de valeur asso­cié à l’es­ti­ma­tion va permettre au product owner d’ordon­nan­cer le product back­log en posi­tion­nant :

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

De cette façon, on trai­tera en premier lieu les éléments du haut du product back­log, lorsque l’on va commen­cer l’im­plé­men­ta­tion.

Survol de Scrum : la plani­fi­ca­tion du Sprint

Une fois le product back­log prêt, on va passer à la deuxième phase de SCRUM que l’on appelle la plani­fi­ca­tion du sprint.

SPRINT = ITERA­TION

L’iden­ti­fi­ca­tion des éléments entrant dans le sprint

Alors concrè­te­ment, il va s’agir de solli­ci­ter l’équipe de déve­lop­pe­ment et le product owner pour plani­fier le sprint. Ensemble, ils vont iden­ti­fier les éléments ordon­nés en haut du product back­log pouvant entrer dans un sprint, dont on a préa­la­ble­ment fixer la durée. Cette durée sera en moyenne de 2 à 4 semaines maxi­mum 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 atten­tion à ce qu’elle soit toujours la même. Cela va créer un rythme régu­lier qui va faci­li­ter l’ana­lyse de indi­ca­teurs d’avan­ce­ment du projet.

Une fois que l’on a iden­ti­fié puis sélec­tionné les éléments du product back­log pouvant entrer dans un sprint, on va décou­per ces éléments en sous-tâches de déve­lop­pe­ment. Cela devra permettre à l’équipe de se répar­tir plus faci­le­ment le travail. On est donc là sur des strates plus fines, donc des tâches de granu­la­rité plus affi­nées et plus facile à répar­tir.

La plani­fi­ca­tion et la mise en oeuvre du sprint

Ces tâches fines vont se retrou­ver dans le sprint back­log et certains vont les esti­mer indi­vi­duel­le­ment. En géné­ral en heure, puisque le but est idéa­le­ment d’avoir des tâches qui peuvent s’ac­com­plir en moins de 8 heures (1 jour­née). Cela permet­tra de répar­tir encore plus faci­le­ment les tâches dans l’équipe et se rendre compte de l’avan­ce­ment du sprint.

A partir de ce moment là seule­ment, le sprint peut démar­rer. Et quoti­dien­ne­ment, en géné­ral le matin, pendant 15 minutes maxi­mum, l’équipe va se synchro­ni­ser et mesu­rer son avan­ce­ment. Puis iden­ti­fier les obstacles et voir comment les lever. On est sur une plani­fi­ca­tion quasi­ment quoti­dienne. On passe d’une plani­fi­ca­tion à moyen terme à une plani­fi­ca­tion à court terme sur les prochaines 24 heures. C’est comme cela que ça doit fonc­tion­ner en terme de coor­di­na­tion et de plani­fi­ca­tion au quoti­dien.

Du premier incré­ment à la revue de sprint

Une fois le sprint terminé, on abou­tit à ce que l’on nomme un incré­ment. L’in­cré­ment est en fait la première version utili­sable du logi­ciel. Mais il n’est pas forcé­ment évident d’ob­te­nir des fonc­tion­na­li­tés dès le premier incré­ment. On est souvent sur un mini­mum de fonda­tions et de socle tech­nique à propo­ser. Mais on essaye quand même de créer au moins une fonc­tion­na­lité, très basique poten­tiel­le­ment, comme par exemple la première page d’ac­cueil d’un site ou d’une appli­ca­tion 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ésen­ter cette incré­ment et ses fonc­tion­na­li­tés au product owner, au repré­sen­tant des utili­sa­teurs et aux utili­sa­teurs eux-mêmes s’ils sont présents. Ce peut être égale­ment le moyen de donner aux spon­sors une visi­bi­lité concrète sur l’avan­ce­ment du projet. La revue de sprint est vrai­ment une étape de trans­pa­rence sur le produit concret, en train de se construire. Ce ne sont pas unique­ment des maquettes d’écran ou des indi­ca­teurs d’avan­ce­ment du projet. On montre le produit en l’état. Alors évidem­ment, plus on fait de sprint, plus on a de la matière à montrer. Les premiers sont évidem­ment assez pauvres, mais le but est d’avoir un maxi­mum de choses à présen­ter.

L’étape suivante est la rétros­pec­tive où l’équipe Scrum se réunit pour voir comment elle peut amélio­rer son effi­ca­cité pour le sprint suivant, en terme de :

• coor­di­na­tion
• proces­sus
• méthodes tech­niques
• pratiques

Après la rétros­pec­tive, on boucle et l’on recom­mence une nouvelle phase de plani­fi­ca­tion du sprint, en lais­sant bien sûr passer une nuit entre les deux. Et puis on recom­mence à nouveau, jusqu’à fina­li­sa­tion du produit.

Conclu­sion

Voici donc une vue d’avion de la métho­do­lo­gie Scrum, illus­tré par la vidéo et l’ani­ma­tion 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érar­chique, mais plutôt dans le sens où il doit avoir en perma­nence un vue d’en­semble du projet Scrum pour bien s’as­su­rer que toutes les briques sont mises en place et maîtri­sées. Il s’as­su­rera égale­ment que l’équipe de déve­lop­pe­ment et le product owner commu­niquent bien au quoti­dien, pour avan­cer dans le bon sens.