Partage via

Scrum et bonnes pratiques

  • Article

Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2019

Réunions de planification de sprint

Une grande partie de la planification des sprints implique une négociation entre le propriétaire du produit et l’équipe pour déterminer le focus et le travail à traiter dans le sprint à venir. Il est utile d’encadrer la réunion de planification en la limitant à 4 heures ou moins.

Dans la première partie de la réunion, votre propriétaire de produit rencontre votre équipe pour discuter des récits utilisateur qui peuvent être inclus dans le sprint. Votre propriétaire de produit partage des informations et répond à toutes les questions de votre équipe sur ces récits. Cette conversation peut révéler des détails comme les sources de données et la disposition de l’interface utilisateur. Ou elle peut révéler des attentes en matière de temps de réponse et des considérations relatives à la sécurité et à la facilité d’utilisation. Votre équipe doit capturer ces détails dans le formulaire d’éléments de backlog. Au cours de cette partie de la réunion, votre équipe apprend ce qu’elle doit créer.

Lorsque vous planifiez vos sprints, vous pouvez découvrir d’autres exigences à capturer et à ajouter à votre backlog. Assurez-vous qu’il est bien défini et dans l’ordre de priorité.

En outre, la définition d’un objectif de sprint dans le cadre de vos efforts de planification peut aider l’équipe à rester concentrée sur ce qui est le plus important pour chaque sprint.

Une fois que vous avez planifié votre sprint, vous pouvez partager le plan avec les parties prenantes principales.

Vous pouvez en apprendre plus à ce sujet en utilisant ces ressources :

Définir des objectifs de sprint

Les équipes Scrum utilisent des objectifs de sprint pour concentrer leurs activités de sprint. Elles définissent souvent cet objectif lors de leur réunion de planification de sprint. L’objectif résume ce que l’équipe souhaite accomplir à la fin du sprint. En spécifiant explicitement l’objectif, vous créez une compréhension partagée au sein de l’équipe de l’objectif principal. L’objectif de sprint peut également aider à guider l’équipe lorsque des conflits surviennent autour des priorités.

Conseils de vétérans : définir des objectifs de sprint

L’objectif de sprint définit ce que le propriétaire du produit et l’équipe considèrent comme la cible ultime pour accomplir ce sprint. Il ne s’agit pas d’une sélection aléatoire d’éléments de backlog qui n’ont pas vraiment de relation, mais d’un court texte qui capture ce que l’équipe doit essayer d’accomplir. Normalement, le propriétaire du produit établit l’objectif de sprint avant de sélectionner de nombreux éléments pour le sprint suivant. Les éléments de ce sprint doivent tous correspondre à cet objectif commun.

Les objectifs de sprint peuvent être orientés fonctionnalités, mais également avoir un composant de processus conséquent, comme l’automatisation du déploiement ou des tests.

Par exemple :

  • Pour ce sprint, nous allons nous concentrer sur un récit utilisateur simple. Nous l’utiliserons pour prouver que la solution proposée fonctionne.
  • Ce sprint tourne autour de l’implémentation des fonctionnalités de sécurité qui sécurisent correctement la section d’administration du site Web.
  • Ce sprint concerne l’intégration des passerelles de paiement les plus importantes afin que nous puissions commencer à collecter de l’argent.

La définition des objectifs de sprint aide l’équipe à rester concentrée. Cela facilite la définition de la priorité des tâches dans un sprint et contribue probablement à limiter le nombre de parties prenantes et d’utilisateurs finaux impliqués.

Lors de l’examen du sprint, la question la plus importante que vous devez vous poser est de savoir si vous avez réussi à atteindre l’objectif de sprint. Le nombre de récits que vous avez terminés passe après. Si l’objectif est atteint, le sprint réussit, même si tous les récits n’ont pas été terminés.

Contribution de Jesse Houwing, Ranger devops Visual Studio et consultant senior travaillant pour Avanade Netherlands.

Conseils pour des réunions de triage réussies

