Qu'est-ce que Scrum ?

Scrum est une technique qui aide les équipes à travailler ensemble. Avec l'aide de laquelle l'équipe d'employés de l'entreprise doit tirer les leçons de l'expérience acquise, maîtriser les principes d'auto-organisation, travailler à résoudre le problème et analyser leurs succès et leurs échecs afin de s'améliorer constamment.

Scrum est le plus souvent utilisé par les équipes de développement d'applications, mais ses principes et son expérience peuvent être appliqués à toutes sortes de travail d'équipe. C'est l'une des raisons de la popularité de la technique. Scrum est souvent présenté comme une plateforme de gestion de projet Agile. Les membres de l'équipe Scrum tiennent des réunions, utilisent des outils dédiés et assument des rôles spécifiques pour organiser et gérer le travail.

Dans cet article, nous examinerons en quoi consistent les pratiques Scrum traditionnelles. C'est là que le guide Scrum va nous aider.

Sprints

Un sprint est uncourt laps de temps pendant lequel une équipe Scrum effectue une quantité donnée de travail. Les sprints sont au cœur des méthodologies Scrum et Agile, et choisir les bons sprints aidera votre équipe agile à fournir de meilleurs logiciels sans maux de tête inutiles.

Avec Scrum, le produit est développé en une série d'itérations à durée fixe appelées sprints, qui décomposent les grands projets complexes en petites tâches.

De nombreuses personnes associent si souvent les sprints Scrum au développement logiciel Agile que Scrum et Agile sont confondus avec des synonymes. Cependant, ce n'est pas le cas. Agile est un ensemble de principes et Scrum est une méthodologie pour résoudre activement des problèmes.

Les nombreuses similitudes entre les tâches agiles globales et les processus Scrum conduisent, à juste titre, à associer les deux concepts. Avec les sprints, les équipes peuvent suivre le principe agile de "fournir fréquemment des logiciels fonctionnels", ainsi que l'objectif agile de "répondre au changement comme prévu". Les attitudes Scrum - transparence, validation et intégration - complètent les pratiques agiles et jouent un rôle central dans le concept de sprints.

Planification et exécution du sprint Scrum

Les auteurs Scrum ont vraiment tout fate. Pour planifier un sprint à venir, vous devez organiser une réunion de planification de sprint. La planification de sprint est un exercice où l'équipe collabore pour répondre à deux questions fondamentales : quel travail peut être fait dans ce sprint, et comment sera-t-il fait ?

Il est de la responsabilité du Product Owner, du Scrum Master et de l'équipe de développement de sélectionner les éléments de travail appropriés pour le sprint. Le Product Owner définit le Sprint Goal et les tâches du Product Backlog qui permettront d'atteindre cet objectif.

L'équipe crée ensuite un plan pour les tâches du backlog à terminer d'ici la fin du sprint. Les éléments de travail sélectionnés et le plan pours les terminer sont appelés backlog de sprint. À la fin de la réunion de planification du sprint, l'équipe est prête à démarrer. Pour ce faire, il vous suffit de sélectionner des tâches dans le backlog de sprint et de changer leur statut de "En cours" à "Terminé" à mesure que le travail est terminé.

Pendant le sprint, l'équipe se réunit pour des réunions Scrum quotidiennes (stand-ups) pour discuter de l'avancement du travail. Ces réunions sont nécessaires pour identifier les bloqueurs et les problèmes qui peuvent affecter la réalisation de l'objectif du sprint.

A la fin du sprint, l'équipe montre le travail effectué dans le résumé du sprint. Ici, vous pouvez présenter les résultats de votre travail aux parties prenantes et aux autres membres de l'équipe avant qu'ils n'entrent dans l'environnement de travail.

Terminez le cycle de sprint lors de mon rendez-vous préféré, la rétrospective du sprint. C'est là que l'équipe peut identifier les domaines à améliorer dans le prochain sprint. Avec ces informations, vous pouvez commencer le prochain cycle de sprint. Effronté!

Carnet de produit

Le Product Backlog est une liste d'éléments de travail, classés par ordre d'importance, pour l'équipe de développement. Il est établi sur la base de la feuille de route et des exigences qu'elle contient. Les tâches les plus importantes sont situées au début du backlog du produit afin que l'équipe comprenne quel travail doit être effectué en premier. La vitesse à laquelle l'équipe termine les tâches du backlog est indépendante des souhaits du propriétaire du produit, et lui, à son tour, ne met pas de pression sur l'équipe. En revanche, l'équipe de développement sélectionne indépendamment les tâches du backlog produit lorsqu'elle dispose des ressources nécessaires, en les exécutant de manière continue (Kanban) ou itérative (Scrum).

