Méthode Agile – Explications pour Tout comprendre au SCRUM

Publié le par

Si votre entreprise vient d’adopter une méthode agile SCRUM, vous avez peut être besoin de vous former à cette méthodologie qui a succédé au bon vieux cycle en V. Pour vous, voici donc une rapide formation sur tout ce que vous devez savoir à la méthode agile SCRUM.

Introduction aux méthodes agiles

L’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 tutoriels est de faire entrer les professionnels de la technologie et les autres dans le monde agile.

Nous vous emmènerons à travers le voyage agile étape par étape jusqu’à ce que vous compreniez la philosophie derrière l’utilisation d’Agile, ses avantages et comment la pratiquer. Cette série a pour but d’équiper les lecteurs et de leur permettre d’appliquer l’apprentissage d’Agile et de Scrum dans leur travail.

Ce tutoriel particulier est dédié à vous expliquer pourquoi il y avait un besoin pour Agile et comment il a été créé. L’objectif fondamental est de vous faire comprendre le concept d’adoption d’Agile dans les industries du développement logiciel.

Histoire des méthodes agiles

Les méthodes agiles sont nées lorsqu’un beau jour, 17 personnes ayant des antécédents différents en matière de méthodologies de développement se sont réunies pour réfléchir à l’existence d’une solution alternative au développement de logiciels qui pourrait conduire à un temps de développement plus rapide et à une documentation moins lourde.

À l’époque, le développement de logiciels était si long qu’au moment où les projets étaient prêts à être livrés, l’entreprise avait évolué 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 capable d’atteindre les objectifs définis.

Ainsi, ces champions de différentes techniques de génie logiciel se sont réunis et le résultat final de leur réunion a été ce qu’ils ont appelé le « manifeste agile » que nous allons discuter en détail dans le prochain tutoriel de cette série.

Mais l’agile qui est né ce jour-là n’est pas ce que nous voyons aujourd’hui dans les organisations. La méthodologie sur laquelle ces experts se sont mis d’accord a été décrite comme « légère » et rapide. Mais la principale victoire de cette réunion a été l’idée que la 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 en cascade existantes étaient trop lourdes et ne prévoyaient pas de retour d’information avant que le produit final ne soit prêt à être livré. Cela signifiait qu’il n’y avait pas de marge de manœuvre pour corriger le tir et que le client n’avait pas de vue sur l’avancement du projet avant que le produit entier ne soit prêt. Et c’est ce que ces experts voulaient éviter.

Ils voulaient une solution qui permette un retour d’information constant afin d’éviter le coût d’un remaniement ultérieur.

Les défis de l’agilité et du SCRUM

Les techniques en cascade existantes à l’époque étaient trop lourdes et ne prévoyaient pas de retour d’information jusqu’à ce que le produit final soit prêt à être livré. On appelait ce modèle de développement « en cascade » parce que les équipes terminaient d’abord complètement une étape et ne passaient qu’ensuite à l’étape suivante.

Cela signifiait qu’il n’y avait pas de possibilité de correction de trajectoire et que le client n’avait aucune vue sur l’avancement des travaux avant que le produit complet ne soit prêt. Et c’est ce que ces experts voulaient éviter. Ils voulaient une solution qui permette un retour d’information constant afin d’éviter le coût d’un remaniement ultérieur.

C’est pourquoi la méthode agile est aussi une question d’adaptation et d’amélioration continue, tout autant que de retour d’information constant et de rapidité de livraison.

Que sont les promesses des méthodes agiles ?

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

Les valeurs et les principes agiles permettent à l’équipe de se concentrer et de changer son processus de pensée pour créer de meilleurs logiciels.

Qu’est-ce que l’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. Il s’agit plutôt d’un ensemble de principes qui encouragent la flexibilité, l’adaptabilité, la communication et le travail sur des logiciels plutôt que sur des plans et des processus. Ce principe est résumé de manière très succincte dans ce que l’on appelle le manifeste agile.

Le développement logiciel agile permet à l’équipe de travailler ensemble de manière plus efficace et plus efficiente dans le cadre de projets complexes. Il consiste en des pratiques qui font appel à des techniques itératives et incrémentielles, facilement adoptées et qui donnent d’excellents résultats.

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