La résolution des bogues représente un compromis avec d’autres travaux. Utilisez votre réunion de triage pour déterminer l’importance de la résolution de chaque bogue par rapport à d’autres priorités liées à la réalisation de l’étendue, du budget et de la planification du projet.

  • Établissez les critères de l’équipe pour évaluer les bogues à corriger et comment attribuer la priorité et la gravité. Les bogues associés à des fonctionnalités de valeur significative (ou à un coût d’opportunité de retard important) ou à d’autres risques de projet doivent être affectés à une priorité et à une gravité plus élevées. Stockez vos critères de tri avec les autres documents d’équipe, et mettez-les à jour en fonction de vos besoins.
  • Utilisez vos critères de tri pour déterminer les bogues à corriger et comment définir leur état, leur priorité, leur gravité et autres champs.
  • Ajustez vos critères de tri en fonction de votre progression actuelle dans le cycle de développement. Au début, vous pouvez décider de corriger la plupart des bogues que vous triez. Toutefois, plus tard dans le cycle, vous pouvez relever les critères de tri pour réduire le nombre de bogues que vous devez corriger.
  • Une fois que vous avez trié un bogue, attribuez-le à un développeur. Le développeur peut ensuite l’examiner et déterminer comment implémenter un correctif.

Gérer votre dette technique

Envisagez de gérer votre barre de bogues et votre dette technique dans le cadre de l’ensemble des activités d’amélioration continue de votre équipe. Vous trouverez peut-être ces ressources intéressantes :

Conseils de vétérans : gestion des bogues

Agile Bug Management: Not an Oxymoron
par Gregg Boer, responsable de programme principal, services cloud Visual Studio chez Microsoft

Résoudre les dettes de bogues connus à chaque sprint

Lors de chaque sprint, l’équipe examine tous les bogues restants dans le backlog de bogues et dédie une capacité pour que cet ensemble connu de bogues descende à zéro, ou presque. Qu’il s’agisse d’un jour, d’une semaine ou de la totalité du sprint, vous corrigez les bogues en priorité. Les bogues trouvés après, pendant le sprint, ne sont pas considérés comme faisant partie de cet engagement initial. Sauf s’ils sont prioritaires, ils sont placés dans le backlog de bogues pour le prochain sprint.

De nombreuses équipes travaillent dans une organisation basée sur l’engagement. Souvent, la direction accorde une grande valeur à la capacité d’une équipe à respecter ses engagements. La planification de la capacité par rapport à un ensemble connu de bogues rend la planification des sprints plus déterministe, ce qui augmente les chances de l’équipe de respecter ses engagements. Les nouveaux bogues découverts lors du sprint ne font pas partie de l’engagement initial et peuvent être traités au prochain sprint.

Gérer la dette de bogues au sein d’une entreprise

Une organisation qui passe à une culture où la dette est continuellement éliminée fait probablement face à la question suivante : comment faire pour que les équipes réduisent leur nombre de bogues sans leur dire exactement quoi faire ? La direction souhaite que l’équipe change, mais lui donne l’autonomie pour déterminer comment elle le fait. Une option consiste à utiliser une limite de bogues.

Par exemple, considérez un maximum de trois bogues par ingénieur. Par conséquent, une équipe de 10 personnes ne devrait pas avoir plus de 30 bogues dans son backlog de bogues. Si l’équipe est au-dessus de ce plafond, elle est censée arrêter son travail sur les nouvelles fonctionnalités et passer sous le plafond des bogues. Une équipe est censée être toujours sous sa limite, mais elle choisit comment accomplir cela. Le plafond de bogues garantit que les équipes ne portent pas de dettes de bogues pendant trop longtemps. L’équipe peut apprendre des erreurs qui provoquent l’apparition des bogues en premier lieu.

N’oubliez pas que la limite de bogues représente les bogues dans le backlog de bogues. Elle n’inclut pas les bogues trouvés et corrigés pendant le sprint au cours duquel une fonctionnalité est développée. Ces bogues sont considérés comme du travail non résolu, et non comme faisant partie de la dette.

Bien que les bogues contribuent à la dette technique, ils peuvent ne pas représenter toute la dette.

Une conception logicielle médiocre, un code mal écrit ou des correctifs à court terme peuvent tous contribuer à la dette technique. La dette technique reflète le travail de développement supplémentaire qui découle de tous ces problèmes.

Suivez le travail pour résoudre la dette technique en tant qu’éléments de backlog de produit, récits utilisateur ou bogues. Pour suivre la progression d’une équipe dans l’exécution et le traitement de la dette technique, vous devez réfléchir à la façon de catégoriser l’élément de travail et les détails que vous souhaitez suivre. Vous pouvez ajouter des étiquettes à n’importe quel élément de travail pour le regrouper dans une catégorie de votre choix.

Rôle du Scrum Master

Les Scrum Masters aident à créer et à maintenir des équipes saines en utilisant des processus Scrum. Ils guident, accompagnent, enseignent et aident les équipes Scrum dans l’emploi approprié des méthodes Scrum. Les Scrum Masters jouent également le rôle d’agents de changement pour aider les équipes à surmonter les obstacles et à conduire l’équipe vers des augmentations significatives de la productivité.

