Menu

Méthodologie Agile: Guide du débutant sur la méthode Agile et Scrum

agile methodology beginner s guide agile method

Essayez Notre Instrument Pour Éliminer Les Problèmes

Un guide complet de la méthodologie Agile: (20+ tutoriels détaillés sur la méthodologie Agile Scrum)

Ceci est le guide pour les développeurs de logiciels et les testeurs pour comprendre et commencer à travailler sur le très célèbre Méthodologie Agile SCRUM pour le développement et les tests de logiciels . Apprenez les terminologies de base mais importantes utilisées dans le processus Agile Scrum avec un exemple réel du processus complet.

Nous avons répertorié tous les tutoriels Agile de cette série pour votre commodité. J'espère qu'ils vous seront d'une immense aide.

Sujets couverts: Qu'est-ce que l'Agile, Qu'est-ce que Scrum, Méthodologie Agile dans le développement et les tests logiciels, Tests Agile, Processus Agile Scrum, Méthodologie Scrum avec Scrum Team et Scrum Master.

introduction au développement agile

Ce que vous apprendrez:

Liste des didacticiels de méthodologie Agile

Tutoriel n ° 1: Méthodologies Agile Scrum (Ce tutoriel)
Tutoriel n ° 2: Manifeste Agile
Tutoriel n ° 3: L'équipe Scrum et leurs rôles et responsabilités
Tutoriel n ° 4: Artefacts Scrum
Tutoriel n ° 5: Événements Scrum
Tutoriel n ° 6: Tri des défauts dans Scrum
Tutoriel n ° 7: Équipes Scrum autosuffisantes
Tutoriel n ° 8: Principe des trois Amigo
Tutoriel n ° 9: SAFe - Cadre agile mis à l'échelle
Tutoriel n ° 10: Quiz Agile Scrum

PLUS de tutoriels Agile Scrum recommandés:

Tutoriel n ° 11: Principales techniques d'estimation agile
Tutoriel n ° 12: Modèle hybride Agile Waterfall
Tutoriel n ° 13: Kanban vs Scrum vs Agile
Tutoriel n ° 14: Tutoriel JIRA Agile
Tutoriel n ° 15: Réunions rétrospectives agiles
Tutoriel n ° 16: Rôle des analystes commerciaux dans SCRUM
Tutoriel n ° 17: Rôle du contrôle qualité dans Scrum

Outils et questions d'entrevue:

Tutoriel n ° 18: Outils de test agiles
Tutoriel n ° 19: Meilleurs outils de gestion de projet agile
Tutoriel n ° 20: Les principales questions d'entrevue Agile
Tutoriel n ° 21: Top des questions d'entrevue Scrum

Commençons par le premier tutoriel de la série - Introduction à Agile Scrum.

Introduction au développement agile

Agile en développement logiciel:

Agile est l’un des cadres de développement logiciel les plus utilisés et les plus reconnus au monde.

La plupart des organisations l'ont adopté sous une forme ou une autre, mais il reste encore un long chemin à parcourir dans la maturité de leurs programmes d'adoption. Le seul objectif de cette série de didacticiels est d'intégrer les professionnels de la technologie et non technologiques dans le monde agile.

Nous vous guiderons à travers le parcours Agile étape par étape jusqu'à ce que vous compreniez la philosophie derrière l'utilisation d'Agile, ses avantages et comment la mettre en pratique. Cette série vise à équiper et à permettre aux lecteurs d'appliquer l'apprentissage Agile et Scrum dans leur travail.

Ce tutoriel particulier est dédié à vous expliquer pourquoi il y avait un besoin d'Agile et comment il a été créé. L'essentiel ici est de vous faire comprendre le concept de l'adoption agile dans les industries de développement de logiciels.

Histoire de l'Agile

Agile est né quand, un beau jour, 17 personnes ayant des connaissances en méthodologies de développement différentes se sont réunies pour réfléchir à la possibilité d'une solution alternative au développement logiciel qui pourrait conduire à un temps de développement plus rapide et moins lourde en documentation.

À cette époque, le développement de logiciels se faisait si longtemps qu'au moment où les projets étaient prêts à être livrés, l'entreprise avait progressé et les exigences avaient changé. Ainsi, un projet n'était pas en mesure de répondre aux besoins de l'entreprise même s'il était en mesure d'atteindre ses objectifs définis.

Ainsi, ces champions des différentes techniques d’ingénierie logicielle se sont réunis et le résultat final de leur rencontre a été ce qu’ils ont appelé le «manifeste agile» dont nous parlerons en détail dans le prochain tutoriel de cette série.

Mais l'agilité qui est née ce jour-là n'est pas ce que nous voyons aujourd'hui dans les organisations. La méthodologie convenue par ces experts a été qualifiée de «légère» et rapide. Mais la principale victoire de cette réunion était la pensée qu'une livraison plus rapide d'un produit et un retour d'information constant étaient les clés du succès dans le développement de logiciels.

Les techniques de cascade existantes étaient trop lourdes et ne prévoyaient aucun retour d'information tant que le produit final n'était pas prêt à être livré. Cela signifiait qu'il n'y avait aucune possibilité de correction de cap et que le client n'avait aucune vue sur les progrès tant que le produit n'était pas prêt. Et c'est ce que ces experts voulaient éviter.

