Méthode agile Scrum, guide complet pour tout savoir

Vous avez surement déjà entendu parler du framework agile Scrum. Scrum est devenu un framework incontournable dans le monde agile. La méthode est essentielle pour tous ceux qui travaillent dans le domaine de la gestion de projet ou du développement de produits. Voyons de quoi il s’agit !

Que sont les méthodes agiles ?

Différentes techniques ont progressivement émergé pour mettre en pratique les valeurs et principes plutôt abstraits du manifeste. Il s’agit par exemple des « task boards », des « daily standup meetings » et des « user stories », pour n’en citer que quelques-unes. C’est à partir de ces principes que se sont développées les méthodes dites agiles. Depuis de nombreuses années déjà, ces méthodes font progressivement leur entrée dans le développement de logiciels, notamment sous les termes « processus unifié », « programmation extrême » et « Scrum ».

Aujourd’hui, les concepts agiles sont tout naturellement appliqués à des projets autres que le développement de logiciels – ce qui, dans la plupart des cas, est faisable, même si ce n’est pas toujours très facile.

Pourquoi utiliser les méthodes agiles ?

La gestion de projet agile est une réponse à la vitesse croissante à laquelle les projets doivent être menés et à la constatation que dans de nombreux projets, les écarts par rapport au plan sont la règle plutôt que l’exception. Ce dernier point est particulièrement vrai lorsque les exigences relatives au produit (le résultat du projet) ne sont pas totalement claires au début du projet. Dans la gestion de projet traditionnelle, une modification des exigences entraîne presque inévitablement une augmentation des coûts ou une prolongation de la durée du projet. Dans la gestion de projet agile, ces changements sont acceptés dès le départ. Cela permet de limiter les coûts et de respecter le calendrier.

Les valeurs qui découlent du Manifeste Agile sont :

Ouverture,
Courage,
Focus,
Respect,
Commitment ou Engagement personnel.

Qu’est-ce que Scrum ?

Scrum est basé sur les valeurs et les principes agiles. Il est donc parfaitement adapté aux problèmes complexes. Le développement de produits décrit le domaine d’application de Scrum, qui comprend le développement de nouveaux produits et solutions.

Scrum est donc un cadre ou une structure qui m’aide lorsque je suis confronté au défi de développer un produit ou une solution dans un environnement complexe.

Scrum doit être considéré comme un cadre léger. Dans ce contexte, « léger » signifie qu’il fournit un cadre général tout en laissant une grande marge de manœuvre.

Origine de Scrum

Scrum est né dans le développement de logiciels, car c’est là que la rapidité et donc la complexité se font le plus rapidement sentir. Aujourd’hui, Scrum s’est toutefois introduit dans presque tous les domaines du développement de produits.

Scrum se base sur cinq principes essentiels : itération courte, auto-organisation, inspection et adaptation, livraison régulière et transparence.

Itération courte

En raison de la forte dynamique de l’environnement, il est important que les entreprises aient toujours la possibilité de réagir aux changements sur le chemin du produit. Les itérations courtes aident à s’adapter en permanence aux conditions changeantes.auto-organisation : auto-organisation ou équipes auto-organisées. Pour que les itérations courtes soient non seulement possibles, mais aussi utilisées au mieux, il faut une équipe qui soit organisée de manière à pouvoir s’auto-organiser. Au niveau de l’équipe, l’auto-organisation signifie qu’il existe certes des exigences techniques, mais que la mise en œuvre technique est laissée à la liberté de l’équipe, qui obtient ainsi plus de responsabilité et de marge de manœuvre.

Inspection et adaptation

Ce principe vise l’amélioration continue et l’apprentissage. Dans les projets classiques, nous connaissons généralement tout au plus un Lessons Learned à la fin du projet. Dans Scrum, en revanche, on vérifie après chaque unité de temps, inspect, ce qui s’est passé et où nous en sommes, et on en déduit des mesures pour l’adaptation et le changement correspondants, adapt.

Livraison régulière

Grâce à des livraisons régulières, l’équipe a l’occasion de recevoir un feed-back du client, ce qui fournit la base pour adapter toujours au mieux la direction du développement ; contrairement à de nombreuses approches classiques, où le client ne voit généralement sa solution qu’à la fin du développement et où il y a donc peu de place pour l’adaptation.

Transparence

La transparence est un point crucial pour que des cadres agiles comme Scrum puissent vraiment fonctionner. Chaque aspect important doit être transparent pour toutes les personnes impliquées dans Scrum. Cela inclut bien sûr aussi le client. Le client est totalement intégré dans le développement. Son feed-back ne peut être utile que si la transparence est réellement vécue. Voilà donc les cinq principes qui se cachent derrière Scrum.

Aperçu du framework Scrum

Le framework lui représente le cadre que constitue Scrum. Ce cadre se compose de trois éléments : Les événements, les rôles et les artefacts.

Les événements décrivent logiquement des rencontres régulières dans Scrum. Dans Scrum, il y a le Sprint Planning, le Daily Scrum, le Scrum Review et la Scrum Retrospective.
En outre, il existe trois rôles différents dans Scrum : le Scrum Master, le Product Owner et l’équipe de développement.
Et pour finir, deux artefacts : le Product Backlog et le Sprint Backlog. Nous vous expliquerons plus tard ce qu’il en est de ces événements, rôles et faits.

