Liste des articles SEO

Comment intégrer la méthode Scrum Agile dans votre gestion de projets

By 12 juin 2018 No Comments

Vous avez peut-être déjà entendu parler de la méthode de gestion de projet Agile Scrum. Celle-ci s’avère être très répandue au sein des organisations digitales.

Cette méthode a le gros avantage de fonctionner par itération et de manière incrémentale : On fait progresser son produit / service par petits bouts en prenant compte des besoins de commanditaire.
Cette méthode met l’accent sur le respect du délai et des coûts, le respect du résultat final apparait comme secondaire.

Le processus de gestion s’avère assez simple même s’il change facilement d’une organisation à une autre justement à cause de sa souplesse.

Voici quelques définitions pour bien comprendre de quoi il s’agit :

 

Sprint

Lors de la conduite d’un projet en mode Agile Scrum, le sprint désigne la phase (souvent 5 jours, parfois 10 selon le périmètre du projet) de développement d’une ou plusieurs tâches (appelées stories).
A la fin de ce sprint toutes les tâches doivent être finies et prêtes à passer en production.
Tous les jours du sprint a lieu le daily sprint meeting qui est une réunion de 15 minutes pendant laquelle chaque développeur parle des tâches qu’il a à accomplir.
Il détaille le statut de chaque tâche, les contraintes rencontrées. L’objectif est de pouvoir trouver des solutions.

 

PO (Product Owner)

Lors de la conduite d’un projet en mode Agile Scrum, le PO ou Product Owner est le propriétaire des demandes de développement.
Dans le backlog il liste les différents développements dont il a besoin pour améliorer son site ou application.
A la fin du sprint il vérifie avec les développeurs que les développements ont bien été effectués et sont prêts à passer en production.

 

Scrum Master

Lors de la conduite d’un projet en mode Agile Scrum, le scrum master n’a pas le rôle de chef de projet ou chef d’équipe, il a un rôle de facilitateur dans le déroulement du sprint.
Il a bien en tête la liste des tâches qui devront être réalisées durant le sprint. Il dirige la réunion daily sprint meeting.

 

Et voici un focus sur les étapes :

Le PO (Product Owner) liste les tâches (on les appelle des stories) qu’il veut voir réalisées dans un fichier (excel souvent) qu’on appelle le backlog.
Il y ajoute les numéros des tickets correspondant à chaque story qu’il a rempli sur un outil comme Mantis ou Redmine.

Le Scrum Master prépare le sprint suivant : Il valide avec les développeurs et le PO la liste des stories qui seront gérées pendant ce sprint, lors d’une réunion de pré lancement de sprint).
Le scrum master décrit avec les développeurs chaque story et la divise en autant de tâches que nécessaire afin de mener à bien le développement de la tâche.
Chaque développeur se voit assigné un certain nombre de stories et tâches associées.

Souvent le sprint dure 5 jours. De ce que j’ai vécu jusque maintenant, les sprint ont souvent lieu du Vendredi au Jeudi.
On fait la mise en production le Jeudi après midi, on commence un nouveau sprint le Vendredi qui se fini le jeudi matin suivant.

Chaque matin a lieu le point de débrief où chacun s’exprime sur ses stories. Le Scrum master dirige la réunion.

Souvent on utilise un grand tableau sur lequel on tient à jour le statut de la story.

Plusieurs statuts :

Les stories à réaliser, les stories en cours de développement, les stories en phase de recette, les stories prêtes à MEP.

Chaque story passe en phase de recette. C’est pendant cette phase que le product owner, l’initiateur de la story peut vérifier que les développements sont bons et correspondent à ses besoins.

 

Jeudi, tous les développements sont finis, près à être mis en production. Le Product Owner a vérifié que les développements étaient bons et correspondaient aux attentes.

Jeudi après midi a lieu la mise en production (MEP), en cas de souci, ce laps de temps avant le week end permet d’effectuer les roll backs si besoins.

A lieu ensuite la réunion de fin de sprint où chacun s’exprime sur les points positifs et points négatifs du sprint passé.
L’objectif est d’identifier les axes d’amélioration afin que les process soient toujours plus fluides et faciles à mettre en place.

Il se peut parfois que les développements nécessaires à une story aient été sous estimés ou sur estimés, cela peut avoir de graves répercussions sur
le déroulement du sprint. D’où l’idée d’anticiper au maximum les développements à planifier.

Le scrum master suit un burndown chart : c’est un tableau permettant de suivre l’évolution du volume de tâches par rapport au volume de jours restant sur le sprint.

A la fin du sprint il ne doit plus rester de tâche à finir.

Si une story a été vraiment complexe à mettre en place, il est possible de la finir dans le sprint suivant (selon les disponibilités des développeurs et selon les urgences et les besoins).

A noter que le mode de développement en mode Sprint itératif comme cela ne correspond pas à tous les projets (par exemple les projets SEO structurels parfois très impactant et pour lesquels il faut plus que 5 jours de développement).

Dans ce cas, ces chantiers peuvent être menés en parallèle du sprint.

nvidal

Author nvidal

More posts by nvidal

Leave a Reply

Conseil et formation en SEO