Ils voulaient une solution qui puisse bénéficier d'un retour d'information constant afin d'éviter le coût de retouches à un stade ultérieur.

Défis agiles

Les techniques de cascade existantes à l'époque étaient trop lourdes et ne prévoyaient pas de rétroaction tant que le produit final n'était pas prêt à être livré. Cela s'appelait un modèle de développement en cascade parce que les équipes ont d'abord terminé une étape complètement et seulement après cela, elles sont passées à l'étape suivante.

Cela signifiait qu'il n'y avait aucune possibilité de correction de cap et que le client n'avait aucune vue sur les progrès tant que le produit n'était pas prêt. Et c'est ce que ces experts voulaient éviter. Ils voulaient une solution qui puisse bénéficier d'un retour d'information constant afin d'éviter le coût de retouches à un stade ultérieur.

Et c'est pourquoi l'agilité, c'est aussi être adaptatif et s'améliorer continuellement, autant qu'il s'agit d'un feedback constant et d'une rapidité de livraison.

Que sont les promesses agiles?

Promesses agiles

Agile ne consiste pas seulement à appliquer les pratiques établies dans le développement de logiciels. Cela entraîne également un changement dans l’état d’esprit de l’équipe, ce qui les pousse à créer de meilleurs logiciels, à travailler ensemble et à devenir un client heureux.

Les valeurs et principes agiles permettent à l'équipe de changer d'orientation et de changer son processus de réflexion pour créer de meilleurs logiciels.

Qu'est-ce qu'agile exactement?

Agile n'est pas un ensemble de règles. Agile n'est pas un ensemble de directives. Agile n'est même pas une méthodologie. Au contraire, Agile est un ensemble de principes qui encouragent la flexibilité, l'adaptabilité, la communication et le fonctionnement des logiciels sur les plans et les processus. Il est très succinctement capturé dans ce qu'on appelle le manifeste agile.

Le développement logiciel agile permet à l'équipe de travailler ensemble plus efficacement et plus efficacement dans le développement de projets complexes. Il se compose de pratiques qui exercent des techniques itératives et incrémentales qui sont facilement adoptées et donnent d'excellents résultats.

Pour appliquer Agile à l'action, nous avons diverses méthodes et méthodologies basées sur Agile. Ces méthodes et méthodologies répondent à tous les besoins d'une industrie de développement de logiciels, de la conception et de l'architecture de logiciels, du développement et des tests à la gestion de projet et aux livraisons.

Non seulement cela, les méthodes et méthodologies Agiles ouvrent également la voie à l'amélioration des processus en tant que partie intégrante de chaque livraison.

Agile est une approche de développement logiciel dans laquelle une équipe autosuffisante et interfonctionnelle travaille à effectuer des livraisons continues par itérations et évolue tout au long du processus en recueillant les commentaires des utilisateurs finaux.

Comment pratiquer Agile?

Il existe diverses méthodologies Agile qui sont en pratique dans diverses industries diversifiées.

Méthodologies Agiles

Cependant, les méthodologies les plus populaires parmi toutes sont:

  • Scrum
  • Kanban
  • Programmation extrême

Toutes ces méthodologies se concentrent sur le développement de logiciels allégés et aident à créer de meilleurs logiciels de manière efficace et efficiente.

C'est tout avec l'introduction Agile. La partie est structurée pour vous aider à comprendre les valeurs et principes fondamentaux qui doivent être adoptés pour qu'une équipe travaille dans un mode et un état d'esprit Agile.

Agile Méthodologie

Introduction aux modèles agiles:

Méthodologie agile

différence entre les tests de boîte noire et les tests de boîte blanche

Comme nous le savons tous, Agile est une méthodologie de développement logiciel.

Nous avons également pris connaissance des valeurs et des principes mentionnés dans le manifeste agile par les fondateurs d'agile. Lors de nos discussions initiales, nous avons également évité les différences entre les modèles agiles et traditionnels en cascade.

Dans ce tutoriel, nous apprendrons à connaître les avantages et les inconvénients de la méthodologie agile.

Nous verrons ce qu'est la mêlée? et en quoi est-il différent de l'agilité. Ensuite, nous comprendrons les différentes méthodologies agiles qui sont utilisées par différentes organisations et comment pouvons-nous mettre en œuvre l'agilité en les utilisant.

Vous pourrez également apprécier la différence et aussi les avantages / inconvénients de ces méthodologies.

Avantages de la méthodologie Agile

Vous trouverez ci-dessous les différents avantages de la méthodologie Agile:

  • Les clients ont en permanence un aperçu de l'avancement du projet à la fin de chaque itération / sprint.
  • Chaque sprint fournit au client un logiciel fonctionnel qui répond à ses attentes selon la définition du done fourni par lui.
  • Les équipes de développement sont assez réactives aux exigences changeantes et peuvent s'adapter aux changements même aux stades avancés de développement.
  • Il y a une communication bidirectionnelle constante qui maintient les clients impliqués, ainsi toutes les parties prenantes - commerciales et techniques - ont une visibilité claire sur l'avancement du projet.
  • La conception du produit est efficace et répond aux exigences de l'entreprise.