Éléments de SCRUM

Dans ce schéma, nous avons une vue d’ensemble de tous les éléments. Scrum travaille avec des événements, des rôles et des artefacts. Commençons par les rôles du Product Owner, du Scrum Master et de l’équipe de développement.

Le Product Owner

Dans Scrum, le Product Owner met en lumière, si l’on peut dire, l’aspect commercial du produit. Il est responsable de la maximisation de la valeur du produit dans le sens de la vision du produit et de l’utilité pour le client. Le Product Owner se concentre essentiellement sur un aspect précis, la valeur commerciale derrière le produit. En tant que propriétaire du produit, il est en quelque sorte le propriétaire du produit, ce qui signifie qu’il détermine les exigences qui ont le plus de valeur pour le client. Son travail consiste donc à formuler de nouvelles exigences et à les hiérarchiser en fonction de la valeur commerciale. Le Product Owner est donc toujours la seule personne responsable des exigences techniques.

Comme son nom l’indique, le Product Owner est propriétaire du produit, ce qui signifie qu’il porte l’entière responsabilité de la valeur émergente ou valeur commerciale derrière le produit. Dans Scrum, cela débouche précisément sur ce rôle, ce qui signifie également qu’il constitue l’interface entre l’équipe Scrum et toutes les autres parties prenantes. Il en résulte déjà une de ses tâches principales, la gestion des parties prenantes.

En tant que représentant de l’utilisateur futur du produit, il doit toujours peser le pour et le contre des différents intérêts et options des parties prenantes potentielles et décider de ce qui est le mieux dans l’esprit de la valeur commerciale. C’est aussi pour cette raison que le Product Owner est souvent appelé Value Maximizer.

Le Product Owner doit accomplir un certain nombre de tâches. Voyons ici les plus importantes :

L’identification et la hiérarchisation des exigences du produit : Il s’agit certainement de la tâche principale du Product Owner. Il se pose toujours la question suivante : avec quelles exigences puis-je augmenter le plus la valeur du produit pour le client ? Outre l’identification de ces exigences, la priorisation est certainement l’une des tâches les plus difficiles, car il n’est généralement pas possible de tout mettre en œuvre dans le sens de la focalisation et prioriser signifie souvent aussi dire non aux exigences.
Description des critères d’acceptation des exigences du produit : Ce n’est pas seulement l’identification des exigences qui est essentielle, mais aussi la description du moment où une exigence est prête. Les critères d’acceptation aident à décrire quand une exigence est prête ou non. Décider quand un produit ou un incrément sera livré : Au cours du processus de développement, la question de savoir quand le produit sera livré se pose régulièrement. Le Product Owner doit toujours trouver un équilibre entre une livraison précoce et une itération supplémentaire, ce qui lui donne la possibilité de continuer à développer le produit. Il accepte les exigences mises en œuvre. Au cours d’un sprint, l’équipe met en œuvre les exigences, mais à la fin du sprint, il incombe au Product Owner d’accepter les exigences mises en œuvre et donc de les adopter.
Répondre aux questions et aux incertitudes concernant les exigences : même si les exigences doivent être décrites de manière à être claires et compréhensibles, il peut toujours arriver que l’équipe ait des questions. Le Product Owner est responsable de ces questions et il est aidé en cela par sa disponibilité permanente et, le cas échéant, par sa présence auprès de l’équipe de développement.
Gestion des parties prenantes : comme décrit précédemment, c’est l’une des tâches principales du Product Owner.
Collaboration avec le Scrum Master : outre l’équipe de développement et les parties prenantes, le travail avec le Scrum Master fait également partie du quotidien du Product Owner. Le Scrum Master doit résoudre de nombreux obstacles en collaboration avec le Product Owner et, en tant qu’expert du processus Scrum, le Scrum Master soutient également le Product Owner dans son travail. Un échange harmonieux entre les deux rôles est une condition impérative pour un projet réussi.

L’équipe de développement

L’équipe de développement est responsable de la mise en œuvre des exigences fonctionnelles ; elle agit toujours par délégation de pouvoir et de manière autonome, ce qui exige toutefois qu’elle soit organisée de manière à posséder toutes les compétences nécessaires pour pouvoir mettre en œuvre de manière autonome les exigences fonctionnelles du Product Owner.

L’équipe de développement est autonome et responsable de la mise en œuvre des exigences posées par le Product Owner. Il s’agit d’une équipe interfonctionnelle, ce qui signifie qu’elle dispose de toutes les compétences nécessaires pour la mise en œuvre. Elle se caractérise non seulement par un degré élevé d’auto-organisation, mais aussi par un fort engagement et une grande motivation intrinsèque. Ce passage contenait déjà un mot important, qui est tout à fait décisif si l’on considère l’équipe de développement. Dans le cas d’une équipe cross-fonctionnelle, il ne s’agit pas d’avoir des compositions selon une spécialité particulière, comme par exemple une équipe de marketing ou une équipe de designers, mais une équipe interdisciplinaire.