Les principales responsabilités des Scrum Masters sont les suivantes :

  • Aidez l’équipe à adopter et à suivre les processus Scrum. Par exemple, vous ne devez pas laisser la réunion Scrum quotidienne devenir une discussion ouverte qui dure 45 minutes.

  • Empêchez le propriétaire du produit ou les membres de l’équipe d’ajouter du travail après le début du sprint.

  • Éliminez les problèmes bloquants qui empêchent l’équipe de progresser. Ce travail peut vous obliger à effectuer de petites tâches, comme l’approbation d’un bon de commande pour un nouvel ordinateur de build ou la résolution d’un conflit au sein de votre équipe.

  • Aidez l’équipe à résoudre les conflits et les problèmes qui surviennent et à tirer des enseignements du processus.

  • Posez des questions qui révèlent des problèmes cachés et vérifient que les personnes qui communiquent sont bien comprises par l’ensemble de l’équipe.

  • Identifiez et protégez l’équipe contre les problèmes potentiels qui deviennent des problèmes majeurs. Tout comme il est moins coûteux de corriger un bogue peu après sa découverte, il est également plus facile et moins perturbant de résoudre un problème d’équipe quand il est encore petit et gérable.

  • Empêchez l’équipe de présenter des récits utilisateur incomplets lors d’une réunion de révision sprint.

  • Rassemblez, analysez et présentez des données aux parties prenantes de l’entreprise pour montrer comment l’équipe s’améliore et se développe. Par exemple, si votre équipe a augmenté la quantité de valeur qu’elle a fournie tout en générant moins de bogues, rendez cette valeur visible par le biais de communications régulières avec les parties prenantes de l’entreprise.

Les bons Scrum Masters ont ou développent d’excellentes compétences en communication, en négociation et en résolution de conflits. Ils écoutent activement les mots que les gens disent et écrivent. Ils écoutent également la façon dont ils transmettent leurs messages, par exemple leur langage corporel, leurs expressions faciales, leur rythme vocal et d’autres communications non verbales.

Tout comme il est moins coûteux de corriger un bogue peu après sa découverte, il est également plus facile et moins perturbant de résoudre un problème d’équipe quand il est petit et gérable, avant qu’il se transforme en problème majeur.

Réunions Scrum quotidiennes

Les réunions Scrum quotidiennes permettent à une équipe de rester concentrée sur ce qu’elle doit faire le lendemain. Rester concentré aide l’équipe à maximiser sa capacité à respecter les engagements de sprint. Votre Scrum Master doit appliquer la structure de la réunion et s’assurer qu’elle commence à l’heure et se termine en moins de 15 minutes.

Trois aspects des réunions Scrum réussies sont les suivants :

  • Tout le monde est debout. La position debout permet de garder les réunions ciblées et courtes.
  • Elles commencent et se terminent à l’heure et se produisent au même moment au même endroit chaque jour
  • Tout le monde participe, et chaque membre de l’équipe répond aux trois questions Scrum :
    • Qu’ai-je accompli depuis le dernier Scrum ?
    • Que puis-je accomplir avant le prochain Scrum ?
    • Quels obstacles ou problèmes bloquants peuvent affecter mon travail ?

Notes

Lors des réunions Scrum, l’accent est mis sur l’état du travail qui doit être transmis d’un membre de l’équipe à un autre.

Les membres de l’équipe doivent s’efforcer de répondre rapidement et de manière concise à leurs questions. Par exemple :

« Hier, j’ai mis à jour la classe pour refléter le nouvel élément de données que nous extrayons de la base de données, et je l’ai fait apparaître dans l’interface. Cette tâche est terminée. Aujourd’hui, je m’assure que le nouvel élément de données calcule correctement avec la procédure stockée et les autres éléments de données de la table. Je pense que je peux terminer cette tâche aujourd’hui. J’ai besoin de quelqu’un pour vérifier mes calculs. Je n’ai pas d’obstacles ni de problèmes bloquants. »

Cette réponse indique ce que le membre de l’équipe a accompli, ce qu’il prévoit d’accomplir et le fait qu’il souhaite obtenir de l’aide pour vérifier le code.

À l’inverse, prenez l’exemple suivant :

« Hier, j’ai travaillé sur la classe, et ça marche. Aujourd’hui, je travaille sur l’interface. Pas de problèmes bloquants. »

Le membre d’équipe ne fournit pas suffisamment de détails sur la classe sur laquelle il a travaillé ni sur les composants d’interface qu’il va terminer. En fait, le mot terminé n’apparaît même pas.