En outre, les méthodes et méthodologies agiles ouvrent également la voie à l’amélioration des processus, qui fait partie intégrante de chaque livraison.

L’agilité est une approche du développement logiciel dans laquelle une équipe autonome et interfonctionnelle travaille à la réalisation de livraisons continues par itérations et évolue tout au long du processus en recueillant les commentaires des utilisateurs finaux.

Comment pratiquer l’Agilité ?

Il existe plusieurs méthodologies Agile qui sont en pratique dans des industries diverses et variées. Cependant, les méthodologies les plus populaires parmi toutes sont :

  • Scrum
  • Kanban
  • la programmation extrême.

Toutes ces méthodologies sont axées 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 à la méthode Agile. Cette partie est structurée pour vous aider à comprendre les valeurs et les principes fondamentaux qui doivent être adoptés pour qu’une équipe travaille dans un mode et un état d’esprit agiles.

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

Nous avons également appris les valeurs et les principes qui ont été mentionnés dans le manifeste agile par les fondateurs d’agile. Dans nos discussions initiales, nous avons également abordé les différences entre la méthode agile et les modèles traditionnels en cascade.

Dans ce tutoriel, nous allons découvrir les avantages et les inconvénients de la méthodologie agile.

Nous verrons ce qu’est scrum et en quoi elle est différente d’agile. Ensuite, nous comprendrons les différentes méthodologies agiles qui sont utilisées par différentes organisations et comment nous pouvons mettre en œuvre la méthode agile en les utilisant.

Vous serez également en mesure d’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 continuellement 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, conformément à la définition de « fait » qu’il a donnée.
  • Les équipes de développement sont très réactives à l’évolution des besoins et peuvent s’adapter aux changements, même à un stade avancé du développement.
  • Une communication bidirectionnelle constante permet de maintenir l’implication des clients.
  • 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.

Ce sont les suivants

  • Une documentation complète n’est pas privilégiée, ce qui peut conduire les équipes agiles à interpréter de manière incorrecte que la méthode agile ne nécessite pas de documentation. Ainsi, la rigueur se perd dans la documentation. Ceci devrait être évité en vous demandant continuellement si cette information est suffisante pour continuer ou non.
  • Parfois, au début des projets, les exigences ne sont pas très claires. Les équipes peuvent procéder et découvrir que la vision des clients a été réorientée et dans de telles situations, les équipes doivent incorporer 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 dans le monde. Nous allons découvrir en détail quatre des plus populaires d’entre elles.

#1) Scrum

Scrum peut facilement être considéré comme le cadre agile le plus populaire. Le terme « Scrum » est souvent considéré comme synonyme de « agile » par la plupart des praticiens. Mais il s’agit d’une idée fausse. Scrum n’est que l’un des cadres permettant de mettre en œuvre la méthode agile.

Le mot « mêlée » vient du rugby sportif. Les joueurs se serrent les uns contre les autres pour pousser leurs 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 la même manière, la mêlée dans l’informatique croit en des équipes de développement autonomes et autogérées avec trois rôles spécifiques et clairement définis. Ces rôles sont les suivants : le propriétaire du produit (PO), le Scrum Master (SM) et l’équipe de développement composée de programmeurs et de testeurs. Ils travaillent ensemble par tranches de temps itératives appelées sprints.

La première étape est la création du backlog du produit par le PO. Il s’agit d’une liste de choses à faire par l’équipe de mêlée. Ensuite, l’équipe sélectionne les éléments les plus prioritaires et essaie de les terminer dans le cadre d’une période appelée « sprint ».

Une façon plus facile de se souvenir de tout cela est de mémoriser le cadre 3-3-5. Cela signifie qu’un projet scrum comporte 3 rôles, 3 artefacts et 5 événements.

Il s’agit de

  • Rôles : PO, Scrum master, et équipe de développement.
  • Les artefacts : Backlog de produit, backlog de sprint et incrément de produit.
  • Événements : Sprint, planification du Sprint, Scrum quotidien, revue du Sprint et rétrospective du Sprint.
  • Cadre 3-3-5

#2) Kanban

Kanban est un terme japonais qui signifie une carte. Ces cartes contiennent les détails du travail à effectuer sur le logiciel. L’objectif 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 la livraison continue. Tout comme Scrum, Kanban a également pour but d’aider les équipes à travailler efficacement et de promouvoir les équipes autogérées et collaboratives.