Le guide Scrum décrit également que toutes les compétences doivent être présentes dans l’équipe de développement afin de pouvoir développer le produit de manière fonctionnelle. Pour la composition, cela signifie qu’au lieu de rassembler plusieurs personnes d’une même spécialité, il faut se concentrer sur le produit et sa vision et se poser la question suivante : De quelles compétences ai-je besoin pour cela ? L’avantage d’une équipe interfonctionnelle est évident. Si toutes les compétences sont présentes dans l’équipe, celle-ci peut créer un produit entièrement fonctionnel sans dépendance externe. Si une équipe de développement est constituée de cette manière, elle est également en mesure d’agir de manière auto-organisée. Elle peut prendre des décisions sur les exigences à mettre en œuvre et sur l’expertise la plus utile à ce moment-là. Plus une équipe est hétérogène, plus sa marge de manœuvre est grande et plus son engagement sera important. Si l’équipe peut travailler sans dépendance externe, elle est en mesure d’atteindre elle-même les objectifs qu’elle s’est fixés. Cela augmente visiblement l’appropriation et donc l’engagement.

Le Scrum Master

Le Scrum Master, en tant que troisième rôle, est chargé de créer un cadre dans lequel l’équipe de développement et le Product Owner peuvent travailler bien et efficacement. Cela implique que le Scrum Master accompagne tout un processus de changement dans l’entreprise et qu’il agisse en outre comme coach pour l’équipe. Les qualités que doit posséder le Scrum Master sont multiples. Outre l’expertise du framework Srum, des aspects tels que l’empathie, la capacité à s’imposer, le talent de communication et les compétences de modération jouent un rôle essentiel.

Comparé à de nombreuses méthodes classiques de gestion de projet, le Scrum Master est certainement l’une des plus grandes nouveautés du point de vue des rôles, et l’une des plus complexes dans son expression. On distingue essentiellement cinq facettes pour le rôle du Scrum Master :

expert : En tant qu’expert, le Scrum Master doit impérativement être au courant de l’évolution de Scrum et de l’agilité en général. Le framework en lui-même ne cesse d’évoluer et il s’agit ici d’être toujours à jour dans les développements. Cette expertise signifie également que tout le monde regarde comment le Scrum Master s’organise lui-même. Il doit être conscient de cette fonction d’exemple à tout moment et il peut également l’utiliser pour promouvoir l’introduction de Scrum en général. D’une part, cela présente l’avantage qu’il peut montrer l’exemple du processus Scrum tel qu’il veut l’enseigner à l’équipe, mais d’autre part, si des erreurs sont commises, un comportement indésirable peut être facilement encouragé. Dans tous les cas, le Scrum Master est le rôle qui possède les connaissances et l’expérience nécessaires sur le framework.
agent de changement : L’introduction de Scrum implique souvent des changements profonds au sein de l’organisation. C’est pourquoi le Scrum Master, dans son rôle d’agent du changement, doit connaître les résistances typiques que ce processus de changement implique et être en mesure de les contrer activement.
facilitateur : Il est responsable de l’élimination des problèmes et des obstacles qui empêchent l’équipe de travailler de manière auto-organisée.
gardien du processus : Le fait que Scrum ne soit pas une méthode de processus avec beaucoup de règles ne signifie pas qu’il n’y en a pas du tout. Le cadre défini par Scrum constitue la structure de base pour une conception active, il est donc crucial de le respecter. Le Scrum Master doit notamment veiller à ce que les événements, les plannings, les revues et les rétrospectives se déroulent dans un but précis. Tout l’art consiste à s’assurer que tout le monde respecte le processus, tout en donnant aux collaborateurs le sentiment qu’ils ne sont pas forcés de suivre le processus.
coach agile : Dans son rôle de coach, il s’agit de faire évoluer activement l’ensemble de l’équipe Scrum. Selon le degré de maturité de l’équipe, le Scrum Master doit aider l’équipe à assimiler la pensée agile et non seulement à comprendre la mêlée, mais aussi à intégrer les principes dans le travail quotidien. Surtout dans la phase initiale exigeante d’une introduction Scrum, il accompagne l’équipe, initie et anime des ateliers et des événements et mène des entretiens. Il utilise son expérience du framework et de l’agilité ainsi que son acceptation au sein de l’équipe et de l’organisation pour aider ses collègues à développer de nouveaux modèles et à ne pas retomber dans les vieilles habitudes. Selon le degré de maturité de l’équipe, le Scrum Master doit d’abord aider l’équipe à assimiler la pensée agile et à intégrer les principes dans le travail quotidien.

Dans l’esprit d’un leader serviteur, Ceux-ci peuvent être liés à des conditions générales tout à fait banales, comme une lampe défectueuse, ou à des conflits de dirigeants. Le Scrum Master dans son rôle de gardien du processus.Scrum ne réussira pas si l’organisation n’adopte pas l’état d’esprit agile. Le Scrum Master, en tant que facilitateur, se charge de cette tâche. Il sait quand il doit donner des impulsions et quelles pourraient être ces impulsions. Il peut s’agir d’une réunion de l’ensemble de l’équipe Scrum, d’une discussion avec les parties prenantes ou simplement d’une conversation téléphonique avec le Product Owner — en tant que facilitateur, il sait toujours ce qui est nécessaire, son rôle va donc bien au-delà de la simple réaction aux phénomènes concomitants du changement. Le Scrum Master doit lui-même être le moteur de l’introduction de Scrum. Le Scrum Master en tant que coach (agile).