À faire et à ne pas’ faire

Même si les bases sont déjà connues, la plupart des équipes trébuchent en se lançant dans les sprints.

Qu'avons nous à faire:

• Assurez-vous que l'équipe comprend le but du sprint et comment mesurer le succès. Il est important que tous les participants se mettent à l'écoute et avancent vers un objectif commun.

• Assurez-vous d'avoir un backlog clair et compréhensible avec des priorités et des dépendances. Si le backlog n'est pas correctement maintenu, cela peut devenir un gros problème et perturber le flux de travail.

• Assurez-vous de mesurer correctement la vitesse de l'équipe et de prendre en compte les événements tels que les vacances et les assemblées générales.

• Utilisez la réunion de planification de sprint pours développer votre description de tâche actuelle avec plus de détails. Encouragez les membres de l'équipe à présenter un aperçu général de toutes les histoires, bogues et problèmes qui entrent dans le sprint.

• Ignorez les tâches qui empêchent votre équipe de résoudre les problèmes de dépendance. Ces tâches comprennent le travail de l'autre équipe, la conception et la confirmation juridique.

• Enfin, après avoir pris une décision ou élaboré un plan, assurez-vous qu'il y a quelqu'un qui capture ces information dans un outil de gestion de projet ou de collaboration comme le prétend Jira. Dans ce cas, plus tard, tout le monde peut lire rapidement la décision et sa justification.

Et si vous travaillez déjà pour devenir un expert en mêlée solide en suivant les directives, consultez également la section À NE PAS FAIRE.

Ce qu'il ne faut pas’ faire.

Ne prenez pas trop d'histoires, ne surestimez pas la vitesse de travail et ne définissez pas de tâches qui ne peuvent pas être effectuées dans ce sprint. Vous ne voulez pas vous laisser tomber ou laisser tomber votre équipe, n'est-ce pas ?

N'oubliez pas la qualité et la dette technique. Assurez-vous d'avoir le temps de faire le contrôle de la qualité et le travail hors fonctionnalités, comme les corrections de bogues et les contrôles de développement.

Évitez les situations où l'équipe n'a pas une compréhension claire du contenu du sprint. Déterminez l'étendue des travaux et ne vous attardez pas sur la rapidité d'exécution; assurez-vous que tous les membres de l'équipe travaillent dans la même direction.

Aussi, ne vous engagez pas dans un travail trop vague ou risqué. Partagez de grandes histoires ou des histoires avec un degré élevé d'incertitude et n'hésitez pas à laisser une partie du travail pour le prochain sprint.

Si l'équipe exprime des préoccupations concernant la vitesse, le niveau d'incertitude dans le travail ou un volume trop important, n'ignorez pas les opinions des participants. Considérez ce problème et effectuez les ajustements nécessaires.

Planification de sprints

La planification de sprint est un événement dans Scrum qui marque le début d'un sprint. La planification détermine la quantité de travail pours le sprint et la façon dont ce travail sera effectué. La planification du sprint se fait avec l'aide de toute l'équipe Scrum.

Dans Scrum, un sprint est une durée fixe pendant laquelle tout le travail est effectué. Mais avant d'agir, le sprint doit être planifié. Il est nécessaire de déterminer la durée et le but du sprint, ainsi que le point de départ du travail. Lors de la réunion de planification du sprint, l'éventail des tâches principales et le vecteur du développement du sprint sont déterminés. Si la réunion est gérée correctement, l'équipe quitte la réunion motivée, chargée d'objectifs ambitieux et concentrée sur le succès. De mauvais plans de sprint peuvent conduire une équipe à l'arrêt si des attentes irréalistes sont présentées.

• "Quoi". Le Product Owner définit l'objectif (ou le but) principal du sprint et explique quelles tâches du backlog doivent être accomplies pour atteindre cet objectif. L'équipe Scrum décide ce qu'il faut accomplir dans le sprint à venir et ce qui doit être fait pendant le sprint.

• "Comment". L'équipe de développement établit un plan de travail à réaliser pour atteindre l'objectif du sprint. Le plan de sprint final est convenu entre l'équipe de développement et le propriétaire du produit en termes de valeur créée et d'efforts déployés.