Mais il existe également des différences entre les deux. Par exemple, au cours d’un sprint Scrum, les éléments sur lesquels travaille une équipe sont fixes et nous ne pouvons pas ajouter d’éléments au sprint, alors que dans Kanban, nous pouvons ajouter des éléments si la capacité est disponible. Cela 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’existe pas de tels rôles prédéfinis dans Kanban.

Une autre différence est qu’alors que la mêlée suggère une hiérarchisation des backlogs de produits, Kanban n’a pas cette exigence et est totalement facultatif. Kanban nécessite donc moins d’organisation et évite les activités sans valeur ajoutée. Il convient aux processus qui exigent une certaine réactivité face aux changements.

#3) Lean

Le Lean est une philosophie qui se concentre sur la réduction des déchets. Comment s’y prend-elle ?

Dans le cadre du Lean, vous divisez un processus en activités à valeur ajoutée, en activités sans valeur ajoutée et en 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 devons essayer d’éliminer ce gaspillage dans le processus pour l’alléger.

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

Le développement logiciel allégé peut être utilisé dans n’importe quel projet informatique en appliquant les sept principes allégés présentés ci-dessous :

Sept principes lean

Comme leur nom l’indique, ces principes sont assez explicites. L’élimination des gaspillages est le premier et le plus important de ces principes et nous avons vu comment le faire, en classant les activités en activités à valeur ajoutée 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 une valeur commerciale justifiable. Il peut également s’agir de récits d’utilisateurs vagues, de tests médiocres ou de l’ajout de fonctionnalités qui ne sont pas nécessaires dans le contexte général.

Le deuxième principe, celui de l’amplification de l’apprentissage, est lui aussi facile à comprendre, car une équipe a besoin de diverses compétences pour livrer des produits dans un environnement qui évolue rapidement et où de nouvelles technologies apparaissent à intervalles rapprochés.

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

Mais il y a toujours un compromis à faire, car les équipes doivent trouver un équilibre avec le quatrième principe qui consiste à livrer plus rapidement. Le fait de retarder les décisions ne doit pas avoir d’impact sur la livraison globale et ne doit pas réduire le rythme de travail. Il faut toujours avoir un œil sur l’ensemble du tableau.

L’autonomisation des équipes est également très courante de nos jours, et c’est une chose que même Agile suggère. Les équipes responsabilisées sont plus responsables et peuvent prendre des décisions plus rapidement. Le sentiment d’appartenance d’une équipe responsabilisée conduit à de meilleurs résultats. Pour responsabiliser une équipe, il faut lui permettre de s’organiser et de prendre des décisions par elle-même.

Ainsi, nous constatons que les méthodes allégées et agiles ont beaucoup en commun, à une différence près : si les équipes allégées 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 des techniques agiles les plus populaires. 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 façons différentes – communication, simplicité, feedback, respect et courage. Ce sont les valeurs de XP.

Parmi celles-ci, tout commence par la communication. Les équipes XP collaborent régulièrement avec les équipes commerciales et les autres programmeurs et commencent à créer du code dès le premier jour. L’accent est mis ici sur la communication en face à face, autant que possible avec l’aide d’autres supports visuels.

Les programmeurs extrêmes construisent également un code simple et commencent à obtenir un retour sur celui-ci dès le premier jour. L’accent est mis sur le fait de ne pas aller trop loin ou de ne pas prévoir des exigences qui n’ont pas été partagées. Cela permet de garder une conception simple et de ne produire que le produit minimum qui répondra aux exigences.

Le retour d’information aide l’équipe à s’améliorer et à produire un travail de meilleure qualité. Il les aide à se respecter mutuellement car ils apprennent les uns des autres et à partager leurs points de vue.

Cela leur donne également du courage, car ils savent qu’ils ont rassemblé les meilleures idées de chacun et qu’ils ont réalisé un bon produit grâce aux commentaires des autres. Ils n’ont donc pas peur d’inclure des changements ou de recevoir d’autres commentaires sur leur travail.

Cela est particulièrement utile dans les projets où les exigences changent souvent. Un feedback constant aidera les équipes à inclure 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 les plus subtiles entre elles. Nous avons également appris les principes fondamentaux de chacune de ces méthodologies et vu comment les appliquer à nos projets en fonction des besoins.

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