Inconvénients de la méthodologie Agile

Bien que la méthodologie Agile présente plusieurs avantages, elle comporte également certains inconvénients.

Elles sont:

#1) Une documentation complète n'est pas préférée, ce qui peut conduire les équipes agiles à interpréter à tort cela, car Agile ne nécessite pas de documentation. La rigueur se perd donc dans la documentation. Cela doit être évité en vous demandant continuellement si ces informations sont suffisantes pour continuer ou non.

#deux) Parfois, au début des projets, les exigences ne sont pas claires. Les équipes peuvent continuer et constater que la vision des clients a été réalignée et dans de telles situations, les équipes doivent intégrer de nombreux changements et il est également difficile d'évaluer le résultat final.

Types de méthodologies agiles

Il existe plusieurs méthodologies agiles en pratique à travers le monde. Nous allons en apprendre plus en détail sur quatre des plus populaires.

Types de méthodologies agiles

# 1) Scrum

Scrum peut facilement être considéré comme le framework agile le plus populaire. Le terme «scrum» est souvent considéré comme synonyme de «agile» par la plupart des praticiens. Mais c'est une idée fausse. Scrum n'est que l'un des frameworks par lesquels vous pouvez implémenter Agile.

Le mot scrum vient du rugby sportif. Où les joueurs se blottissent ensemble dans une position verrouillée poussant contre les adversaires. Chaque joueur a un rôle défini dans sa position et peut jouer à la fois offensif et défensif selon la demande de la situation.

De même, la mêlée informatique croit en des équipes de développement autogérées autonomes avec trois rôles spécifiques et clairement définis. Ces rôles comprennent - Product Owner (PO), Scrum Master (SM) et l'équipe de développement composée des programmeurs et des testeurs . Ils travaillent ensemble dans des durées itératives en boîte de temps appelées sprints.

La première étape est la création du backlog produit par le PO. C’est une liste de choses à faire par l’équipe de mêlée. Ensuite, l'équipe Scrum sélectionne les éléments les plus prioritaires et essaie de les terminer dans la zone de temps appelée sprint.

Un moyen plus simple de se souvenir de tout cela est de mémoriser le cadre 3-3-5. Cela signifie qu'un projet Scrum a 3 rôles, 3 artefacts et 5 événements.

Ceux-ci sont -

Rôles: PO, Scrum master et équipe de développement.

Artefacts: Backlog produit, Backlog SprintetIncrément de produit.

Événements: Sprint, planification de sprint, Daily Scrum, revue de sprint et rétrospective de sprint.

3-3-5 cadre

Nous en apprendrons plus en détail sur chacun d'entre eux dans nos prochains tutoriels.

# 2) Kanban

Kanban est un terme japonais qui signifie une carte. Ces cartes contiennent des détails sur les travaux à effectuer sur le logiciel. Le but est la visualisation. Chaque membre de l'équipe est conscient du travail à effectuer grâce à ces aides visuelles.

Les équipes utilisent ces cartes Kanban pour une livraison continue. Tout comme Scrum, Kanban sert également à aider les équipes à travailler efficacement et à promouvoir des équipes autogérées et collaboratives.

Mais il y a aussi des différences entre ces deux - comme lors d'un sprint Scrum, les éléments sur lesquels travaille une équipe sont corrigés et nous ne pouvons pas ajouter d'éléments au sprint alors que, dans Kanban, nous pouvons ajouter des éléments s'il y a de la capacité disponible. Ceci est particulièrement utile lorsque les exigences changent fréquemment.

De même, une autre différence est que si la mêlée a défini les rôles d'un PO, d'un scrum master et des équipes de développement, il n'y a pas de tels rôles prédéfinis dans Kanban.

Une autre différence est que si la mêlée suggère une hiérarchisation des backlogs de produits, Kanban n'a pas une telle exigence et c'est totalement facultatif. Ainsi Kanban nécessite moins d'organisation et évite les activités sans valeur ajoutée et convient aux processus qui nécessitent une réactivité face aux changements.

# 3) Maigre

Lean est une philosophie axée sur la réduction des déchets. Comment fait-il cela?

Dans le lean, vous divisez un processus en activités à valeur ajoutée, activités sans valeur ajoutée et activités essentielles sans valeur ajoutée. Toute activité qui peut être classée comme une activité sans valeur ajoutée est un gaspillage et nous devrions essayer d'éliminer ce gaspillage dans le processus pour le rendre plus léger.

Un processus allégé signifie une livraison plus rapide et moins d'efforts gaspillés dans les tâches qui n'aident pas à atteindre les objectifs de l'équipe. Cela permet d'optimiser chaque étape du cycle de développement logiciel. C'est pourquoi les principes du lean ont été adaptés de la fabrication au plus juste au développement logiciel.

Le développement de logiciels Lean peut être utilisé dans n'importe quel projet informatique en appliquant les sept principes Lean présentés ci-dessous:

sept principes lean

Ceux-ci sont assez explicites comme leurs noms le suggèrent. L'élimination du gaspillage est le premier et le plus important principe Lean et nous avons vu comment faire cela, nous classons simplement les activités en valeur et sans valeur ajoutée.

