Utiliser concrètement Scrum, devenir un expert Scrum / Scrum Master

Publié dans: 

Les logiciels sont de plus en plus complexes, et changent régulièrement, surtout en phase de développement. Du coup, les méthodologies de développement traditionnelles ont montré des limites devant ces évolutions, surtout pour les grands projets.

 

Cet article a été publié dans le numéro 162 (Avril 2013) du magazine « PROgrammez ». La version PDF de l’article est mise à votre disposition en téléchargement gratuit.

Aujourd’hui les logiciels font partie du quotidien de l’être humain. Pas seulement les développeurs, mais aussi les utilisateurs finaux, partant des professionnels (banquiers, assureurs, financiers)  et allant jusqu’aux particuliers.
Les logiciels sont de plus en plus complexes, et changent régulièrement surtout en phase de développement. Du coup les méthodologies de développement traditionnelles ont montré des limites devant ces évolutions, surtout pour les grands projets.
En effet, avec les méthodologies classiques, il n’y a pas d’interaction entre le client (propriétaire du logiciel ou produit) et l’équipe de développement. Le client ne voit le résultat qu'à la livraison finale et rien ou presque rien pendant toute la phase de développement. D’où l’effet tunnel.
Cet effet tunnel en lui-même génère un autre risque au projet. C’est le risque de modification ou d’ajout de fonctionnalités. Avec les méthodologies classiques, ce genre de modifications, qui sont demandé par le client, surviennent généralement à une phase très avancée du projet où toute modification est très risquée.
Une des méthodes qui s’est distinguée et qui a montré son efficacité face à cette évolution est la méthodologie agile ou "Scrum". Cet article essayera d’expliquer les bonnes pratiques à suivre pour utiliser concrètement SCRUM.

SCRUM ?


Scrum est un cadre structuré pour soutenir le développement de produits complexes, cette méthodologie se compose d'équipe Scrum et de leurs rôle et d'évènements. Scrum s'appuie sur le découpage d'un projet en incréments, nommés "sprint" ou "itération".
Le besoin du client (ou spécifications) est traduit en backlog de produit. A chaque sprint l’équipe traite une partie de ce backlog, appelée backlog de sprint.
Mais connaitre la définition de scrum  ne garantit ni l’efficacité de la méthodologie, ni la réussite du projet. Il faut suivre les bonnes pratiques de scrum.
A quoi ressemble une équipe scrum ? Quel est le rôle de chacun ? Qui fait quoi ?
L'équipe Scrum est constituée d'un product owner (propriétaire de produit), de l'équipe de développement et d'un Scrum Master.
Le product owner est le client, il est chargé de maximiser la valeur du produit et du travail de l'équipe de développement. Cela se concrétise d'une manière qui varie considérablement selon les organisations, les équipes Scrum et les individus. Le product owner est la seule personne responsable de la gestion du backlog de produit.
La gestion du backlog de produit comprend :

  • Exprimer clairement les items du backlog de produit

  • Hiérarchiser les items du backlog de produit pour mieux atteindre les objectifs et les missions

  • S'assurer de la valeur du travail que l'équipe de développement réalise

  • S'assurer que le backlog de produit est visible, transparent et clair pour tous et qu’il décrit bien le travail à venir pour l'équipe.

  • S'assurer que l'équipe de développement comprend suffisamment les items du backlog  de produit.

L’équipe de développement est composée de professionnels qui livrent à chaque sprint livrable du produit. Seuls les membres de l’équipe de développement réalisent ce livrable.
Les équipes de développement ont les caractéristiques suivantes :

  • Elles sont auto-organisées. Personne (pas même le Scrum Master) ne peut dicter à l’équipe comment traduire le backlog  de produit en incréments de fonctionnalités potentiellement livrables.

  • Elles sont pluridisciplinaires, ayant toutes les compétences nécessaires pour mettre en œuvre un livrable du produit.

  • Individuellement, les membres d’une équipe peuvent être spécialisés dans certaines compétences ou dans certains domaines, mais la responsabilité appartient à l'équipe de développement dans son ensemble.

  • Les équipes de développement ne contiennent pas de sous équipes dédiées à un domaine en particulier comme les tests ou l’analyse métier (fonctionnelle).

La taille d’une équipe de développement doit être optimale :

  • Assez petite pour demeurer agile

  • Assez grande pour effectuer du travail significatif.