Méthodologie Scrum

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

L’un des principaux handicaps du modèle traditionnel Waterfall était que – tant que la première phase n’était pas terminée, l’application ne passait pas à l’autre phase. Et par hasard, s’il y a des changements dans la dernière phase du cycle, alors il devient très difficile de mettre en œuvre ces changements, car cela impliquerait de revenir sur les phases précédentes et de refaire les changements.

Voici quelques-unes des principales caractéristiques de SCRUM :

  • Une équipe auto-organisée et concentrée.
  • Pas d’énormes documents d’exigences, mais plutôt des histoires très précises et directes.
  • Les équipes interfonctionnelles travaillent ensemble comme une seule unité.
  • Une communication étroite avec le représentant des utilisateurs pour comprendre les fonctionnalités.
  • Un délai précis d’un mois maximum.
  • 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.

Définitions importantes en SCRUM

1) Équipe Scrum

L’équipe Scrum est une équipe composée 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 chargées de la base de données, des personnes chargées du 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écurrent et défini, pour développer et mettre en œuvre lesdites fonctionnalités. La disposition des sièges de l’équipe SCRUM joue un rôle très important dans leur interaction, ils ne sont jamais assis dans des cubicules ou des cabines, mais sur une immense table.

2) Sprint

Le sprint est un intervalle ou une période de temps prédéfinie au cours de laquelle le travail doit être achevé et rendu prêt pour la révision ou le déploiement de la production. Ce laps de temps se situe généralement entre 2 semaines et 1 mois.

Dans notre vie quotidienne, lorsque 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 rendons prêtes pour la révision à la fin de ce mois.

3) Product Owner

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 et a besoin d’une clarification. 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

Le Scrum Master est le facilitateur de l’équipe de mêlée. Il s’assure que l’équipe de mêlée est productive et progressive. En cas d’obstacles, le Scrum Master assure le suivi et la résolution des problèmes de l’équipe. Le 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, il en discute avec le PO et les résout. Comme le standup quotidien de l’équipe, un standup du SCRUM Master avec le PO a lieu chaque jour.

Lecture recommandée => Comment être un bon mentor d’équipe, un coach et un véritable défenseur de l’équipe dans un monde de tests agiles ?

5) Business Analyst (BA)

Un analyste commercial joue un rôle très important dans SCRUM. Cette personne est responsable de la finalisation des exigences et de leur rédaction dans les documents d’exigences (sur la base desquels les histoires d’utilisateur sont créées).

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

C’est toujours une bonne pratique d’avoir un BA lorsque le projet démarre.

6) User Story

Les user stories ne sont rien d’autre que les exigences ou les caractéristiques qui doivent être mises en œuvre.

Dans la mêlée, nous n’avons pas ces énormes documents d’exigences, plutôt les exigences sont définies dans un seul paragraphe, ayant généralement le format suivant :

En tant qu’ <Utilisateur / type d’utilisateur>
Je veux <un objectif/une cible réalisable>
Pour atteindre <un résultat ou une raison de faire la chose>.

Par exemple :

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

Il existe certaines caractéristiques des user stories qui doivent être respectées.

Les user stories doivent être courtes, réalistes, estimables, complètes, négociables et testables. Une user story n’est jamais modifiée ou changé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 correctement rédigé les user stories avec un ensemble approprié de critères d’acceptation ». Si des changements qui auront un impact sur le lancement du sprint doivent être effectués, ces histoires sont retirées du sprint ou sont réalisées en fonction des 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 aident à affiner la user story. N’importe quel membre de l’équipe peut rédiger les critères d’acceptation. L’équipe de test fonde ses cas/conditions de test sur ces critères d’acceptation.

7) Épopées / Epic

Les épopées sont des user stories équivoques ou nous pouvons dire que ce sont les user stories qui ne sont pas définies et qui sont gardées pour les prochains sprints.

Essayez de faire le lien avec la vie, imaginez que vous partez en vacances. Comme vous partez la semaine prochaine, vous avez tout mis en place, comme les réservations d’hôtel, les visites touristiques, le contrôle des voyageurs, etc. Mais qu’en est-il de votre plan de vacances pour l’année prochaine ? Mais qu’en est-il de votre plan de vacances pour l’année prochaine ? Vous n’avez qu’une vague idée d’aller à l’endroit XYZ, mais vous n’avez pas de plan détaillé.