Il est important que personne n’interrompe les autres pendant les rapports. Chaque personne doit avoir suffisamment de temps pour répondre aux trois questions.

Les discussions plus approfondies et de suivi doivent avoir lieu après la réunion, quand les personnes retournent à leur bureau ou, si une longue conversation est nécessaire, pendant une réunion de suivi.

De nombreuses équipes retardent les discussions en utilisant la méthode du « parking virtuel ». Quand un membre de l’équipe pense avoir besoin d’une discussion plus approfondie, il peut tranquillement marcher jusqu’à un tableau blanc ou de conférence et ajouter le sujet au « parking ». À la fin de la réunion, l’équipe détermine comment elle va gérer les éléments qui y sont répertoriés.

Réunions de révision de sprint

Organisez vos réunions de révision de sprint le dernier jour du sprint. Votre équipe présente chaque élément de backlog de produit qu’elle a terminé lors du sprint. Le propriétaire du produit, les clients et les parties prenantes acceptent les récits utilisateur qui répondent à leurs attentes et identifient les nouvelles exigences. Les clients comprennent souvent mieux leurs besoins après avoir vu les démonstrations et peuvent identifier les modifications qu’ils souhaitent voir.

Sur la base de cette réunion, certains récits utilisateur sont acceptés comme étant complets. Les récits utilisateur incomplets restent dans le backlog de produit. De nouveaux récits utilisateur sont ajoutés au backlog. Les deux ensembles de récits sont classés et estimés, ou estimés à nouveau lors de la prochaine réunion de planification de sprint.

Après cette réunion et la réunion rétrospective, votre équipe planifie le prochain sprint. Étant donné que les besoins de l’entreprise évoluent rapidement, vous pouvez tirer parti de cette réunion avec votre propriétaire de produit, vos clients et les parties prenantes pour passer à nouveau en revue les priorités du backlog de produit.

Réunions rétrospectives de sprint

Les rétrospectives, lorsqu’elles sont bien menées et à intervalles réguliers, soutiennent l’amélioration continue.

La réunion rétrospective de sprint se produit généralement le dernier jour du sprint, après la réunion de révision de sprint. Au cours de cette réunion, votre équipe explore l’exécution de Scrum et ce qui pourrait nécessiter des ajustements.

En fonction des discussions, votre équipe peut modifier un ou plusieurs processus pour améliorer son efficacité, sa productivité, sa qualité et sa satisfaction. Cette réunion et les améliorations résultantes sont essentielles au principe Agile de l’auto-organisation.

Notes

Pour prendre en charge la rétrospective de votre équipe, envisagez d’installer l’extension Rétrospectives de la Place de marché. Cette extension prend en charge la collecte de commentaires sur les jalons de votre projet, l’organisation et la hiérarchisation des commentaires, ainsi que la création et le suivi de tâches concrètes pour aider votre équipe à s’améliorer au fil du temps.

Recherchez ces points lors des rétrospectives de sprint de votre équipe :

  • Problèmes qui ont affecté l’efficacité générale, la productivité et la qualité de votre équipe.

  • Éléments qui ont affecté la satisfaction globale de votre équipe et le flux de projet.

  • Quelle a été la cause des éléments de backlog incomplets ? Quelles mesures l’équipe peut-elle prendre pour éviter ces problèmes à l’avenir ?

    Par exemple, considérez une équipe qui avait plusieurs tâches qu’une seule personne de l’équipe pouvait effectuer. L’expertise isolée a créé un chemin critique qui a menacé le succès du sprint. Le membre de l’équipe a travaillé des heures supplémentaires, tandis que les autres membres de l’équipe étaient frustrés de ne pas pouvoir en faire plus pour aider. À l’avenir, l’équipe a décidé de pratiquer la programmation eXtreme pour l’aider à corriger ce problème au fil du temps.

En tant qu’équipe, déterminez s’il faut adapter un ou plusieurs processus pour réduire l’occurrence de problèmes pendant le sprint.

Votre équipe peut avoir besoin de faire du travail pour implémenter une amélioration. Par exemple, une équipe qui s’est trouvée affectée négativement par un trop grand nombre de builds ayant échoué a décidé d’implémenter l’intégration continue. Comme ils ne voulaient pas interrompre le processus, ils ont passé quelques heures à configurer une build de test avant de l’activer dans leur build de production. Pour représenter ce travail, ils ont créé un pic et organisé ce travail par rapport au reste du backlog de produit.