Une activité sans valeur ajoutée peut être n'importe quelle partie du code qui pourrait le rendre moins robuste, augmenter l'effort impliqué et prendre beaucoup de temps sans ajouter de valeur commerciale justifiable. Il peut également s'agir de récits d'utilisateurs vagues, de tests médiocres ou d'ajout de fonctionnalités qui ne sont pas nécessaires dans l'ensemble.

Le deuxième principe d'amplification de l'apprentissage est à nouveau facile à comprendre car une équipe a besoin de diverses compétences pour livrer des produits dans un environnement en évolution rapide avec de nouvelles technologies apparaissant rapidement.

Prendre des décisions tardives peut être gratifiant dans des circonstances où cela réduit les retouches, par exemple si des changements sont attendus, mieux vaut le retarder afin que l'équipe n'ait pas à refaire le travail à mesure que les besoins de l'entreprise changent.

Mais il y a toujours un compromis ici car les équipes doivent équilibrer cela avec le quatrième principe de livraison plus rapide. Le report des décisions ne doit pas avoir d'incidence sur la prestation globale et ne doit pas réduire le rythme de travail. Un œil doit toujours être sur l'image complète.

Avoir des équipes responsabilisées est également très courant de nos jours et c'est quelque chose que même agile suggère. Les équipes habilitées sont plus responsables et peuvent prendre des décisions plus rapidement. Le sentiment d'appartenance dans une équipe responsabilisée conduit à de meilleurs résultats. Pour habiliter une équipe, ils doivent être autorisés à s'organiser et à prendre des décisions par eux-mêmes.

Ainsi, nous voyons que le lean et l'agile ont beaucoup en commun avec une différence flagrante: alors que les équipes lean peuvent aider à affiner un produit, les équipes agiles sont celles qui construisent réellement le produit.

# 4) Programmation extrême (XP)

La programmation extrême est une autre technique agile la plus populaire. Selon extremeprogramming.org, le premier projet XP a été lancé le 6 mars 1996. Ils mentionnent également que XP a un impact sur le développement de projets logiciels de 5 manières différentes: communication, simplicité, rétroaction, respect et courage. Celles-ci sont appelées les valeurs de XP.

Hors de ceux-ci, tout commence par la communication. Les équipes XP collaborent régulièrement avec des équipes commerciales et d'autres programmeurs et commencent à créer du code dès le premier jour. L'accent est mis ici sur la communication face à face autant que possible à l'aide des autres aides visuelles.

Les programmeurs extrêmes créent également un code simple et commencent à recevoir des commentaires dès le premier jour. L'objectif est de ne pas aller trop loin ou de ne pas prévoir des exigences qui n'ont pas été partagées. Cela garde la conception simple et produit juste le produit minimum qui répondra aux exigences.

Le feedback aide l'équipe à s'améliorer et à produire une meilleure qualité de travail. Cela les aide à se respecter mutuellement tout en apprenant les uns des autres et en apprenant à partager leurs points de vue.

Cela leur donne également le courage car ils savent qu'ils ont rassemblé les meilleures idées de chacun et produit un bon produit avec les commentaires des autres. Ainsi, ils n'ont pas non plus peur d'inclure des changements ou de recevoir d'autres commentaires sur leur travail.

Ceci est particulièrement utile dans les projets où les exigences vont souvent changer. Un retour d'information constant aidera les équipes à intégrer ces changements avec courage.

Ainsi, nous avons vu les différentes méthodologies agiles comme Scrum, XP, Kanban et Lean avec leurs avantages et inconvénients respectifs.

Maintenant, nous pouvons facilement les différencier et apprécier les différences plus subtiles entre eux. Nous avons également appris les fondamentaux de chacune de ces méthodologies et vu comment les appliquer dans nos projets au fur et à mesure des besoins.

Dans la partie suivante, nous allons tout comprendre sur Scrum.

Méthodologie Scrum

SCRUM est un processus en méthodologie agile qui est une combinaison du modèle itératif et du modèle incrémental.

Un des handicaps majeurs du traditionnel Modèle de cascade était-ce - jusqu'à ce que la première phase soit terminée, l'application ne passe pas à l'autre phase. Et par hasard, s'il y a des changements dans la dernière étape du cycle, il devient alors très difficile de mettre en œuvre ces changements, car cela impliquerait de revoir les phases antérieures et de refaire les changements.

Test de mêlée agile

Certaines des principales caractéristiques de SCRUM comprennent:

  • Équipe auto-organisée et concentrée.
  • Pas d'énormes documents d'exigence, plutôt avoir une histoire très précise et au point.
  • Les équipes interfonctionnelles travaillent ensemble comme une seule unité.
  • Communiquez étroitement avec le représentant des utilisateurs pour comprendre les fonctionnalités.
  • A un calendrier défini de maximum un mois.
  • Au lieu de faire tout le «truc» à la fois, Scrum fait un peu de tout à un intervalle donné.
  • La capacité et la disponibilité des ressources sont prises en compte avant de s'engager.