Moins de trois membres dans l'équipe de développement diminue les interactions et entraîne des gains de productivité moindres. Une équipe de développement trop petite peut rencontrer des contraintes de compétences pendant le sprint, menant l'équipe à être incapable de terminer un incrément potentiellement livrable.
Plus de neuf membres exige trop de coordination. Les grandes équipes de développement génèrent trop de complexité pour être gérées par un processus empirique. Les rôles du product owner et du Scrum Master ne sont pas inclus dans ce nombre, sauf s'ils participent également à la réalisation des travaux du backlog  de sprint.
Le Scrum Master est responsable de la compréhension et de l’application de Scrum. Pour cela il ou elle s’assure que l’équipe Scrum adhère aux valeurs, pratiques et règles de Scrum. Le rôle de Scrum Master est celui de meneur au service de l’équipe Scrum « Servant Leader ».
Le Scrum Master sert le product owner de plusieurs façons, notamment :

  • En trouvant des techniques pour la gestion efficace du backlog  de produit

  • En communiquant clairement la vision, les objectifs et les items du backlog  de produit à l'équipe de développement

  • En enseignant à l'équipe de développement comment créer des items de backlog  clairs et concis

  • En comprenant la planification à long terme du produit dans un environnement empirique

  • En comprenant et pratiquant l'agilité

  • En facilitant les évènements Scrum à la demande ou lorsque c’est nécessaire.

Le Scrum Master sert l'équipe de développement de plusieurs façons, notamment :

  • En aidant l’équipe de développement à apprendre comment s'auto-organiser et développer sa transversalité

  • En enseignant et en menant l'équipe de développement à livrer des produits de haute valeur

  • En supprimant les obstacles nuisant au progrès de l'équipe de développement

  • En facilitant des évènements Scrum à la demande ou lorsque c’est nécessaire

  • En accompagnant l'équipe de développement dans les environnements organisationnels dans lesquels Scrum n’est pas encore complètement adopté et compris.

Quels sont les évènements scum ?


Des évènements prescrits sont utilisés dans Scrum afin de créer de la régularité et de minimiser la nécessité de réunions qui ne sont pas définies dans Scrum.
Ces évènements sont :

  • Réunion de planification de sprint

  • Le sprint

  • Daily meeting (mêlée quotidienne)

  • Revue de sprint

  • Rétrospective de sprint

Réunion de planification de sprint

Les travaux à effectuer durant le sprint sont planifiés lors de la réunion de planification de sprint. Ce plan est créé par la collaboration de toute l'équipe Scrum. La réunion de planification de sprint est, généralement,  un bloc de temps de huit heures
La réunion de planification de sprint se compose de deux parties, chacune utilisant la moitié du temps total alloué pour la planification. Les deux parties de la réunion de planification de sprint répondent aux questions suivantes :

  • Qu’est-ce qui sera livré dans l’incrément résultant du prochain sprint ?

Dans cette partie, l'équipe de développement choisit les fonctionnalités qui seront livrées au cours du sprint. Le product owner présente à l'équipe de développement les items hiérarchisés du backlog  de produit et toute l'équipe Scrum travaille alors ensemble sur la compréhension du travail à effectuer dans le sprint.
Les items sélectionnés du backlog de produit pour ce sprint est appelé le backlog de sprint

  • Comment le travail nécessaire pour réaliser l'incrément sera-t-il accompli ?

Après avoir choisi le travail du sprint, l'équipe de développement décide comment elle va réaliser, durant le sprint, un livrable (incrément de produit).
L’équipe de développement décompose  le backlog de sprint en tâches et s'auto-organise pour estimer et dispatcher ces tâches sur entres les membres.
Une fois les tâches estimées, l’équipe aura une visibilité sur la durée du sprint et estime la date de fin du sprint.
Le product owner peut être présent lors de la deuxième partie de la réunion de planification de sprint pour clarifier les items sélectionnés du backlog de produit et afin de contribuer à trouver des compromis. Si l'équipe de développement détermine qu'elle a trop de travail, ou bien qu’elle n’en a pas assez, elle peut renégocier avec le product owner les items du backlog de sprint. L'équipe de développement peut également inviter d'autres personnes à la réunion afin de fournir des conseils techniques ou sur le domaine (consultants métiers, …).

Daily Meeting (Mêlée quotidienne) :