• "Qui". La planification de sprint est impossible sans l'implication du propriétaire du produit et de l'équipe de développement. Le Product Owner se fixe un objectif qui dépend de la valeur souhaitée. L'équipe de développement doit comprendre si elle peut atteindre cet objectif (et comment le faire). Si l'une de ces parties est absente de l'événement, il devient presque impossible de planifier un sprint.

• Des données d'entrée. Le Product Backlog est un excellent point de départ pour la planification de sprint, car une grande partie peut être incorporée dans le sprint actuel. L'équipe doit également analyser le travail en cours qu'elle effectue dans l'incrément et évaluer ses propres capacités.

• Résultats. La chose la plus importante avec laquelle une équipe peut quitter une réunion de planification de sprint est de comprendre ce qui doit être accompli dans le sprint et comment commencer à avancer vers cet objectif. Cela peut être illustré en utilisant le Sprint Backlog.

Préparation de la réunion de planification de sprint

Pour qu'une réunion de planification de sprint soit un succès, une certaine organisation est nécessaire. Le Product Owner doit être prêt à revoir les leçons apprises de la précédente Revue de Sprint, et à apprendre des parties prenantes et de leur concept de produit. On peut dire qu'ils ont préparé le terrain pour le sprint. Pour rendre la situation actuelle transparente et compréhensible, le backlog produit doit être adapté aux réalités modernes et ajusté. Un événement Scrum distinct est dédié à l'affinement du backlog ; certains backlogs n'en ont pas besoin, il n'est donc pas nécessaire de l'exécuter. Cependant, la plupart des équipes doivent se réunir avant de planifier un sprint pour revoir et ajuster le backlog.

Limite de temps pour la planification de sprint

La planification du sprint ne devrait pas prendre plus de deux heures par semaine de sprint. Par exemple, une réunion de planification de sprint de deux semaines ne devrait pas durer plus de deux heures. Dans ce cas, vous limitez le temps maximum qu'une équipe peut passer à planifier un sprint. Le Scrum Master est chargé de s'assurer que tous les participants à la réunion comprennent les contraintes de temps. Si l'équipe fait le travail tôt, la réunion se termine. Seule la durée maximale d'une réunion est déterminée par des restrictions ; aucune durée minimale n'est spécifiée.

Révisions de résumé de sprint

Pour franchir la ligne d'arrivée et terminer le travail, vous devez faire un bon plan, définir les critères de préparation au travail, puis travailler méthodiquement. Cela concerne en grande partie la planification du sprint, mais les équipes ont besoin de plus qu'un plan pour évaluer avec succès le résultat du sprint et le sprint lui-même. Ils doivent articuler clairement l'approche du travail et les critères de préparation.

Des critères de préparation bien définis aident les équipes à se concentrer sur l'objectif ultime pour chaque tâche de travail. Lorsque le Product Owner ajoute du travail au backlog de l'équipe, il lui appartient de définir les critères d'acceptation. Quelle devrait être la user story terminée ? Chez Atlassian, l'équipe Jira rédige les critères d'acceptation et les notes de test au même endroit que la description de la user story Jira. Cela donne à tous les membres de l'équipe une image complète de l'avancement de chaque tâche. Que sont les critères d'acceptation et les notes de test ?

• Les critères d'acceptation sont des mesures par lesquelles un propriétaire de produit peut déterminer si un livrable de user story répond à ses exigences.

• Les notes de test sont des instructions courtes et ciblées de l'équipe d'assurance qualité qu'un développeur peut suivre pour écrire un meilleur code fonctionnel et des tests automatisés.

Lorsque les objectifs sont clairement définis, n'importe qui peut faire son travail avec succès. Vous pouvez facilement ajouter des champs supplémentaires à Jira. Pour ce faire, l'administrateur n'a qu'à cliquer sur le bouton Admin de la tâche.

Un petit conseil pour finir

Les équipes qui débutent dans les revues de synthèse de sprint ont une forte tentation de combiner la revue de synthèse avec la rétrospective. La réunion Sprint Outcome Review n'est pas associée à une rétrospective de Sprint. Prenez le temps de profiter des résultats de vos travaux. Célébrez les victoires avec courage. De bonnes critiques des résultats du sprint renforcent le moral des équipes et les motivent à en faire plus.