Pour bien comprendre cette méthodologie, il est important de comprendre les terminologies clés de SCRUM.

Lire aussi => Comment fournir des fonctionnalités logicielles de grande valeur dans un court laps de temps à l'aide du processus Agile Scrum

Terminologies importantes de SCRUM

1) Équipe Scrum

L'équipe Scrum est une équipe de 7 personnes avec + ou - deux membres. Ces membres sont un mélange de compétences et comprennent des développeurs, des testeurs, des personnes de base de données, des personnes de support, etc. ainsi que le propriétaire du produit et un scrum master.

Tous ces membres travaillent ensemble en étroite collaboration pendant un intervalle récursif et défini, pour développer et implémenter lesdites fonctionnalités. La disposition des sièges des équipes SCRUM joue un rôle très important dans leur interaction, ils ne s'assoient jamais dans des cabines ou des cabines, mais sur une immense table.

Équipe Scrum

2) Sprint

Le sprint est un intervalle ou un laps de temps prédéfini dans lequel le travail doit être terminé et le rendre prêt pour la révision ou pour le déploiement en production. Cette case de temps se situe généralement entre 2 semaines et 1 mois.

logiciel de feuille de temps gratuit pour les petites entreprises

Dans notre vie de tous les jours, quand nous disons que nous suivons un cycle de Sprint d'un mois, cela signifie simplement que nous travaillons pendant un mois sur les tâches et que nous les préparons pour examen d'ici la fin de ce mois.

3) Propriétaire du produit

Le propriétaire du produit est la partie prenante clé ou l'utilisateur principal de l'application à développer. Le propriétaire du produit est la personne qui représente le côté client. Il / elle a l'autorité finale et doit toujours être disponible pour l'équipe.

Il / elle doit être joignable lorsque quelqu'un a des doutes nécessitant des éclaircissements. Il est important que le propriétaire du produit comprenne et n'assigne aucune nouvelle exigence au milieu du sprint ou lorsque le sprint a déjà commencé.

4) Scrum Master

Scrum Master est l'animateur de l'équipe Scrum. Il / elle s'assure que l'équipe Scrum est productive et progressive. En cas d'obstacles, Scrum Master les suit et les résout pour l'équipe. SCRUM Master est le médiateur entre le PO et l'équipe.

Il / elle tient le PO informé de l'avancement du Sprint. S'il y a des obstacles ou des préoccupations pour l'équipe, discute avec le PO et les résout. Comme le Daily Standup de l'équipe, un standup du SCRUM Master avec le PO a lieu tous les jours.

Lecture recommandée => Comment être un bon mentor d'équipe, un entraîneur et un vrai défenseur d'équipe dans un monde de tests agiles?

5) Analyste d'affaires (BA)

Un Business Analyst joue un rôle très important dans SCRUM. Cette personne est responsable de la finalisation et de la rédaction de l'exigence dans les documents d'exigence (sur la base desquels les user stories sont créées).

S'il y a des ambiguïtés dans les critères User Stories / Acceptation, c'est lui qui est approché par l'équipe technique (SCRUM) et il la porte ensuite au PO ou bien si possible se résout de lui-même. Dans les projets à grande échelle, il peut y avoir plus d'un BA, mais dans les projets à petite échelle, le Master SCRUM peut également faire office de BA.

C'est toujours une bonne pratique d'avoir un BA au démarrage du projet.

6) Histoire d'utilisateur

Les user stories ne sont rien d'autre que les exigences ou les fonctionnalités qui doivent être implémentées.

Dans la mêlée, nous n’avons pas ces énormes documents sur les exigences, mais les exigences sont définies dans un seul paragraphe, généralement au format:

As a
je veux
Atteindre

Par exemple :

En tant qu'administrateur, je veux avoir un mot de passe verrouillé au cas où l'utilisateur entre un mot de passe incorrect pendant 3 fois consécutives pour restreindre l'accès non autorisé.

Certaines caractéristiques des user stories doivent être respectées. Les user stories doivent être courtes, réalistes, peuvent être estimées, complètes, négociables et testables. Une user story n'est jamais modifiée ou modifiée au milieu du sprint.

Il est de la responsabilité du SCRUM Master et du BA (le cas échéant) de s'assurer que le PO a rédigé correctement les User Stories avec un ensemble approprié de Critères d'acceptation ». Si des modifications qui auront un impact sur la sortie du sprint doivent être apportées, alors ces histoires sont retirées du sprint ou elles sont effectuées selon les heures disponibles.

Chaque user story a un critère d'acceptation qui doit être bien défini et compris par l'équipe.

Les critères d'acceptation détaillent la user story qui fournit les pièces justificatives. Cela permet d'affiner davantage la user story. N'importe qui de l'équipe peut écrire les critères d'acceptation. L'équipe de test fonde ses cas / conditions de test sur ces critères d'acceptation.

7) Épopées

Les épopées sont des user stories équivoques ou on peut dire que ce sont les user stories qui ne sont pas définies et qui sont conservées pour les sprints futurs.