Les événements dans Scrum

Regardons maintenant les événements dans Scrum. Ce sont : le sprint, la planification du sprint, la mêlée quotidienne, la revue du sprint et la rétrospective du sprint. Le sprint est le cœur de Scrum. Le sprint dure une semaine à un mois et décrit les itérations au cours desquelles les exigences techniques sont mises en œuvre. Le Sprint Planning est l’événement qui se déroule au début de chaque sprint et qui permet de déterminer quelles exigences seront mises en œuvre au cours du prochain sprint.

Le Daily Scrum

Le Daily Scrum a lieu tous les jours avec un timebox de 15 minutes et sert à la concertation et à la synchronisation de l’équipe. On y répond toujours à trois questions :

Qu’est-ce que j’ai réalisé hier qui aidera l’équipe de développement à atteindre l’objectif du sprint ?
Qu’est-ce que je vais faire aujourd’hui pour aider l’équipe de développement à atteindre l’objectif du sprint ?
Est-ce que je vois des obstacles, des impediments, qui m’empêchent ou qui empêchent l’équipe de développement d’atteindre l’objectif ?

La revue de sprint

L’événement suivant, la revue de sprint, sert à vérifier à la fin du sprint si les exigences ou les incréments que l’on s’est fixés pour ce sprint ont été réellement mis en œuvre et correspondent à une compréhension commune du « terminé », ou « Done » en anglais. La rétrospective clôt le sprint. Elle est l’élément décisif pour garantir l’idée d’Inspect and Adapt et donc l’amélioration continue. Pour finir, nous avons les deux artefacts dans Scrum : le Product Backlog et le Sprint Backlog. Le Product Backlog est la collection de toutes les exigences ou incréments possibles que le produit pourrait contenir. Il est géré par le Product Owner et est toujours classé par ordre de priorité, de sorte qu’il est toujours clair quelles exigences sont les plus importantes par rapport à la valeur commerciale. Le deuxième artefact est le Sprint Backlog. Le Sprint Backlog indique quels incréments seront mis en œuvre au cours de chaque sprint. Il est important qu’il ne soit jamais modifié au cours d’un sprint.

Les événements dans le framework de SCRUM

Avant le premier sprint

Dans la pratique, il existe plusieurs noms pour l’atelier avant le premier sprint, l’un des plus utilisés étant Sprint Zero. Le Spring Zero doit préparer le terrain pour que le premier sprint puisse avoir lieu. Il doit en quelque sorte préparer le terrain. Il s’agit notamment d’éviter les problèmes fréquents au début du projet, tels que le manque d’équipement ou les désaccords entre les parties prenantes sur la vision du produit.

Le Sprint Zero est animé par le Scrum Master et traite essentiellement trois aspects : les aspects spécifiques au projet, les aspects spécifiques à l’équipe et les aspects spécifiques à l’organisation. Les informations spécifiques au projet consistent à créer une compréhension commune du projet au sein de toute l’équipe. Cela comprend la présentation de la version du produit par le Product Owner. Le Product Owner présente ici la vision qui se cache derrière le produit, à quoi il sert, qui il doit aider et crée ainsi la base technique et, dans le meilleur des cas, la motivation de toute l’équipe. La clarification des parties prenantes du projet et leur implication. On pourrait rapidement répondre ici qu’il ne s’agit après tout que de l’équipe Scrum.

Le Sprint Zero est l’occasion idéale de clarifier quand et comment ces parties prenantes seront impliquées et où elles auront la possibilité d’intervenir. En outre, le Sprint Zero permet de discuter d’aspects importants tels que les risques, la durée approximative ou les coûts. Le deuxième élément du Sprint Zero sont les éléments spécifiques à l’équipe. Ils concernent la collaboration au sein de l’équipe Scrum. Cela concerne des aspects tels que les heures de travail, c’est-à-dire quand nous travaillons ensemble.

Les valeurs : Quelles sont les valeurs dans la collaboration en tant qu’équipe qui sont particulièrement importantes pour nous ? Ou encore le langage : quel est le langage utilisé dans le projet ? Dans Scrum, ces éléments comprennent également l’élaboration de la « Definition of Done », qui décrit les critères généraux permettant de déterminer quand une exigence est considérée comme remplie, et la « Definition of Ready », qui décrit comment une exigence doit être décrite par le Product Owner.

Les aspects organisationnels : Le troisième élément du Sprint Zero sont les aspects organisationnels. Cela concerne maintenant tous les aspects importants du projet au sein de l’organisation. Il peut s’agir de dates clés, d’informations concernant le projet, mais aussi de réunions critiques et importantes avec les parties prenantes au sein de l’organisation.

Planification de sprint

Regardons de plus près le premier événement qui a lieu dans un sprint : le Sprint Planning. Lors du Sprint Planning, on détermine ce qui sera mis en œuvre au cours du prochain sprint. Le Sprint Planning dure environ 2 heures, selon la durée du sprint. L’animateur de cet événement est le Scrum Master. Les points suivants sont particulièrement importants et font partie intégrante du Sprint Planning :