Le daily meeting est une réunion limitée à un bloc de temps de 15 minutes et destinée à permettre à l’équipe de développement de synchroniser ses activités et planifier les prochaines 24 heures. Pour ce faire, le travail réalisé depuis le dernier daily meeting est inspecté et une prévision du travail qui pourra être réalisé avant la prochaine mêlée est énoncée.
Le daily meeting a lieu tous les jours à la même heure et au même endroit afin de réduire la complexité. Pendant la réunion chaque membre de l’équipe de développement décrit :

  • Ce qu’il a réalisé depuis la dernière réunion

  • Ce qu’il réalisera avant la prochaine réunion

  • Les difficultés qu’il rencontre.

L’équipe de développement se sert du daily meeting  pour évaluer l’atteinte de l’objectif du sprint ainsi qu’évaluer comment se fait la progression vers la finalisation du travail du backlog de sprint.
Le Scrum Master s’assure que le daily meeting a lieu mais c’est l’équipe de développement qui est responsable du déroulement de la réunion. Le Scrum Master apprend à l’équipe de développement comment limiter le daily meeting à un bloc de temps de 15 minutes. 
Le Scrum Master veille à l’application de la règle stipulant que seuls les membres de l’équipe de développement participent au daily meeting. Le daily meeting n’est pas une réunion d’avancement et est destinée aux personnes en charge de transformer les items du backlog de produit en fonctionnalités livrables. 
Les daily meetings améliorent la communication, réduisent le nombre de réunions, identifient et suppriment les obstacles qui perturbent le développement, mettent en avant et encouragent la prise de décision rapide et améliorent la compréhension du projet par l’équipe de développement. Il s’agit d’une réunion d’inspection et d’adaptation primordiale.

La Revue de sprint :

La revue de sprint est une réunion qui se déroule à la fin de chaque itération etcomprend les éléments suivants :

  • Le product owner identifie ce qui a été terminé et ce qui n’a pas été  terminé

  • L'équipe de développement discute de ce qui s'est bien déroulé durant le sprint, quels problèmes ont été rencontrés, et comment ces problèmes ont été résolus

  • L'équipe de développement démontre le travail terminé et répond aux questions sur l'incrément

  • Le product owner discute du backlog de produit tel qu'il est. Il ou elle détermine des dates probables d’achèvement en fonction des progrès à ce jour

  • L'ensemble du groupe convient de ce qu'il faut faire pour la suite, de sorte que la revue de sprint fournisse une contribution précieuse aux réunions subséquentes de planification de sprint

Le résultat de la revue de sprint est un backlog de produit révisé qui définit les items probables pour le prochain sprint. Le backlog de produit peut également être complètement revu pour répondre à de nouvelles opportunités.
Rétrospective de sprint
La rétrospective de sprint est une occasion pour l'équipe Scrum de s'inspecter et de créer un plan d'améliorations qui sera mis en place au cours du sprint suivant.
Le but de la rétrospective de sprint est :

  • D’inspecter la manière dont le dernier sprint s'est déroulé en ce qui concerne les personnes, les relations, les processus et les outils

  • D’identifier et ordonner les éléments majeurs qui se sont bien déroulés et les améliorations potentielles

  • De créer un plan pour améliorer les processus de travail de l'équipe Scrum.

Le Scrum Master encourage l'équipe Scrum à améliorer, dans le cadre du processus Scrum, son processus de développement et ses pratiques afin de les rendre plus efficaces et agréables pour le prochain sprint. Lors de chaque rétrospective de sprint, l'équipe Scrum planifie des moyens adéquats d'accroître la qualité du produit, en adaptant sa définition de ’terminé’.
À la fin de la rétrospective de sprint, l'équipe Scrum devrait avoir identifié les améliorations qu'elle mettra en œuvre durant le prochain sprint. La mise en œuvre de ces améliorations au cours du prochain sprint est l'adaptation à l'inspection de l'équipe de développement elle-même. Bien que des améliorations puissent être mises en œuvre à tout moment, la rétrospective de sprint fournit un évènement dédié et axé sur l'inspection et l'adaptation.

En Résumé …

Scrum implique tout le monde dans la réalisation d’un projet, le product owner, le scum master et l’équipe de développement.
L’équipe de développement est le noyau de l’équipe scrum, mais sans l’implication du product owner et du scrum Master, scrum sera loin d’être efficace.
Le principal rôle d’un Scrum Master est de veiller à l’application des événements scrum, au respect des règles de la méthodologie et à l’implication de toute l’équipe (surtout le product owner).
La méthodologie expliquée ci-dessous peut varier d’un projet à un autre, d’une entreprise à une autre.  Dans certains cas des adaptations doivent être faites afin de mieux gérer le projet.