Essayez simplement de le relier à la vie, imaginez que vous partez en vacances. Au fur et à mesure que vous partez la semaine prochaine, vous avez tout en place comme vos réservations d'hôtel, vos visites touristiques, vos chèques de voyage, etc. Mais qu'en est-il de votre plan de vacances pour l'année prochaine? Vous n'avez qu'une vague idée que vous pouvez aller chez XYZ, mais vous n'avez pas de plan détaillé.

Une épopée est comme le plan de vacances de l’année prochaine, où vous savez que vous voudrez peut-être aller, mais où, quand, avec qui, tous ces détails, vous n’avez aucune idée pour le moment.

De la même manière, il existe des fonctionnalités qui doivent être implémentées dans le futur dont les détails ne sont pas encore connus. La plupart du temps, une fonctionnalité commence par un Epic, puis se décompose en histoires qui pourraient être implémentées.

8) Backlog produit

Le backlog de produit est une sorte de seau ou de source où toutes les user stories sont conservées. Ceci est maintenu par le Product Owner. Le backlog de produit peut être imaginé comme une liste de souhaits du propriétaire du produit qui le priorise en fonction des besoins de l'entreprise.

Lors de la réunion de planification (voir la section suivante), une user story est extraite du backlog produit, puis l'équipe fait le brainstorming, la comprend et l'affine et décide collectivement quelles user stories prendre, avec l'intervention du product owner.

9) Backlog de sprint

En fonction de la priorité, les user stories sont extraites du Product Backlog une par une. L'équipe Scrum réfléchit à cela pour déterminer la faisabilité et décider des histoires à travailler sur un sprint particulier. La liste collective de toutes les user stories sur lesquelles l'équipe Scrum travaille sur un sprint particulier est connue sous le nom de backlog Sprint.

Backlog de sprint

10) Points d'histoire

Les story points sont une indication quantitative de la complexité d'une user story. Sur la base du point de l'histoire, l'estimation et les efforts pour une histoire sont déterminés.

Un point d'histoire est relatif et non absolu. Afin de nous assurer que notre estimation et nos efforts sont corrects, il est important de vérifier que les user stories ne sont pas volumineuses. Plus la user story est précise et petite, plus l'estimation sera précise.

Chaque user story est assignée à un story point basé sur la série Fibonacci (1, 2, 3, 5, 8, 13 & 21). Plus haut est le nombre, le complexe est l'histoire.

Pour être précis

  • Si vous donnez 1/2/3 point d'histoire, cela signifie que l'histoire est petite et de faible complexité.
  • Si vous donnez des points comme 5/8, c'est un complexe moyen et
  • 13 et 21 sont très complexes.

Ici, la complexité comprend à la fois le développement et l'effort de test.

Pour décider d'un point d'histoire, un brainstorming a lieu au sein de l'équipe Scrum et l'équipe décide collectivement d'un point d'histoire.

Il peut arriver que l'équipe de développement donne un point d'histoire de 3 à une histoire particulière, car pour eux, il peut s'agir de 3 lignes de changement de code, mais l'équipe de test donne 8 points d'histoire car ils estiment que ce changement de code affectera des modules plus grands. l'effort de test serait plus important. Quel que soit le point de l'histoire que vous donnez, vous devez le justifier.

Donc, dans cette situation, un brainstorming se produit et l'équipe accepte collectivement un point d'histoire.

Chaque fois que vous décidez d'un point d'histoire, gardez à l'esprit les facteurs ci-dessous:

  • La dépendance de l'histoire avec une autre application / module.
  • L'ensemble des compétences de la ressource.
  • La complexité de l'histoire.
  • Apprentissage historique.
  • Critères d'acceptation de la user story.

Si vous n'êtes pas au courant d'une histoire en particulier, ne la dimensionnez pas.

Chaque fois qu'une histoire vaut = ou> 8 points, elle est décomposée en 2 histoires ou plus.

11) Graphique brûlé

Le graphe déroulant est un graphique qui montre l'effort réel v / s estimé des tâches Scrum.

C'est un mécanisme de suivi par lequel, pour un sprint particulier, les tâches quotidiennes sont suivies pour vérifier si les histoires progressent ou non vers l'achèvement des points d'histoire engagés.

Exemple : Pour comprendre cela, vérifiez la figure ci-dessous:

Burn Down graphique 1

J'ai supposé:

  • Sprint de 2 semaines (10 jours)
  • 2 ressources travaillant sur le sprint.

'Histoire' -> Cette colonne montre les user stories prises pour le sprint.

'Tâche' -> Cette colonne affiche la liste de la tâche associée à la user story.

'Effort' -> Cette colonne montre l'effort. Maintenant, cette mesure est l'effort total pour terminer la tâche. Il ne décrit pas l'effort déployé par un individu en particulier.

'Jour 1 - Jour 10' -> Cette (ces) colonne (s) indique les heures qui restent pour terminer l'histoire. Veuillez noter que l'heure n'est PAS l'heure qui est déjà faite MAIS les heures qui restent.

'Effort estimé' -> Est le total de l'effort. Pour le «Début», il s'agit simplement de la somme de la tâche individuelle entière: SOMME (C5: C15)

Un nombre total d'efforts à réaliser en 1 jour est de 70/10 = 7. Donc à la fin du jour 1, l'effort devrait être réduit à 70 - 7 = 63. De la même manière, il est calculé pour tous les jours jusqu'au jour 10, lorsque l'effort estimé doit être de 0 (ligne 16)