Un backlog de produit préparé, la présentation des exigences par le Product Owner et la création du backlog de sprint ainsi que la formulation de l’objectif du sprint. La préparation du Product Backlog est ici la condition de base sans laquelle cet événement ne peut avoir lieu. Avant l’événement, le Product Owner s’assure que suffisamment d’exigences sont décrites dans le Product Backlog de manière suffisamment précise pour que l’équipe de développement ait en tout cas suffisamment de travail pour le prochain sprint. Une description suffisamment précise signifie que les exigences correspondent à une définition commune du prêt, c’est-à-dire à des critères définis en commun sur ce qu’une exigence doit contenir pour être incluse dans un backlog de sprint.
La présentation des exigences, appelées User Stories dans Scrum, est le point suivant important. Elle est effectuée par le Product Owner. Comme la planification de sprint est limitée dans le temps et que le Scrum Poker présenté prend un certain temps, il faut parfois une méthode qui soit nettement moins longue. C’est là qu’intervient ce que l’on appelle l’estimation d’équipe. Lors de l’estimation de l’équipe, toutes les user stories à estimer sont réparties sur la table. Il s’agit de s’assurer que les User Stories présentées correspondent à l’idée de la version du produit ou de la valeur commerciale, et que l’utilité d’une User Story est toujours un élément central de la présentation. Dans le Sprint Planning, l’équipe de développement détermine ensuite de manière autonome combien de User Stories elle peut prendre en charge pendant le sprint. Les User Stories sont la plus petite unité d’exigence dans le Product Backlog. Une User Story décrit une action spécifique qui apporte une valeur ajoutée à nos utilisateurs. Une User Story est toujours écrite sous la forme En tant que [rôle], je veux [action] pour [bénéfice]
Le résultat est maintenant le Sprint Backlog. L’engagement joue ici un rôle essentiel. L’équipe s’engage à réaliser cette exigence, ce qui ressemble à une promesse pour l’équipe. Le dernier point de la planification du sprint est l’objectif du sprint. Ici, toute l’équipe Scrum formule un objectif global pour l’ensemble du sprint. En conclusion de cet événement, il doit représenter une fois de plus le point focal du sprint et encourager la motivation et l’esprit d’équipe.

La mêlée quotidienne

L’événement suivant dans un sprint est la réunion Scrum quotidienne. Il est important de noter qu’il s’agit d’un événement destiné en premier lieu à l’équipe de développement, le Product-Owner et le Scrum-Master n’étant pas obligatoires selon la doctrine Scrum pure. Dans la pratique, il est toutefois extrêmement recommandé que ces deux rôles participent au Daily-Scrum. La mêlée quotidienne dispose d’une boîte de temps de 15 minutes pendant lesquelles seule l’équipe de développement parle activement et répond successivement aux trois questions suivantes :

Qu’est-ce que j’ai réalisé hier qui aide l’équipe de développement à atteindre l’objectif du sprint ?
Qu’est-ce que je vais faire aujourd’hui pour aider l’équipe de développement à atteindre l’objectif du sprint ?
Est-ce que je vois des obstacles qui m’empêchent d’atteindre l’objectif ou qui empêchent l’équipe de développement d’atteindre l’objectif ?

Comme nous l’avons déjà mentionné, cet événement sert en premier lieu à l’équipe de développement ou à l’équipe de développement pour se synchroniser, identifier les obstacles à temps et garder un œil sur la progression du sprint.

Le Scrum Master devrait utiliser le Daily Scrum pour trouver des indications sur les points éventuellement problématiques de l’équipe, sur les points où il peut la soutenir et sur les éventuels obstacles qu’il peut aider à éliminer. Dans son rôle de coach et d’agent du changement, il obtient en outre des informations importantes sur l’état d’avancement de l’équipe en ce qui concerne la manière de travailler selon Scrum et sur les points de résistance qui nécessitent son intervention. Une mêlée quotidienne omise par le scrum master est donc toujours une occasion manquée de se faire une idée de l’état d’esprit.

Lors de la mêlée quotidienne, le Product-Owner obtient en outre un aperçu parfait et rapide de l’avancement du sprint et donc de son produit. Cela peut être très important pour les parties prenantes ou simplement pour son propre travail en tant que Product-Owner. Le deuxième point est l’un des plus importants. Lors de la mêlée quotidienne, les obstacles qui entravent l’équipe de développement apparaissent souvent au grand jour et, dans le pire des cas, mettent en péril l’objectif du sprint. Si le Product-Owner est directement présent, il peut ensuite travailler avec l’équipe de développement et le Scrum-Master à l’élimination des obstacles.

La revue de sprint

A la fin de chaque itération, c’est-à-dire de chaque sprint, a lieu la revue de sprint. Lors de la revue de sprint, l’équipe de développement présente ce qu’elle a réalisé au cours du sprint et le Product Owner prend connaissance des exigences réalisées, c’est-à-dire des User Stories.Une revue de sprint typique se déroule comme suit. Répétition de l’objectif du sprint, présentation des nouvelles fonctionnalités acquises, présentation des User Stories mises en œuvre par l’équipe de développement et acceptation par le Product Owner.