Un Epic est exactement comme votre plan de vacances de l’année prochaine, où vous savez juste que vous voulez y aller, mais où, quand, avec qui, tous ces détails que vous n’avez aucune idée à ce moment-là.

De la même manière, il existe des fonctionnalités qui doivent être mises en œuvre à l’avenir et dont les détails ne sont pas encore connus. La plupart du temps, une fonctionnalité commence par un Epic, puis est décomposée en histoires qui pourraient être mises en œuvre.

8) Product Backlog

Le backlog du produit est une sorte de seau ou de source où sont conservées toutes les histoires des utilisateurs. Il 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 hiérarchise en fonction des besoins de l’entreprise.

Au cours de la réunion de planification (voir section suivante), une user story est prise dans le backlog de produit, puis l’équipe fait un brainstorming, la comprend et l’affine et décide collectivement des user stories à prendre, avec l’intervention du propriétaire du produit.

9) Backlog de sprint

En fonction de la priorité, les user stories sont prises dans le Product Backlog, une par une. L’équipe Scrum y réfléchit, détermine la faisabilité et décide des histoires à traiter dans un sprint particulier. La liste collective de toutes les user stories sur lesquelles l’équipe Scrum travaille pendant un sprint particulier est connue sous le nom de Sprint Backlog.

10) Story Points

Les story points sont une indication quantitative de la complexité d’une user story. L’estimation et les efforts à fournir pour une histoire sont déterminés en fonction de ce point.

Un story point est relatif et non absolu. Afin de s’assurer que notre estimation et nos efforts sont corrects, il est important de vérifier que les user stories ne sont pas trop grandes. Plus l’user story est précise et petite, plus l’estimation sera précise.

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

Pour être précis

Si vous donnez 1 / 2 / 3 points d’histoire, cela signifie que l’histoire est petite et peu complexe.
Si vous donnez des points comme 5 / 8, c’est une histoire moyennement complexe et
13 et 21 sont très complexes.
Ici, la complexité consiste en un effort de développement et de test.

Pour décider d’un story point, un brainstorming a lieu au sein de l’équipe scrum et l’équipe décide collectivement d’un story point.

Il peut arriver que l’équipe de développement donne un story point de 3 à une histoire particulière, parce que pour elle, il s’agit d’un changement de 3 lignes de code, mais l’équipe de test donne un story point de 8 parce qu’elle estime que ce changement de code affectera des modules plus importants et que l’effort de test sera donc plus important. Quel que soit le story point que vous donnez, vous devez le justifier.

Dans cette situation, un brainstorming a lieu et l’équipe convient collectivement d’un story point.

Lorsque vous décidez d’un story point, gardez les facteurs suivants à l’esprit :

  • La dépendance de l’histoire avec une autre application/module.
  • L’ensemble des compétences de la ressource.
  • La complexité de l’histoire.
  • L’apprentissage historique.
  • Les critères d’acceptation de l’user story.
  • Si vous n’êtes pas au courant d’une histoire particulière, ne la dimensionnez pas.

Lorsqu’une story est = ou > 8 points, elle est décomposée en 2 ou plusieurs user stories.

11) Burn down chart

Le Burn down chartn est un graphique qui montre l’effort estimé par rapport à l’effort réel des tâches de Scrum.

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

12) Vélocité

Le nombre total de story point qu’une équipe de 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 story points, mais d’avoir un livrable de qualité, en respectant le niveau de confort de l’équipe Scrum.

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

Vélocité de Scrum
Donc ici la vélocité sera la somme des story points = 30

Définition de Done :

Un sprint est considéré comme terminé lorsque toutes les histoires sont achevées, que toutes les tâches de développement, de recherche et d’assurance qualité sont marquées « Terminé », que tous les bogues sont corrigés et fermés, que ceux qui peuvent être faits plus tard (comme ceux qui ne sont pas complètement liés ou qui sont moins importants) sont retirés et ajoutés au backlog, que la révision du code et les tests unitaires sont terminés, que le nombre d’heures estimées correspond au nombre d’heures réelles consacrées aux tâches et, surtout, qu’une démonstration réussie a été faite au PO et aux parties prenantes.