'Effort réel restant' -> Comme son nom l'indique, c'est l'effort qui reste pour terminer l'histoire. Il peut également arriver que les efforts réels augmentent ou diminuent par rapport à l'estimation.

Vous pouvez utiliser les fonctions intégrées et le graphique dans Excel pour créer ce graphique de burndown.

Les étapes de Burn Down Chart seraient:

  1. Entrez toutes les histoires (Colonne A5 - A15).
  2. Entrez toutes les tâches (Colonne B5 - B15).
  3. Entrez les jours (jour 1 - jour 10).
  4. Saisissez les efforts de démarrage (additionnez les tâches C5 - C15).
  5. Appliquez la formule pour calculer les «efforts estimés» pour chaque jour (du jour 1 au jour 10). Entrez la formule à J15 (C16- $ C $ 16/10) et faites-la glisser pour tous les jours.
  6. Pour chaque jour, entrez les efforts réels. Entrez la formule à J17 (SOMME (D5: D15)) pour résumer les efforts réels restants, et faites-la glisser pour tous les autres jours.
  7. Sélectionnez-le et créez le graphique comme suit:

Burn Down graphique 2

12) Vitesse

Le nombre total de points d'histoire qu'une équipe Scrum archive dans un sprint est appelé Velocity. L'équipe Scrum est jugée ou référencée par sa vélocité. Cela dit, il faut garder à l’esprit que l’objectif ici n’est PAS d’atteindre le maximum de points, mais d’avoir un livrable de qualité, respectant le niveau de confort de l’équipe de mêlée.

Par exemple : Pour un sprint particulier: le nombre total de user stories est de 8 ayant des story points comme indiqué ci-dessous.

Vitesse de Scrum

Donc ici la vitesse sera la somme des points d'histoire = 30

Définition de fait:

Un Sprint est marqué comme Terminé lorsque toutes les histoires sont terminées, toutes les tâches de développement, de recherche et d'assurance qualité sont marquées `` Terminées '', tous les bogues sont corrigés-fermés sinon ceux qui peuvent être faits plus tard (comme pas complètement liés ou sont moins importants) sont retirés et ajoutés au backlog, la révision du code et les tests unitaires sont terminés, les heures estimées ont atteint les heures réelles consacrées aux tâches et, surtout, une démonstration réussie a été donnée au PO et aux parties prenantes.

Activités réalisées dans la méthodologie SCRUM

# 1) Réunion de planification

Une réunion de planification est le point de départ du Sprint. C'est la réunion où toute l'équipe Scrum se réunit, le SCRUM Master sélectionne une user story en fonction de la priorité du backlog produit et l'équipe réfléchit dessus.

Sur la base de la discussion, l'équipe Scrum décide de la complexité de l'histoire et la dimensionne selon la série Fibonacci. L'équipe identifie les tâches ainsi que les efforts (en heures) qui seraient faits pour terminer la mise en œuvre de la user story.

Bien souvent, la réunion de planification est précédée d'une «réunion de pré-planification». C’est comme les devoirs que fait l’équipe Scrum avant de s’asseoir pour la réunion de planification officielle. L'équipe essaie d'écrire les dépendances ou d'autres facteurs dont elle aimerait discuter lors de la réunion de planification.

# 2) Exécution des tâches de sprint

Comme son nom l'indique, il s'agit du travail réel effectué par l'équipe Scrum pour accomplir sa tâche et amener la user story à l'état «Terminé».

# 3) Standup quotidien

Pendant le cycle de sprint, chaque jour, l'équipe de mêlée se réunit pendant 15 minutes au maximum (peut être un appel debout, recommandé d'avoir au début de la journée) et énonce 3 points:

  1. Qu'a fait le membre de l'équipe hier?
  2. Qu'est-ce que le membre de l'équipe prévoyait de faire aujourd'hui?
  3. Des obstacles (barrages routiers)?

C'est le Scrum master qui facilite cette rencontre. Dans le cas où un membre de l'équipe est confronté à des difficultés, le scrum master fait le suivi pour le résoudre. Dans Stand ups, le tableau est également revu et montre en lui-même la progression de l'équipe.

# 4) Réunion d'examen

À la fin de chaque cycle de sprint, l'équipe SCRUM se réunit à nouveau et démontre les user stories implémentées au product owner. Le propriétaire du produit peut vérifier les histoires selon ses critères d'acceptation. Il est à nouveau de la responsabilité du Scrum master de présider cette réunion.

Toujours dans l'outil SCRUM, le Sprint est fermé et les tâches sont marquées comme terminées.

# 5) Réunion rétrospective

La réunion rétrospective a lieu après la réunion d'examen.

L'équipe SCRUM se réunit, discute et documente les points suivants:

  • Qu'est-ce qui s'est bien passé pendant le Sprint (Meilleures pratiques)?
  • Qu'est-ce qui ne s'est pas bien passé dans le Sprint?
  • Leçons apprises
  • Éléments d'action.