La partie principale de la revue de sprint, la présentation des user stories mises en œuvre par l’équipe de développement et l’acceptation par le Product Owner, est l’élément principal de cet événement. A ce stade, l’équipe de développement présente successivement les user stories mises en œuvre et montre directement sur le produit que tous les critères d’acceptation ont été remplis.

Après chaque User Story présentée, l’équipe de développement demande au Product Owner s’il peut accepter la User Story telle quelle. Si le Product Owner répond par l’affirmative, l’exigence est considérée comme réalisée. En cas de réponse négative, le Product Owner doit avoir une raison bien précise pour cela, qui ne peut en fait avoir que deux raisons : Un critère d’acceptation n’a pas été rempli ou un point de la Definition of Done n’a pas été respecté. La définition d’achèvement est, comme nous l’avons déjà mentionné, l’artefact Scrum qui rassemble les critères d’achèvement qui s’appliquent à toutes les user stories. Cette liste représente une compréhension commune du moment où une user story peut être considérée comme réalisée.

Souvent, une définition d’achèvement consiste en des souhaits du Product Owner concernant la qualité du produit. Il peut s’agir entre autres de souhaits en matière de sécurité, d’aspects d’évolutivité ou d’aspects pertinents pour l’utilisateur. Il devient donc rapidement évident que le propriétaire du produit et l’équipe de développement sont les principaux acteurs de la revue de sprint. Mais il y a aussi des points importants du point de vue du Scrum Master. Le Scrum Master organise l’événement, comme les autres événements, en veillant à ce que l’équipe et le Product Owner soient invités, qu’une salle soit organisée et que le timebox soit respecté. La revue de sprint dure entre une et quatre heures, selon le sprint. Le Scrum Master a particulièrement besoin d’intervenir lorsqu’une exigence n’est pas acceptée, mais que l’équipe de développement n’est pas d’accord avec le Product Owner. Dans ce cas, le Scrum Master a une fonction de modérateur.

La rétrospective de sprint

Comparée aux autres événements, la rétrospective a une importance particulière dans Scrum. D’un point de vue de coaching ou systémique, et donc pour le Scrum Master, elle constitue même le cœur de l’ensemble du framework : on fait ensemble une rétrospective de la dernière itération et on regarde ce qui fait vraiment avancer l’équipe et ce qui la bloque encore.

La rétrospective dans Scrum est le dernier événement de chaque sprint. L’objectif de la rétrospective est de donner à l’ensemble de l’équipe Scrum la possibilité de se pencher sur elle-même et sur le processus et d’examiner librement, selon l’approche « inspect and adapt », ce qui a bien fonctionné et ce qui n’a pas fonctionné et ce que nous pouvons en apprendre pour l’avenir. Il est important que l’apprentissage ne se concentre pas sur les aspects techniques, mais sur les personnes et le processus. La rétrospective doit déboucher sur des actions concrètes d’amélioration continue pour l’avenir. Contrairement à tous les autres événements, la rétrospective est un événement fermé. Afin de créer un climat d’ouverture et de confiance, seule l’équipe Scrum y participe et tout ce qui est discuté ici reste dans la rétrospective et ne quitte donc pas l’espace protégé. Le Scrum Master joue un rôle central dans la création de cet espace protégé. La rétrospective dure 45 minutes par semaine de sprint, soit par exemple 90 minutes pour un sprint de deux semaines. Elle est divisée en cinq phases que nous allons maintenant examiner de plus près.

Phase 1 : Créer un climat de discussion. Cette phase doit permettre d’arriver à la rétrospective. Chaque participant arrive probablement avec un état d’esprit différent. L’un sort d’une conversation téléphonique frustrante, l’autre d’une réunion stressante de six heures. Cette phase permet de créer l’atmosphère de base et d’expliquer à nouveau les règles et principes de base d’une rétrospective.

Phase 2 : Collecter des données. Les décisions qui ne font qu’effleurer la surface peuvent, en cas de doute, faire plus de mal que de bien. Dans cette phase, il s’agit tout d’abord de découvrir ce qui motive l’équipe. Sans porter de jugement, il s’agit d’abord de rassembler ce qui motive l’équipe, que ce soit positif ou négatif. Il s’agit en particulier d’élargir et d’ouvrir le champ. A la fin de cette phase, il convient encore d’établir des priorités afin de pouvoir ensuite se pencher en premier lieu sur les thèmes importants.

Phase 3 : acquérir des connaissances. Une erreur pourrait maintenant être de vouloir tirer des mesures immédiates des données obtenues. Il manquerait alors une étape décisive. Pourquoi les aspects sont-ils tels qu’ils sont et pourquoi sommes-nous arrivés précisément à ces thèmes ? Il s’agit ici avant tout d’aller en profondeur et de comprendre pourquoi un problème existe. Il s’agit en principe d’une phase préparatoire pour pouvoir ensuite développer des mesures ciblées qui s’attaquent aux problèmes à leur origine et ne se contentent pas de traiter les symptômes.

Phase 4 : Prendre des décisions. En fin de compte, les choses ne changeront que par l’action. La phase « Prendre des décisions » revêt donc une importance capitale. C’est ici que les décisions concrètes et les actions sont prises sur la base des phases précédentes. Il est très important de formuler la décision de la manière la plus concrète possible et de l’assortir d’une date et d’une responsabilité afin de créer un certain engagement.

