Agile Mëtteg Mai: Scrum et Backlog

Agile Mëtteg Mai: Scrum et Backlog

logo_agile_metteg-v2

Lors de ce dernier Agile Mëtteg de mai, nous avons mis en avant les notions de Scrum et Backlog “Evolution des priorités dans le développement de logiciels : contrainte ou opportunité ? “. L’idée était de mettre en avant la notion de tâches et de priorités des éléments dans le Backlog en Scrum. Pour ce faire, Arnaud Lamouller-Bonaventure, coach agile chez Agile Partner s’est prêté au jeu de l’Agile Mëtteg et a proposé une séance d’information d’1h.

Mais tout d’abord, remettons dans son contexte Scrum. Ce framework n’est pas uniquement destiné aux  équipes IT. Mais il est un bon vecteur pour comprendre les équipes. Dans un context global, tout peut être agile. L’ Agile Manifesto est une forme de “guide”, très court, sans être un grand manuel. L’agilité est une formule s’adaptant dans différent context et évoluant dans ce context. Il ne faut pas dire “Faire de la méthodologie Agile” car l’agilité n’est pas une méthodologie. Cependant il existe des méthodologies dans l’agilité. Agile est simplement un guideline. Avec l’agilité, les équipes se focalisent sur la valeur de l’application et non les coûts, permettant la création de valeurs ajoutés.

L’agilité n’est pas révolutionnaire et n’est pas le fruit d’une seule personne. L’agilité est arrivée dans les année 80-90 et avec le début de l’IT. Les équipes n’étaient pas satisfaites de la création de logiciel de type waterfall, méthode traditionnelle, exemple:

Besoin -> Définition des spécificités fonctionnelles -> Définition des spécificité technique -> Développement -> Test -> Mise en production

Cette gestion de projet n’est plus adapté à l’IT.

Le manifest Agile est créé avec et à la suite d’un ensemble de retours d’expériences des personnes ayant réussis avec des résultats dans des projets IT. Avec l’agilité, les individus, le logiciel, la collaboration et l’adaptation sont privilégiés. Les équipes s’organisent pour avoir la capacité d’encaisser les changements.

Scrum et le backlog

Le Backlog est une liste ordonnée de fonctionnalités, prioritisées par leur valeur métier et dont les complexités ont été estimées. Pour avoir cette liste, l’équipe réalise un découpage fonctionnelle de la demande. Toute l’application n’est pas développée en une seule fois mais par plusieurs étapes, avec les fonctionnalités les plus importantes.

Exemple de découpage – par ordre de priorité décidé par le Product Owner – pour la fonctionnalité “gestion du compte utilisateur” d’un site internet :

  1. Création compte
  2. Mise à jour du compte
  3. Supprimer compte
  4. Import d’une compte via réseaux sociaux

La grande fonction de gestion d’utilisateur est découpée en 4 “petites tâches”. L’ensemble du projet est appelé “épic“. Dés qu’un besoin a été implémenté, il peut être mis en production et l’entreprise peut commencer à bénéficier de la valeur ainsi produite. Ensuite l’équipe récupère les feedbacks d’utilisateurs suite à cette mise en production pour s’adapter aux utilisateurs. Par exemple, les utilisateurs réclament la création de compte par un import à partir des réseaux sociaux. Avec l’agilité, l’équipe est prête à s’adapte au changement. Ce qui fait revoir les priorités:

  1. Création du compte – En production
  2. Import du compte via les réseaux sociaux – En cours
  3. Mise à jour du compte
  4. Supprimer le compte

Pour implémenter le contenu du backlog, l’équipe peut utiliser le framework Scrum. Ce framework est facile à comprendre mais néanmoins difficile à maitriser. Le Sprint Backlog est un sous-ensemble du Product Backlog que l’équipe s’engage à réaliser durant un sprint (entre 1 et 4 semaines). Toutes les fonctionnalités pour un sprint donné sont dedans. Si toutes les conditions ne sont pas encore réunies pour réaliser une tâche, celle-ci sera reportée dans un prochain sprint.

Le sprint planning est une réunion pour définir la liste des priorités, avec l’équipe, à mettre dans le sprint backlog. Celles-ci s’ajoutent en fonction des compétences et des capacités des développeurs. Les tâches qui ne seraient pas finies durant un sprint ne sont pas livrées et seront achevées au prochain sprint si rien n’apportant plus de valeur ne vient s’ajouter au backlog.

Pour ajouter les tâches dans le sprint backlog, il faut calculer la valeur métier, souvent avec une unité numérique. Toute l’équipe de développeurs estime une tâche. Si jamais les avis divergent, les deux extrémités d’estimation justifient leur choix. Après une courte discussion, l’équipe donne une nouvelle valeur à la tâche et la valide en l’ajoutant dans le sprint backlog.

C’est ainsi que les priorités sont ajoutées pour chacune des tâches. Durant le sprint et le développement, l’équipe va piocher les tâches en fonction des priorités et de leurs compétences pour faire évoluer le projet.

 

 

Annabelle Buffart

Web geek

No Comments

Post a Comment

Comment
Name
Email
Website