Activités réalisées dans le cadre de la méthodologie SCRUM

#1) Planning Meeting

La réunion de planification est le point de départ du sprint. C’est la réunion où toute l’équipe se rassemble, où le SCRUM Master sélectionne une user story en fonction de la priorité du backlog de produit et où l’équipe réfléchit à cette histoire.

Sur la base de la discussion, l’équipe décide de la complexité de l’histoire et la dimensionne selon la série de Fibonacci. L’équipe identifie les tâches ainsi que les efforts (en heures) à fournir pour achever la mise en œuvre de l’user story.

Souvent, la réunion de planification est précédée d’une « réunion de préplanification ». Il s’agit d’une sorte de devoir que l’équipe de scrum fait avant de se rendre à la réunion de planification formelle. L’équipe essaie d’écrire les dépendances ou d’autres facteurs qu’elle aimerait discuter lors de la réunion de planification.

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

Comme son nom l’indique, il s’agit du travail réel effectué par l’équipe pour accomplir sa tâche et faire passer l’histoire de l’utilisateur à l’état « Done ».

#3) Standup Daily

Pendant le cycle de sprint, l’équipe se réunit chaque jour pendant 15 minutes au maximum (il peut s’agir d’un stand-up call, recommandé en début de journée) et aborde 3 points :

  • Qu’a fait le membre de l’équipe hier ?
  • Qu’est-ce que le membre de l’équipe a prévu de faire aujourd’hui ?
  • Des obstacles (roadblocks) ?

C’est le Scrum Master qui anime cette réunion. Si un membre de l’équipe est confronté à une difficulté quelconque, le Scrum Master assure le suivi pour la résoudre. Lors de ces réunions, le tableau est également passé en revue, ce qui montre en soi les progrès de l’équipe.

#4) La rétro

À la fin de chaque cycle de sprint, l’équipe SCRUM se réunit à nouveau et présente les histoires d’utilisateur mises en œuvre au propriétaire du produit. Le propriétaire du produit peut vérifier les histoires en fonction de ses critères d’acceptation. C’est encore la responsabilité du Scrum Master de présider cette réunion.

Toujours dans l’outil SCRUM, le sprint est clôturé et les tâches sont marquées comme accomplies.

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é pendant le Sprint ?
  • Les leçons apprises
  • Actions à entreprendre.

L’équipe Scrum doit continuer à suivre les meilleures pratiques, ignorer les « non meilleures pratiques » et mettre en œuvre les leçons apprises au cours des sprints suivants. La réunion de rétrospective aide à mettre en œuvre l’amélioration continue du processus SCRUM.

Comment se déroule le processus ? Un exemple !
Après avoir lu le jargon technique de SCRUM, laissez-moi essayer de démontrer le processus entier avec un exemple.

Exemple :

  • Etape 1 : Nous avons une équipe SCRUM de 9 personnes comprenant 1 propriétaire du produit, 1 Scrum Master, 2 testeurs, 4 développeurs et 1 DBA.
  • Étape 2 : Le Sprint est décidé pour suivre un cycle de 4 semaines. Nous avons donc un sprint d’un mois, du 5 juin au 4 juillet.
  • Étape 3 : Le Product Owner dispose de la liste des user stories classées par ordre de priorité dans le backlog du produit.
  • Étape 4 : L’équipe décide de se réunir le 4 juin pour la réunion de « préplanification ».

Le propriétaire du produit prend une histoire dans le backlog de produit, la décrit et laisse à l’équipe le soin d’y réfléchir.
L’ensemble de l’équipe discute et communique directement au propriétaire du produit pour avoir bien compris l’histoire de l’utilisateur.
De la même manière, plusieurs autres user stories sont prises. Si possible, l’équipe peut aller de l’avant et dimensionner les histoires également.
Après toute la discussion, les membres de l’équipe individuelle retournent à leur poste de travail et identifient leurs tâches individuelles pour chaque histoire.

Quels outils utilise t-on en SCRUM ?

Il existe plusieurs outils qui peuvent être utilisés de manière extensive pour le suivi des activités de scrum.

En voici quelques-uns :

  • Jira
  • XPlanner
  • VersionOne
  • Sprintometer
  • ScrumNinja