Phase 5 : la conclusion. Cette phase est l’occasion de jeter un regard rétrospectif et émotionnel sur la rétrospective. Avec quel sentiment les participants sortent-ils de la rétrospective ? Quelle a été l’efficacité de l’événement ? Et avons-nous le sentiment d’avoir abordé les bons thèmes pertinents ? Qu’est-ce qui doit être fait différemment la prochaine fois et qu’est-ce qui doit être conservé ? Cela met un terme clair à la rétrospective et donne au Scrum Master l’opportunité d’adapter la prochaine rétrospective en fonction de l’équipe.

Le sprint

Au cours d’un sprint, il n’y a logiquement pas de déroulement fixe ou autre, car chaque rôle se concentre sur ses tâches, et pourtant, selon le rôle, il y a quelques modèles qui peuvent être reconnus dans chaque sprint. Le Scrum Master dans le sprint : pour le Scrum Master, la liste des impediment est l’artefact central pour l’organisation générale du sprint. La liste des impediment : Le Scrum Master doit tenir une liste visible de tous les impedimentations pendant tout le processus Scrum. L’objectif est de montrer de manière transparente qu’il travaille réellement à l’élimination des imperfections et que cela porte ses fruits, et de garantir qu’aucune imperfection ne soit oubliée. Organisation générale du sprint : Outre l’organisation de tous les événements, le Scrum Master est responsable du bon déroulement du sprint en général. Cela implique en premier lieu de protéger l’équipe afin qu’elle puisse travailler de manière auto-organisée et qu’elle dispose d’un espace sans perturbations, mais aussi, par exemple, d’être là en tant que coach pour le Product Owner et l’organisation. Le Product Owner dans le sprint : le Product Owner devrait en premier lieu être toujours disponible pour le reste de l’équipe en tant qu’interlocuteur. Les User Stories ont beau être bien décrites, il y a toujours des questions et des obstacles soudains qui ne peuvent être résolus que grâce aux informations du Product Owner. Une joignabilité permanente est donc essentielle pour le Product Owner. L’équipe de développement dans le sprint : l’équipe de développement devrait tout d’abord se concentrer entièrement sur elle-même et sur son sprint backlog pendant le sprint. Le sprint est la période la plus importante pour eux, ils n’ont donc pas d’autres tâches particulières, à l’exception de la mêlée quotidienne pendant le sprint.

L’artefact dans le framework : le Product Backlog

Le backlog de produit

Du point de vue du produit et donc du Product Owner, le Product Backlog est l’artefact décisif tout au long du processus Scrum. Le Product Owner est le gardien du Product Backlog. C’est son bureau, sur lequel il s’assoit chaque jour et qui doit toujours être rangé, actualisé et ordonné.

En quelques mots, le Product Backlog est une liste priorisée d’exigences, appelées Requirements. Dans le cadre du Product Backlog, on parle de critères DEEP pour un Product Backlog bien entretenu. Les critères DEEP sont en quelque sorte des conditions ou une orientation que le Product Owner doit respecter. Les lettres du mot DEEP signifient Detailed, c’est-à-dire raisonnablement détaillé, Estimated, estimé, Emergent, émergent, c’est-à-dire plus que la somme des parties individuelles, et Prioritized, prioritaire.

Les exigences situées en haut du Product Backlog ont une priorité si élevée qu’elles seront probablement mises en œuvre dans un avenir proche. Dans ce cas, il est important qu’elles soient déjà décrites de manière très détaillée. Si une exigence se trouve plutôt plus bas dans le Product Backlog, une description abstraite des exigences peut suffire. Estimée fait référence à la complexité des exigences décrites. Ces estimations sont extrêmement importantes pour l’ensemble de l’équipe Scrum. Pour l’équipe de développement, elles donnent des indications sur le nombre d’exigences qui peuvent être mises en œuvre en un sprint et pour le Product Owner, elles constituent une base pour la planification ultérieure des versions.

L’émergence est un point très important dans le contexte du cadre Scrum. Tout comme l’équipe de développement ne devrait pas se contenter de développer fonctionnalité après fonctionnalité, le Product Backlog est plus qu’une simple collection d’exigences. Il est toujours plus que la somme des éléments individuels, car il n’est ni plus ni moins que la mise par écrit de la vision du produit. Priorisé est le dernier point, mais pas le moins important. Dans Scrum, on travaille avec des timeboxes fixes, le temps est donc toujours fixe, mais jamais le volume. Il est donc d’autant plus important que le Product Backlog soit toujours priorisé, car dans le cas idéal, ce qui n’est pas mis en œuvre à la fin est une exigence sans importance. Mais pour que cela fonctionne vraiment, un product backlog doit toujours être priorisé. La priorisation devrait toujours se référer à l’importance par rapport à la valeur commerciale. Une autre possibilité de priorisation pourrait être le risque. Un Product Backlog complet remplit en fin de compte tous les critères DEEP et se compose des éléments suivants. Les User Stories : elles décrivent une exigence en une phrase concise. Les critères d’acceptation reflètent les critères techniques qui doivent être remplis pour que l’exigence soit considérée comme terminée. Une estimation qui reflète le degré de complexité estimé et ce que l’on appelle les épics. Les épics sont de grandes exigences qui ne peuvent pas être estimées et qui ne peuvent pas non plus être réalisées en un sprint. Elles doivent être traduites par la suite en User Stories plus précises.

