LOW CODE & TECHNOLOGIE
Lexique de la méthode Agile
13 Février 2023
Habituellement, pour conduire un projet en entreprise, les moindres détails sont exposés dès le départ dans un cahier des charges souvent fastidieux. Mais les choses se déroulent rarement comme prévu et une planification trop rigide s’avère en réalité contre-productive. C’est le constat sur lequel se fonde la méthode Agile, qui redonne toute sa place aux changements et besoins mouvants. Voyons de plus près ce qu’est la méthode Agile à travers un tour d’horizon de son lexique : ses valeurs, ses acteurs, ses processus et ses rituels clés.
Adopter le mindset Agile
Connue sous le nom de « méthode Agile », cette nouvelle façon d’aborder la gestion de projet est bien plus qu’un énième procédé en vogue. Parce qu’elle repose avant tout sur des valeurs et des principes recensés en 2001 dans l’Agile manifesto, la méthode Agile s’apparente à un état d’esprit voire une philosophie.
Les valeurs
L’Agile Manifesto reconnaît la valeur des seconds éléments exposés dans les 4 phrases ci-dessous, mais privilégie :
• Les individus et les interactions plus que les processus et les outils.
• Des logiciels opérationnels plus qu’une documentation exhaustive.
• La collaboration avec les clients plus que la négociation contractuelle.
• L’adaptation au changement plus que le suivi d’un plan.
Comprenez bien que la mise en place de la méthode Agile ne signifie pas pour autant qu’il n’est plus nécessaire d’établir un plan ou de documenter son travail.
« Plus qu’une méthode, l’agilité est un état d’esprit qui permet de s’adapter au changement plus rapidement en plaçant la communication au cœur du projet. »
Les principes
L’Agile Manifesto relate 12 principes qui illustrent les 4 valeurs présentées ci-dessus.
-
- La satisfaction du client est la plus haute priorité. Il convient d’y répondre par la livraison rapide et régulière de fonctionnalités à forte valeur ajoutée.
- Accueillir positivement les changements et nouveaux besoins, même s’ils surviennent alors que le projet est déjà à un stade avancé.
- Livrer fréquemment un produit opérationnel avec des cycles de quelques semaines à quelques mois et une préférence pour les plus courts.
- Miser sur une coopération constante entre les parties prenantes et l’équipe produit.
- Réaliser les projets avec des personnes motivées à qui l’on accorde sa confiance, et à qui l’on procure l’environnement et le soutien dont elles ont besoin pour atteindre les objectifs fixés.
- Privilégier le dialogue en face-à-face pour transmettre de l’information à l’équipe de développement et à l’intérieur de celle-ci.
- Un produit opérationnel doit être la principale mesure de progression.
- Instaurer un rythme soutenable et constant pour faire avancer le projet.
- Porter une attention continue à l’excellence technique et à la conception.
- La simplicité, c’est-à-dire l’art de minimiser la quantité de travail inutile, est essentielle.
- Favoriser la responsabilisation des équipes: les meilleures architectures, spécifications et conceptions émergent des équipes auto-organisées.
- Réfléchir aux moyens de devenir plus efficace à intervalles réguliers, puis ajuster son comportement en fonction.
L’équipe Agile : rôles et responsabilités
L’individu étant au cœur des valeurs de la méthode agile, il est tout naturel que nous vous présentions son équipe avant tout autre chose.
Le Product Owner (PO)
Le Producteur Ower est responsable de la valeur du produit délivré par son équipe. Il priorise les sujets afin d’organiser le « Backlog » et rédige les « User stories », deux termes que nous vous expliquerons un peu plus bas dans l’article. Le Product Owner fait également le lien entre les équipes techniques chargées de développer le produit et le client qui a exprimé son besoin.
Le Scrum Master
Le Scrum Master est le garant du respect de la méthodologie Scrum, notamment du rythme donné par les « Sprints » et des tâches à réaliser rassemblées dans le « Backlog ». Il réunit les qualités et compétences d’un coach et d’un chef de projet, bien qu’il ne soit pas à l’origine de la conception du projet.
D’ailleurs, savez-vous différencier la notion « Agile » de celle de « Scrum », souvent présentées à tort comme des synonymes ? En fait, Scrum est la méthode agile la plus répandue, mais elle n’est pas la seule. On peut alors parler de Scrum pour qualifier des pratiques et techniques spécifiques, fidèles aux valeurs et principes de la méthode Agile.
L’équipe de développement
L’équipe de développement, ou Development Team, se compose des professionnels (entre trois et neufs) qui livrent les nouveaux éléments en état d’utilisation à la fin de chaque Sprint. Autonome, l’équipe est seule à décider de la façon dont elle va « transformer les éléments du Backlog Produit en incréments de fonctionnalités potentiellement publiables », selon les termes du Guide Scrum.
Business Owner
Le Business Owner est responsable des aspects commerciaux et techniques, de la conformité et du retour sur investissement (ROI).
Stakeholders
Les Stakeholders, ou « parties prenantes » en français, sont des personnes externes à l’équipe Scrum ayant toutefois un intérêt et des connaissances utiles à l’avancement du projet. Il peut s’agir d’utilisateurs, de clients externes ou internes. Le Product Owner s’assure que les Stakeholders assistent au « Sprint Review ».
Les principaux processus de la méthode Agile
Le Product Backlog
Le Product Backlog est la liste des items en attente de développement et nécessaires à la création du fameux produit que l’on souhaite réaliser.
Le Sprint Backlog
L’équipe Scrum va insérer les items du Backlog dans le Sprint Backlog pour tenter de répondre à l’objectif du Sprint en cours.
La User Storie
Une Uster Storie est une demande de fonctionnalité à réaliser basée sur un besoin utilisateur. Il existe différentes façons de rédiger une User Storie, mais voici la plus populaire :
-
- En tant que [qui]
- Je souhaite [quoi]
- Afin de [pourquoi]
Definition of Done
La Definition of Done est l’ensemble des critères devant être remplis (tests fonctionnels, critères de qualité, documentation technique…) pour dire qu’un item est bel et bien terminé. Une fois validé par le Product Owner, l’item peut passer en phase de production.
Les Scrum Events
Le Sprint Planning
Le Product Owner, le Scrum Master et l’équipe de développement participent au Sprint Planning, événement au cours duquel l’objectif du Sprint va être défini. Afin d’atteindre cet objectif, l’équipe Scrum sélectionne les éléments prioritaires du Backlog puis procède au découpage des Items en tâches techniques et opérationnelles.
Le Sprint Review
Le Sprint Review est la cérémonie qui clôt le sprint en cours afin d’inspecter l’incrément réalisé et, si nécessaire, d’adapter le Backlog. L’ensemble de l’équipe Scrum est présente, et éventuellement des parties prenantes et des sponsors.
Le Sprint Retrospective
À travers le Sprint Retrospective, l’équipe s’engage à prendre le temps de chercher des axes d’amélioration dans sa façon de travailler. Ils essaient en toute transparence de déterminer ce qui a fonctionné, ce qui peut être perfectionné et ce qui pourra être tenté pour le prochain Sprint.
Le Daily Stand-Up
Au coursn d’u Sprint, l’équipe de développement, et éventuellement le Scrum Master et le Product Owern, se réunit chaque jour pendant 15 minutes tout en restant debout. Ils constatent l’avancement du projet, reviennent sur les possibles difficultés et décrivent les prochaines tâches qu’ils vont accomplir.
Product Backlog Refinement
Le Product Backlog Refinement consiste à ajouter des détails, des estimations et de l’ordre aux items du Backlog. La mise à jour continue du Backlog est nécessaire dans chaque sprint afin d’affiner les éléments et d’être prêt pour les prochains sprints.
La méthode Agile, grâce à ses rituels qui valorisent la collaboration avec les clients, un travail d’équipe efficace et une grande flexibilité face au changement, séduit de plus en plus d’entreprises. Et puisque nous l’appliquons nous-mêmes pour le développement d’applications internes sur-mesure que nous concevons pour des entreprises, nous ne pouvons que constater et diffuser la qualité de ses résultats.
5 raisons d’utiliser la plateforme de low-code Mendix
Notre expertise de digitalisation dans le domaine de l’assurance nous permet d’avoir aujourd’hui une vision aiguisée sur l’usage du Low Code dans ce domaine d’activité. Voici les raisons qui font du low-code l’outil indispensable des leaders de l’assurance.