L'équipe Scrum doit continuer à suivre les meilleures pratiques, ignorer les «pas les meilleures pratiques» et mettre en œuvre les leçons apprises lors des sprints qui en découlent. La réunion rétrospective permet de mettre en œuvre l'amélioration continue du processus SCRUM.

Comment se déroule le processus? Un exemple!

Après avoir lu les jargons techniques de SCRUM. laissez-moi essayer de démontrer l'ensemble du processus avec un exemple.

Exemple:

Étape 1 : Nous avons une équipe SCRUM de 9 personnes comprenant 1 propriétaire de produit, 1 Scrum master, 2 testeurs, 4 développeurs et 1 DBA.

Étape 2 : Le Sprint est décidé à suivre un cycle de 4 semaines. Nous avons donc un Sprint d'un mois du 5 juin au 4ede juillet.

Étape 3 : Le Product Owner a la liste hiérarchisée des user stories dans le backlog du produit.

Étape 4: L'équipe décide de se réunir le 4eJuin pour la réunion «Pre Planning».

  • Le Product Owner prend 1 histoire du backlog du produit, la décrit et laisse à l'équipe le soin de réfléchir.
  • Toute l'équipe discute et communique directement au product owner pour avoir bien compris la user story.
  • De la même manière, diverses autres user stories sont prises. Si possible, l'équipe peut aller de l'avant et dimensionner également les histoires.

Après toute la discussion, les membres individuels de l'équipe retournent à leurs postes de travail et

  • Identifiez leurs tâches individuelles pour chaque histoire.
  • Calculez le nombre exact d'heures pendant lesquelles ils travailleront. Voyons comment le membre conclut ces heures.

Nombre total d'heures de travail = 9
Moins 1 heure pour une pause, moins 1 heure pour les réunions, moins 1 heure pour les courriels, les discussions, le dépannage, etc.
Donc, les heures de travail réelles = 6.
Un nombre total de jours ouvrables pendant le Sprint = 21 jours.
Nombre total d'heures disponibles = 21 * 6 = 126.
Le membre est en congé pendant 2 jours = 12 heures (cela varie pour chaque membre, certains peuvent prendre un congé et d'autres pas.)
Nombre d'heures réelles = 126 - 12 = 114 heures.

Cela signifie que le membre sera effectivement disponible pendant 114 heures pour ce sprint. Il décomposera donc sa tâche de sprint individuelle de manière à atteindre un total de 114 heures.

Étape # 5 : Le 5ede juin, toute l'équipe Scrum se réunit pour la «réunion de planification».

  • Le verdict final de la user story du backlog du produit est fait et l'histoire est déplacée vers le Sprint Backlog.
  • Pour chaque histoire, chaque membre de l'équipe déclare ses tâches identifiées, si nécessaire, il peut avoir une discussion sur ces tâches, peut la dimensionner ou la redimensionner (rappelez-vous la série Fibonacci !!).
  • Le Scrum master ou l'équipe saisissent leurs tâches individuelles ainsi que leurs heures pour chaque histoire dans un outil.
  • Une fois toutes les histoires terminées, Scrum master note la vélocité initiale et démarre formellement le sprint.

Étape # 6 : Une fois que le Sprint a commencé, en fonction des tâches assignées, chaque membre de l'équipe commence à travailler sur ces tâches.

Étape # 7 : L'équipe se réunit quotidiennement pendant 15 minutes et discute de 3 choses:

  • Qu'ont-ils fait hier?
  • Que prévoient-ils de faire aujourd'hui?
  • Des obstacles (barrages routiers)?

Étape # 8 : Le Scrum Master suit les progrès au quotidien à l'aide du «Burn down chart».

Étape # 9 : En cas d'obstacles, le Scrum master fait le suivi pour les résoudre.

Étape # 10 : Sur 4eEn juillet, l'équipe se réunit à nouveau pour la réunion d'examen. Un membre montre la user story implémentée au propriétaire du produit.

Étape # 11 : Sur 5eJuillet, l'équipe se réunit à nouveau pour la rétrospective, où ils discutent

  • Qu'est-ce qui s'est bien passé?
  • Qu'est-ce qui ne s'est pas bien passé?
  • Éléments d'action.

Étape # 12 : Sur 6eEn juillet, l'équipe se réunit à nouveau pour une réunion de pré-planification du prochain sprint et le cycle se poursuit.

Processus de méthodologie agile Scrum

Outils d'activité SCRUM

Il existe plusieurs outils qui peuvent être largement utilisés pour suivre les activités de mêlée.

Certains d'entre eux comprennent:

Dans le prochain tutoriel, nous éclairerions le Manifeste Agile, une notion qui motive des équipes Agile efficaces.

Tutoriel suivant

À propos des auteurs: Cette série est écrite par les membres suivants de l'équipe STH: Shruti Shrivastava - Un Scrum Master professionnel avec 9 ans d'expérience dans les domaines BFSI, E-commerce et B2B. Shruti est un expert des tests d'automatisation et dirige des équipes Scrum.

Anshul Kumar Srivastava - Un professionnel de la gestion de produits axé sur les résultats et un praticien Agile avec 7 ans d'expérience dans les secteurs de la BFSI et des télécommunications.

lecture recommandée

^