Epics et User Stories

Intéressons-nous maintenant aux User Stories et aux Epics. Les User Stories sont la forme de représentation d’une exigence dans le Product Backlog. Une User Story tente de résumer les informations les plus importantes en une phrase concise, afin que l’équipe de développement dispose de suffisamment d’informations techniques pour pouvoir mettre en œuvre les exigences. La forme d’une user story typique est la suivante : « En tant que rôle, je souhaite atteindre l’objectif, de sorte que l’utilité ». La dernière partie de la phrase est certainement le point le plus important. Elle décrit l’utilité et donc le but de l’exigence, ou encore sa raison d’être. Pour les User Stories également, il existe des critères qui peuvent très bien être utilisés comme points de repère pour savoir si une Story est décrite avec suffisamment de précision pour pouvoir théoriquement être intégrée dans un Sprint. Ces critères sont appelés critères INVEST et se composent des lettres et significations suivantes : Independent (indépendant), Negotiable (négociable), Valuable (de valeur), Estimable (estimable), Small (suffisamment petit) et Testable (testable). Indépendant se réfère à la relation entre la User Story et les autres User Stories. Une user story doit être une exigence indépendante et ne pas être liée à une autre story. Négociable signifie qu’une exigence peut être modifiée jusqu’au moment où une User Story est intégrée de manière fixe dans un Sprint Backlog. Jusqu’à ce moment, les éléments du backlog peuvent être modifiés ou réécrits à tout moment. La valeur est étroitement liée à la valeur commerciale. Une User Story doit apporter une valeur ajoutée concrète à l’utilisateur ultérieur. Le fait qu’une user story puisse être estimée constitue une exigence centrale, notamment pour l’équipe de développement. Ce n’est qu’ainsi que l’équipe peut évaluer le nombre de User Stories qu’elle peut mettre en œuvre en un sprint. La taille d’une User Story est également décisive pour la planification d’un sprint. Une user story devrait toujours être suffisamment petite pour qu’il soit possible de la planifier avec une certaine fiabilité dans un sprint. La dernière exigence, la testabilité, se rapporte à la mise en œuvre d’une user story. Une user story doit être formulée de manière à ce qu’il soit possible de tester le résultat après la mise en œuvre des exigences. Le prochain élément essentiel d’une user story sont les critères d’acceptation. Alors que la formulation d’une User Story n’est qu’une brève description de l’exigence, les critères d’acceptation reflètent une compréhension commune du moment où une exigence est mise en œuvre. Cette compréhension commune de la mise en œuvre d’une exigence est notamment décisive pour la Sprint Preview, où l’équipe présente la User Story mise en œuvre. Voici un exemple de User Story : En tant que visiteur de la vidéothèque en ligne, je souhaite pouvoir classer tous les résultats de recherche des films afin de pouvoir trouver rapidement un film à mon goût. Les critères d’acceptation pourraient être les suivants : classement possible par genre ou classement possible selon les commentaires des clients. L’histoire d’utilisateur décrit dans ce cas l’exigence, le classement des résultats de recherche, et fournit aussi directement l’utilité, la recherche rapide d’un film, qui est satisfaite par cette exigence.Les critères d’acceptation donnent un cadre à l’histoire et donnent à l’équipe des indications sur l’effort à fournir.

Pourquoi faire des stratégies de tests de logiciel pour son entreprise ?

En étant dans une entreprise, il est primordial de faire attention à tout, que ce soit la relation client, la qualité des objets, le bien-être de l’équipe ou encore adopter les bonnes stratégies pour aller plus loin et faire le maximum de bénéfices. C’est pour cela qu’il existe une stratégie de test, qui consiste à tester les stratégies d’une entreprise, notamment au niveau de la publicité, du marketing ou encore de la cohérence des équipes. En effet, Loic G est un éditeur de Scapin, qui met son expertise à disposition des clients.

Cela consiste à mettre en place différentes démarches de qualité dans les entreprises afin de voir si tout est aux normes et que le système fonctionne correctement. De plus, il faut établir une définition d’une stratégie de test adaptée au contexte de l’entreprise, notamment en prenant en compte la concurrence par exemple. La stratégie de test prend aussi en compte l’organisation de la collaboration entre les différentes équipes de projets de l’entreprise, pour voir si la stratégie adoptée est la bonne, ou s’il est possible de l’améliorer pour qu’elle soit plus productive.

Toutes ces séries de test sont importantes, car cela permet à l’entreprise de se positionner et de voir sur quels points l’entreprise devrait changer ou évoluer. Il est donc primordial de passer par cette case afin de permettre à l’entreprise de mieux appréhender son futur et faire en sorte que celle-ci ait le monopole dans son domaine. De plus, il existe des logiciels très puissants qui vous permettront de travailler avec votre client beaucoup plus facilement, tout en étant dans l’air du temps et à la pointe de la technologie. Vous devez donc prendre soin de votre entreprise et tester toutes les possibilités de croissance.