Catégorie : Agilité, Lean & produit

Les méthodes agiles sont des approches de gestion de projet favorisant l’adaptation, la collaboration et la livraison itérative. Elles permettent au client de recevoir rapidement un produit fonctionnel, ajustable selon ses besoins. Pour les équipes, elles offrent plus d’autonomie, de motivation et une meilleure réactivité face aux changements.

Qu’est-ce qu’une Sprint review ?

10 mai 2024 / Claude BUENO / 0 Comments

La Revue de sprint (Sprint review) est l’un des cinq événements du cadre Scrum. Cet événement permet à l’équipe Scrum et aux parties prenantes d’examiner les progrès accomplis dans la réalisation de l’objectif du produit et de déterminer les adaptations futures.

Comme tous les événements Scrum, la revue de sprint a lieu pendant le sprint lui-même. Elle ne se produit pas en dehors de la cadence du sprint.

Qu’est-ce qu’une Revue de sprint ?

C’est une réunion collaborative qui a lieu à chaque sprint. Cela dit, il n’est pas nécessaire de la considérer comme une « réunion » au sens traditionnel du terme. Cette réunion est en fait appelée un « événement » dans Scrum. Il existe cinq événements :

Le sprint
La planification du sprint (Sprint planning)
La mêlée quotidienne (Daily scrum)
La revue de sprint (Sprint review)
La rétrospective du sprint (Sprint retrospective)

Tous ces événements sont des occasions d’inspecter et d’adapter.

Les revues de sprint ne doivent pas nécessairement prendre la forme d’une réunion classique. Vous pouvez organiser un espace ouvert, utiliser des outils interactifs en ligne ou d’autres techniques de collaboration qui rassemblent les gens pour inspecter et s’adapter.

Vous devriez organiser une revue de sprint avant la rétrospective de sprint. De cette façon, l’équipe peut discuter librement de tout retour d’information qu’elle a reçu sur ses processus dans un environnement psychologiquement sûr.

Les revues de sprint ont une durée qui varie suivant la taille des sprints. Par exemple :

Durée du sprint	Durée revue de sprint
4 semaines	4 heures
2 semaines	2 heures

La durée de la revue de sprint est un maximum : les équipes Scrum ne remplissent pas la totalité du temps si elles ont atteint leur objectif avant la fin.

Cet événement doit être plus qu’une simple présentation. C’est l’occasion pour l’équipe de scrum d’avoir une discussion avec les parties prenantes et d’obtenir un retour d’information précieux.

L’événement comprend, sans s’y limiter, les éléments suivants :

Inspection des résultats du sprint et questions sur les résultats
Inspection de la manière dont les résultats contribuent à l’objectif du produit
Inspection des conditions externes, telles que les conditions du marché
Inspection des contraintes internes, telles que les étapes, les budgets et les calendriers
Adaptations si nécessaire

Lors de la revue de sprint, l’équipe Scrum partage les résultats du sprint en cours avec les parties prenantes et les autres participants qu’elle a invités. L’équipe présente les éléments du backlog qui répondent à sa définition de réalisation (Definition Of Done) et discute des difficultés rencontrées. Cet événement permet de faire le point sur les progrès accomplis dans la réalisation de l’objectif du produit, sur les difficultés rencontrées et sur la marche à suivre.

Objectifs d’une revue de sprint

Les objectifs typiques d’une revue de sprint sont les suivants :

Partager les incréments et le travail : L’équipe de mêlée peut montrer les incréments de travail qu’elle a réalisés au cours du sprint, ce qui permet aux parties prenantes de voir les progrès accomplis. L’équipe peut également expliquer ce qui a changé dans son environnement et ce qui a pu limiter ses capacités dans les domaines où elle n’a fait que des progrès partiels.
Demander aux parties prenantes de faire part de leurs commentaires : L’événement ne doit pas se limiter à une démonstration de l’incrément. Cet événement permet aux parties prenantes de donner leur avis sur le travail et d’engager une discussion avec l’équipe Scrum. Il aide l’équipe à comprendre si elle avance dans la bonne direction et si elle doit faire des ajustements.
Mettre à jour le Product Backlog : Sur la base du retour d’information reçu, le Product Owner peut mettre à jour le Product Backlog pour refléter les nouvelles idées ou les changements nécessaires. Dans des cas extrêmes, l’ensemble du backlog peut être supprimé si l’orientation du développement du produit nécessite un tel changement.
Identifier les prochaines étapes : En collaboration, l’équipe de mêlée et les parties prenantes peuvent discuter et identifier les priorités, les besoins et les changements. Ces informations aident l’équipe de mêlée lors de son prochain événement de planification du sprint, au cours duquel elle crée un objectif de sprint et un plan pour l’atteindre.
Faciliter la collaboration : La revue de sprint favorise la collaboration entre l’équipe Scrum et les parties prenantes. Elle encourage une communication ouverte, permettant à l’équipe de comprendre les attentes des parties prenantes et de déterminer les prochaines étapes. Comme tous les événements Scrum, la revue de sprint est une occasion de transparence, d’inspection et d’adaptation – les trois piliers du processus empirique Scrum.

Qui doit assister à la revue de sprint ?

L’équipe Scrum y assiste : les développeurs, le Scrum Master et le Product Owner. La revue de sprint est ouverte à toutes les parties prenantes. Souvent, les équipes de mêlée invitent des personnes qui ont un intérêt dans le travail le plus récent qu’elles ont réalisé. L’équipe peut inviter des clients ou des utilisateurs.

En tant que créateurs de l’incrément, les développeurs jouent un rôle essentiel en partageant leur travail et en répondant aux questions.

Le Product Owner participe à la réunion pour fournir des conseils sur les décisions relatives au produit et pour intégrer les commentaires des parties prenantes dans le Product Backlog. Les décisions du Product Owner sont visibles dans le contenu et l’ordre du backlog et dans l’incrément inspectable. Le Product Owner peut soutenir les développeurs lorsqu’ils partagent les résultats.

Le rôle du Scrum Master dans cet événement peut varier d’une réunion à l’autre. Il est là pour soutenir et guider l’équipe de mêlée qui apprend à animer cet événement et à l’utiliser comme une occasion de maintenir la transparence, l’inspection et l’adaptation. Le Scrum Master peut parfois animer lui-même la revue de sprint, bien que celà ne fasse pas partie de sa responsabilité.

Conseils pour une revue de sprint réussie

A quoi doit ressembler l’agenda ?

Voici un exemple d’ordre du jour de la revue de sprint. Vos discussions au cours de cet événement peuvent inclure :

Rappeler à tous l’objectif du produit et l’objectif du sprint,
Montrer le travail achevé ou l’incrément du sprint en cours,
Discuter de la publication de l’incrément par rapport au budget, aux délais, au marché et à d’autres facteurs pertinents,
Discuter du travail le plus utile pour les sprints à venir.

Qui doit animer une revue de sprint ?

L’équipe Scrum facilite cet événement et invite les parties prenantes et d’autres participants si nécessaire. Comme le Product Owner est responsable de la maximisation de la valeur du produit résultant du travail des développeurs, il prendra souvent la tête ou lancera la conversation dans la revue de sprint.

Votre équipe Scrum et votre contexte seront uniques, et dans le cadre d’une rétrospective, vous devriez discuter des meilleures façons pour votre équipe de mener la réunion, que cela implique que le Product Owner guide la revue ou un format différent.

Quelle est la différence entre une Revue de sprint et une Rétrospective de sprint ?

La meilleure façon de comprendre la différence entre ces deux événements est de reconnaître la différence d’objectif et de participation entre les événements.

La revue porte sur le produit. La rétrospective concerne la collaboration et l’interaction de l’équipe.

La revue de sprint a lieu en premier afin que l’équipe puisse prendre en compte les commentaires des parties prenantes lorsqu’elle prend des décisions sur les actions à entreprendre au cours de la rétrospective de sprint. Les parties prenantes assistent à la revue de sprint, mais la rétrospective est un événement réservé à l’équipe Scrum.

Une occasion d’inspecter et d’adapter

L’équipe Scrum peut partager ses résultats et recevoir des commentaires précieux des parties prenantes lors de la revue de sprint. Le cadre Scrum favorise la transparence, la collaboration et l’amélioration continue au sein de l’équipe. En exploitant efficacement la revue de sprint, les équipes Scrum peuvent s’assurer qu’elles apportent de la valeur à leurs clients et qu’elles répondent aux attentes des parties prenantes.

Glossaire Lean

30 mars 2024 / Claude BUENO / 0 Comments

Ce glossaire Lean a pour objectif de présenter les termes clés du Lean. Il est organisé par ordre alphabétique, et chaque terme est accompagné d’une courte description et un lien vers un article développant plus amplement le concept. Il s’adresse à toute personne qui souhaite se familiariser avec le vocabulaire et les notions du Lean, que ce soit pour apprendre, enseigner, pratiquer ou approfondir le sujet.

Le Lean est une philosophie de management qui vise à améliorer la performance des organisations en éliminant les gaspillages, en optimisant les flux de valeur, et en impliquant les collaborateurs dans une démarche d’amélioration continue. Le Lean repose sur un ensemble de concepts, de principes, de méthodes et d’outils qui ont été développés et popularisés par le système de production de Toyota.

Volontairement et pour faciliter l’appropriation du vocabulaire, j’ai décidé de faire figurer dans ce glossaire Lean les termes en anglais. En effet, il est courant, même dans les équipes francophones, d’utiliser les concepts dans la langue de Shakespeare.

A

Andon

Un système visuel utilisé pour signaler les problèmes ou les anomalies dans un processus, permettant une intervention rapide pour les résoudre.

B

C

Cycle de vie de valeur (Value Stream)

La séquence complète des activités nécessaires pour transformer les matières premières en un produit fini, en incluant toutes les étapes de création de valeur et les éventuels gaspillages.

D

E

F

Flux de travail (Workflow)

Le cheminement des tâches et des activités d’un processus, de leur initiation à leur achèvement, en passant par différentes étapes ou étapes intermédiaires.

G

Gemba

Un terme japonais qui signifie “le lieu réel” ou “le lieu de travail réel”, désignant l’endroit où le travail réel se déroule et où les problèmes peuvent être observés et résolus.
Lire l’article : Gemba Walk : observer pour transformer

H

Heijunka

Une technique de nivellement de la production qui permet de produire des quantités équilibrées et régulières, afin de réduire les variations et d’améliorer la flexibilité du processus.

I

IPO (ou Input-Process-Output)

Un modèle conceptuel qui décrit les entrées, les processus et les sorties d’un système ou d’un processus.

J

Juste-à-temps (Just-in-Time)

Un concept de gestion visant à réduire les stocks et les temps d’attente en fournissant les matériaux, les informations et les ressources nécessaires au moment précis où ils sont requis.

K

Kaizen

Un principe d’amélioration continue qui encourage l’implication de tous les membres de l’organisation dans l’identification et la résolution des problèmes, afin d’apporter des améliorations incrémentales et durables.

L

Lean

Une approche qui vise à éliminer le gaspillage et à optimiser les processus de développement en se concentrant sur la valeur ajoutée pour le client.

M

Muda

Le terme japonais pour “gaspillage”, désignant toute activité qui n’ajoute pas de valeur au produit ou au processus, telle que le transport excessif, les stocks excessifs ou les défauts de qualité.

MVP (Minimum Viable Product)

La version minimale d’un produit qui satisfait les besoins de base des utilisateurs et qui peut être utilisée pour recueillir des commentaires et des apprentissages.

N

O

P

Poka-Yoke

Une technique de prévention des erreurs ou des défauts en concevant des dispositifs ou des mécanismes pour éviter les erreurs humaines ou pour les détecter immédiatement.

Q

R

S

SMED (Single-Minute Exchange of Die)

Une méthode de réduction des temps de changement d’outils ou de configurations dans les processus de fabrication, afin d’augmenter la flexibilité et de réduire les temps d’arrêt.

T

Takt Time

Le rythme ou le tempo requis pour terminer une unité de travail dans le temps disponible, basé sur la demande du client et la capacité de production.

U

V

Valeur (Value)

Un concept central du Lean qui définit ce que le client considère comme utile et pour lequel il est prêt à payer, en éliminant les activités non essentielles ou sans valeur ajoutée.

W

WIP (Work in Progress)

Les travaux en cours dans un processus, représentant les tâches ou les unités de travail qui ont été commencées mais qui ne sont pas encore terminées.

X

Y

Z

Glossaire Agile – Scrum

30 mars 2024 / Claude BUENO / 0 Comments

Ce glossaire Agile et Scrum fournit une sélection de termes couramment utilisés dans les pratiques agiles. D’autres termes spécifiques peuvent être utilisés en fonction du cadre de travail ou de la pratique Agile adoptée par une équipe ou une organisation.

Volontairement et pour faciliter l’appropriation du vocabulaire, j’ai décidé de faire figurer les termes de ce glossaire en anglais. En effet, il est courant, même dans les équipes francophones, d’utiliser les concepts dans la langue de Shakespeare.

A

Agile

Une approche de gestion de projet axée sur la flexibilité, la collaboration et l’adaptation aux changements.

B

Backlog (Carnet de produit)

Une liste ordonnée des fonctionnalités, des tâches ou des éléments de travail à réaliser dans un projet.

Burn-down Chart

Un graphique qui montre la quantité de travail que l’on pense qu’il reste à faire dans un backlog. Le temps est indiqué sur l’axe horizontal et le travail restant sur l’axe vertical. Au fur et à mesure que le temps passe et que des éléments sont tirés du backlog et achevés, on peut s’attendre à ce que la ligne du graphique montrant le travail restant diminue.

Burn-up Chart

Un graphique qui montre la quantité de travail qui a été accomplie. Le temps est indiqué sur l’axe horizontal et le travail accompli sur l’axe vertical. Au fur et à mesure que le temps passe et que des éléments sont tirés du backlog et achevés, on peut s’attendre à ce que la ligne du graphique montrant le travail accompli augmente.

C

Cycle de vie itératif

Une approche de développement où le projet est découpé en itérations ou en cycles, avec des versions fonctionnelles du produit livrées à chaque itération.

D

Daily Scrum ou Daily Stand-up Meeting (Mêlée quotidienne)

Un évènement Scrum d’une durée maximale de 15 minutes organisé chaque jour pour les développeurs. La Mêlée quotidienne a lieu chaque jour du Sprint. Les développeurs y planifient le travail pour les 24 heures à venir. Cela permet d’optimiser la collaboration et les performances de l’équipe en inspectant le travail effectué depuis la dernière mêlée quotidienne et en prévoyant le travail à venir dans le cadre du sprint. La mêlée quotidienne se tient chaque jour à la même heure et au même endroit afin de réduire la complexité.

Definition of Done – DoD (Définition de terminé)

Est une description formelle de l’état de l’incrément lorsqu’il répond aux mesures de qualité requises pour le produit. Dès lors qu’un élément du Backlog de produit répond à la définition d’achèvement, un incrément est né. La Definition of Done crée la transparence en fournissant à chacun une compréhension partagée du travail accompli dans le cadre de l’incrément. Si un élément du carnet de commandes ne répond pas à la définition de « terminé », il ne peut pas être publié ni même présenté lors de la Sprint review (revue de sprint).

Developer (Développeur)

Tout membre d’une équipe Scrum qui s’engage à créer tout aspect d’un incrément utilisable à chaque sprint, quelle que soit sa spécialité technique, fonctionnelle ou autre.

E

Emergence

Le processus d’apparition ou de mise en évidence de nouveaux faits ou d’une nouvelle connaissance d’un fait, ou la connaissance d’un fait devenant visible de manière inattendue.

Empirisme

La philosophie selon laquelle toute connaissance trouve son origine dans l’expérience et les observations. Dans le contexte de Scrum, l’empirisme fait référence à l’idée que la résolution de problèmes complexes, ou la réalisation d’un travail complexe, ne peut se faire qu’en utilisant un processus exploratoire plutôt qu’en s’appuyant sur des plans prédéterminés.

Estimation

Le processus d’évaluation de la taille, de la complexité ou de l’effort requis pour réaliser une tâche ou une fonctionnalité.

F

Feedback (Rétroaction)

Les commentaires, les suggestions et les évaluations reçus des parties prenantes ou des utilisateurs du produit.

G

Grooming de backlog (voir Product Backlog refinement)

Le processus de revue, de clarification et de priorisation des éléments du backlog, généralement réalisé lors de réunions de planification.

H

I

Increment

Artifact Scrum qui définit le travail complet et précieux produit par les développeurs au cours d’un Sprint. La somme de tous les Increments constitue un produit.

Intégration continue

Une pratique de développement où les modifications de code sont régulièrement intégrées à un référentiel commun, permettant une détection précoce des problèmes et une collaboration continue.

IPO (ou Input-Process-Output)

Un modèle conceptuel qui décrit les entrées, les processus et les sorties d’un système ou d’un processus.

Itération

Une période définie de temps pendant laquelle un ensemble spécifique de tâches ou de fonctionnalités est développé et testé.

J

K

L

M

Minimum Viable Product – MVP

La version minimale d’un produit qui satisfait les besoins de base des utilisateurs et qui peut être utilisée pour recueillir des commentaires et des apprentissages.

N

O

P

Planning Poker

Une technique d’estimation collaborative où les membres de l’équipe utilisent des cartes numérotées pour donner leur estimation relative de l’effort requis pour réaliser une tâche ou une user story.

Product Backlog

Un artefact Scrum qui consiste en une liste ordonnée du travail à effectuer pour créer, maintenir et pérenniser un produit. Le Product Backlog est géré par le Product Owner.

Product Backlog refinement

Une activité continue visant à affiner et à clarifier les éléments du backlog, généralement réalisée par le Product Owner et l’équipe de développement. C’est l’activité d’un sprint par laquelle le Product Owner et les développeurs ajoutent de la granularité au backlog (carnet de produit).

Product Goal (L’objectif de produit)

Décrit un état futur du produit qui peut servir de cible à l’équipe Scrum pour planifier. Il se trouve dans le Backlog produit. Le reste du Backlog permet de visualiser ou définir ce qui reste pour atteindre l’objectif du produit.

Product Increment

La somme de tous les éléments de backlog terminés pendant un sprint et intégrés au produit existant.

Product Owner

La personne responsable de la définition des fonctionnalités et des priorités du produit, ainsi que de la coordination avec les parties prenantes. Rôle dans Scrum responsable de la maximisation de la valeur d’un produit, principalement en gérant et en exprimant de manière incrémentale les attentes commerciales et fonctionnelles d’un produit aux développeurs.

Q

R

Ready

Une compréhension partagée par le propriétaire du produit et les développeurs concernant le niveau préféré de description des éléments du Backlog de produit introduits lors de la planification du sprint.

Refactoring

Le processus d’amélioration de la structure interne du code sans en changer le comportement externe, afin d’améliorer la maintenabilité et la lisibilité.

Release Planning

Le processus de planification à plus long terme visant à déterminer le moment et le contenu des livraisons de versions du produit.

S

Scrum

Scrum est un cadre léger qui aide les personnes, les équipes et les organisations à générer de la valeur par le biais de solutions adaptatives à des problèmes complexes, comme le définit le Scrum Guide.

Scrum Board

Un tableau physique pour visualiser les informations pour et par l’équipe Scrum, souvent utilisé pour gérer le Backlog de Sprint. Les tableaux Scrum sont une implémentation optionnelle au sein de Scrum pour rendre l’information visible.

Scrum Guide

La définition de Scrum, rédigée et fournie par Ken Schwaber et Jeff Sutherland, cocréateurs de Scrum. Cette définition comprend les responsabilités, les événements, les artefacts et les règles qui les relient.

Scrum Master

Rôle au sein d’une équipe Scrum responsable de l’orientation, du coaching, de l’enseignement et de l’assistance d’une équipe Scrum et de ses environnements dans la compréhension et l’utilisation correctes de Scrum.

Scrum Team (Équipe Scrum)

Une équipe autogérée composée d’un Scrum Master, d’un Product Owner et de Developers.

Scrum Value (Valeurs Scrum)

Un ensemble de valeurs et de qualités fondamentales qui sous-tendent le cadre Scrum ; engagement, concentration, ouverture, respect et courage.

Self-Managing (Autogestion)

Les équipes Scrum sont interfonctionnelles, ce qui signifie que leurs membres possèdent toutes les compétences nécessaires pour créer de la valeur à chaque sprint. Elles sont également autogérées, ce qui signifie qu’elles décident en interne qui fait quoi, quand et comment.

Sprint

L’événement Scrum qui est limité dans le temps à un mois ou moins, et qui sert de conteneur pour les autres événements et activités Scrum. Les sprints sont réalisés consécutivement, sans intervalle intermédiaire.

Sprint Backlog (Backlog de sprint)

Artifact Scrum qui fournit une vue d’ensemble du travail de développement pour réaliser l’objectif d’un Sprint, typiquement une prévision de fonctionnalité et le travail nécessaire pour livrer cette fonctionnalité. Géré par les développeurs.

Sprint Goal (Objectif du Sprint)

Une courte expression de l’objectif d’un Sprint, souvent un problème d’entreprise qui est abordé. La fonctionnalité peut être ajustée pendant le Sprint afin d’atteindre l’objectif du Sprint.

Lire l’article : Comment définir le Sprint Goal (Objectif du sprint) ?

Sprint Planning (Planification du Sprint)

L’événement Scrum qui est limité à 8 heures, ou moins, pour commencer un Sprint. Il sert à l’équipe Scrum à inspecter le travail du Backlog de produit qui est le plus utile à faire ensuite et à concevoir ce travail dans le Backlog de Sprint.

Sprint Retrospective (Rétrospective de sprint)

L’événement Scrum qui est fixé à un délai de 3 heures, ou moins, à la fin d’un Sprint. Elle permet à l’équipe Scrum d’inspecter le Sprint passé et de planifier les améliorations à apporter lors des prochains Sprints.

Lire l’article : Fais souffler un vent d’agilité dans tes rétros

Sprint Review (Revue de Sprint)

L’événement Scrum qui est fixé à une durée de 4 heures, ou moins, pour conclure le travail de développement d’un Sprint. Elle permet à l’équipe Scrum et aux parties prenantes d’inspecter l’incrément de produit résultant du Sprint, d’évaluer l’impact du travail effectué sur la progression globale vers l’objectif du produit et de mettre à jour le carnet de commandes du produit afin de maximiser la valeur de la prochaine période.

Lire l’article : Qu’est-ce qu’une Sprint review ?

Stakeholder (Partie prenante)

Personne extérieure à l’équipe Scrum ayant un intérêt spécifique et une connaissance d’un produit qui est nécessaire pour la découverte incrémentale. Représentée par le Product Owner et activement engagée avec l’équipe Scrum lors de la Sprint Review.

T

Test d’acceptation

Un type de test réalisé pour vérifier si le produit répond aux exigences et aux critères d’acceptation définis par les parties prenantes.

U

User story (Histoire utilisateur)

Une description concise d’une fonctionnalité du point de vue de l’utilisateur, utilisée comme base pour le développement et les tests.

V

Value (Valeur)

Un concept central du Lean qui définit ce que le client considère comme utile et pour lequel il est prêt à payer, en éliminant les activités non essentielles ou sans valeur ajoutée.

Value Stream (Cycle de vie de valeur)

La séquence complète des activités nécessaires pour transformer les matières premières en un produit fini, en incluant toutes les étapes de création de valeur et les éventuels gaspillages.

Velocity (Vélocité)

Une mesure de la quantité de travail qu’une équipe de développement peut accomplir pendant une itération, généralement exprimée en points de story ou en unités de travail.

W

Work in Progress – WIP

Les travaux en cours dans un processus, représentant les tâches ou les unités de travail qui ont été commencées mais qui ne sont pas encore terminées.

X

Y

Z

Glossaire Agile – Kanban

30 mars 2024 / Claude BUENO / 0 Comments

La méthode Kanban est une approche de gestion de projet qui vise à optimiser le flux de travail et à réduire les gaspillages. Elle repose sur l’utilisation d’un tableau visuel qui représente les différentes étapes du processus, ainsi que les tâches à réaliser, en cours ou terminées.

Le tableau Kanban permet de visualiser l’état d’avancement du projet, de limiter le nombre de tâches en cours (le WIP ou Work In Progress) et d’identifier les goulots d’étranglement.

Voici un glossaire des principaux termes utilisés avec la méthode Kanban :

A

Activité

Actions entreprises dans le cadre du flux de travail de la prestation de services qui font progresser un élément de travail vers l’étape suivante de la découverte des connaissances. Une ou plusieurs activités peuvent être visualisées sous la forme d’une colonne dans un tableau Kanban.

B

Backlog

le backlog est la liste des tâches à réaliser pour le projet. Il peut être priorisé selon l’importance ou l’urgence des tâches. Le backlog est alimenté par les demandes des clients, les besoins des utilisateurs ou les idées de l’équipe.

Bloqueur

Quelque chose qui entrave le déroulement d’un travail. Le blocage peut être partiel ou total.

C

Cadences

Un type de réunion ou d’examen fournissant un retour d’information d’un ou de plusieurs services dans le but d’examiner, de coordonner ou d’améliorer le travail fourni.

Capacité

Mesure de la performance d’un système. Les mesures peuvent inclure le délai d’exécution et le débit. Pour plus d’informations sur les mesures, voir métriques.
Représente la quantité de travail qu’un système Kanban peut contenir tout en assurant un flux de travail efficace. Également utilisée pour l’affectation à une activité particulière, à un type d’élément de travail ou à une classe de service.

Carte

une carte représente une tâche à réaliser. Elle contient généralement le nom de la tâche, sa description, son responsable, sa priorité et son estimation de durée. Une carte peut aussi comporter des informations complémentaires, comme des commentaires, des pièces jointes ou des indicateurs de qualité. Une carte se déplace sur le tableau Kanban au fur et à mesure de son avancement.

Classe de service

Un niveau de service spécifique appliqué au traitement d’un élément de travail établi par le biais d’un ensemble défini de politiques. Une classe de service peut s’appliquer à un ou plusieurs types d’éléments de travail. Une classe de service fixe souvent un niveau de service attendu. Le choix de la classe de service peut refléter une valeur relative, un risque ou un coût de retard. Les quatre archétypes courants de classe de service qui sont largement reconnus sont les suivants :
– Accélération
– Date fixe
– Intangible
– Standard

Colonne

une colonne représente une étape du processus de réalisation du projet. Par exemple, une colonne peut correspondre à « À faire », « En cours », « À vérifier » ou « Terminé ». Les colonnes peuvent être adaptées en fonction du contexte et du type de projet. Chaque colonne a une capacité maximale de cartes, qui correspond au WIP.

Coût du retard

Le taux auquel la valeur attendue d’un produit, d’une initiative ou d’un élément de travail diminue au fur et à mesure que sa livraison est retardée. Le coût du retard implique à la fois l’urgence et l’impact. Le coût du retard peut être utilisé pour éclairer les décisions liées au temps, y compris la commande d’éléments de travail pendant le réapprovisionnement ou l’attribution d’une classe de service.

Cycle time

le cycle time est le temps écoulé entre le moment où une carte entre dans la première colonne active du tableau Kanban et le moment où elle en sort. Il s’agit d’un indicateur qui mesure la durée effective du travail et la performance de l’équipe.

D

E

F

G

Goulot d’étranglement

Activité contrainte qui limite le flux et le taux de livraison possible de l’ensemble du flux de travail.

Graphique de contrôle

Un graphique, généralement un diagramme d’exécution, montrant les plages de contrôle en dehors desquelles un processus peut être considéré comme « hors contrôle » dans un sens spécifique.

H

I

J

K

L

Lead time

le lead time est le temps écoulé entre le moment où une carte entre dans le tableau Kanban et le moment où elle en sort. Il s’agit d’un indicateur qui mesure la durée totale du processus et la satisfaction des clients.

Ligne

une ligne représente un segment du projet, qui regroupe des cartes ayant une caractéristique commune. Par exemple, une ligne peut correspondre à un type de tâche, à un client, à un produit ou à une fonctionnalité. Les lignes permettent de catégoriser les cartes et de faciliter leur repérage sur le tableau.

M

N

O

P

Point d’engagement

Le point auquel la décision est prise de commencer les activités pour livrer un travail. Avant ce point, le travail effectué soutient la décision de livrer ou non l’élément de travail (voir en amont).

Principes de gestion du changement

La méthode Kanban aborde le changement évolutif selon les trois principes suivants :
– Commencez par ce que vous faites maintenant,
– Obtenir l’accord pour poursuivre l’amélioration par le biais d’un changement évolutif,
– Encourager les actes de leadership à tous les niveaux.

Pull

le pull est le principe selon lequel une carte ne peut être déplacée vers la colonne suivante que si celle-ci a de la place disponible. Il s’agit d’un mécanisme qui permet de réguler le flux de travail et d’éviter les engorgements. Le pull favorise la collaboration entre les membres de l’équipe et la satisfaction des clients.

Push

le push est le principe inverse du pull, selon lequel une carte est poussée vers la colonne suivante dès qu’elle est terminée, sans tenir compte de la capacité de la colonne. Il s’agit d’un mécanisme qui peut entraîner des problèmes de qualité, des retards ou des pertes de motivation. Le push est à éviter dans la méthode Kanban.

Q

R

S

Swimlane

une swimlane est une ligne horizontale qui traverse toutes les colonnes du tableau. Elle sert à séparer les cartes selon leur niveau de priorité ou leur dépendance. Par exemple, une swimlane peut correspondre à « Urgent », « Normal » ou « Bloqué ». Les swimlanes permettent de hiérarchiser les cartes et de gérer les risques.

T

U

V

W

WIP

le WIP (Work In Progress) est le nombre maximum de cartes que peut contenir une colonne à un moment donné. Il s’agit d’une contrainte volontaire qui vise à éviter la surcharge de travail et à favoriser la qualité. Le WIP doit être adapté en fonction de la capacité de l’équipe et du temps de cycle des tâches.

X

Y

Z

Comment devenir un(e) Coach Agile ?

18 mars 2024 / Claude BUENO / 0 Comments

Dans un cadre Agile, le (la) Coach Agile joue un rôle important pour aider les équipes à adopter une approche Agile et à améliorer continuellement leurs pratiques.

Pour devenir Coach Agile, il est important d’avoir une bonne compréhension des méthodologies agiles, ainsi que des compétences en communication, en leadership et en résolution de problèmes. Je vous présente, à travers cet article, les quelques étapes que vous pouvez suivre pour devenir Coach Agile.

7 étapes à suivre pour devenir un(e) Coach Agile

Pour devenir Coach Agile, voici quelques étapes que vous pouvez suivre :

Acquérir une solide expérience pratique en tant que membre d’une équipe agile. Travailler dans un environnement agile vous permettra de comprendre les principes et les pratiques de manière concrète.
Approfondir vos connaissances en matière de méthodologies et de cadres agiles tels que Scrum, Kanban, Lean, XP, etc. Vous pouvez suivre des formations certifiées ou obtenir des certifications reconnues dans ces domaines.
Développer vos compétences en communication et en facilitation. Être un bon Coach Agile implique de pouvoir guider et inspirer les équipes, de faciliter les réunions et les ateliers, et de favoriser la collaboration.
Renforcer votre compréhension des aspects humains et de la dynamique d’équipe. La gestion du changement, la résolution de conflits et le développement des compétences interpersonnelles sont des éléments clés pour aider les équipes à adopter l’agilité.
Rejoindre des communautés professionnelles liées à l’agilité. Assister à des conférences, participer à des événements et échanger avec d’autres praticiens agiles vous permettra de rester à jour et de bénéficier des connaissances partagées.
Considérez également l’obtention de certifications spécifiques au coaching agile, telles que Agile Coach Certified (ICP-ACC) ou Professional Scrum Trainer (PST). Ces certifications peuvent renforcer votre crédibilité en tant que coach agile.
Enfin, cherchez des opportunités pour mettre en pratique vos compétences de coaching agile, que ce soit en interne au sein de votre organisation ou en proposant vos services en tant que consultant externe. L’expérience pratique et les résultats concrets seront des atouts pour votre parcours professionnel.

N’oubliez pas que devenir un(e) bon(ne) Coach Agile nécessite du temps, de la pratique et un engagement continu pour développer vos compétences et rester à jour avec les évolutions du domaine.

Acquérir une solide expérience pratique au sein d’une équipe agile ?

Pour acquérir une solide expérience pratique en tant que membre d’une équipe agile, voici quelques conseils :

Rejoindre une équipe agile : Cherchez des opportunités au sein de votre organisation ou recherchez des entreprises qui utilisent des méthodologies agiles. Rejoindre une équipe existante vous permettra de vous immerger dans l’environnement agile et d’apprendre des praticiens expérimentés.
Participer activement : Impliquez-vous activement dans les activités de l’équipe agile. Assurez-vous de comprendre les rôles et les responsabilités de chaque membre de l’équipe, et contribuez de manière proactive aux différentes phases du cycle de développement agile, comme la planification, l’exécution et la rétrospective.
Apprendre en observant : Observez attentivement les pratiques agiles mises en œuvre par votre équipe et identifiez les raisons derrière ces pratiques. Comprenez les principes fondamentaux et les valeurs agiles qui les sous-tendent.
Collaborer étroitement avec les autres membres de l’équipe : Le travail d’équipe et la collaboration sont essentiels dans un environnement agile. Participez activement aux réunions, aux ateliers et aux cérémonies agiles, et cherchez à contribuer de manière significative aux discussions et aux décisions prises en équipe.
Prendre des responsabilités supplémentaires : Si possible, cherchez à prendre des responsabilités supplémentaires au sein de l’équipe. Cela peut inclure des tâches telles que la coordination des activités, l’animation de réunions ou la documentation des pratiques et des processus agiles.
Se former : Recherchez des formations et des ressources en ligne pour approfondir vos connaissances en agilité. Les certifications telles que Scrum Master ou Product Owner peuvent également vous aider à développer votre compréhension des rôles et des responsabilités dans une équipe agile.
Solliciter des retours d’expérience : N’hésitez pas à solliciter les retours d’expérience des membres plus expérimentés de votre équipe ou de coaches agiles. Ils pourront vous fournir des conseils précieux et vous aider à améliorer continuellement vos compétences.

Il est important de garder à l’esprit que l’expérience pratique se construit progressivement. Soyez patient, faites preuve de curiosité et d’ouverture d’esprit, et cherchez constamment à vous améliorer dans votre rôle au sein de l’équipe agile.

Scrum master, Product owner et Coach agile, quels sont leurs rôles et missions ?

18 mars 2024 / Claude BUENO / 0 Comments

Quels sont les rôles et activités d’un Coach agile dans un cadre agile ?

Dans un cadre Agile, le Coach Agile joue un rôle important pour aider les équipes à adopter une approche Agile et à améliorer continuellement leurs pratiques. Voici quelques-uns des rôles et activités d’un Coach Agile dans un cadre Agile :

Faciliter la planification et l’exécution des projets : Le Coach Agile aide les équipes à planifier leur travail, à définir les objectifs et les résultats attendus, et à suivre l’avancement du projet.
Encourager la collaboration et la communication : Le Coach Agile aide les équipes à travailler ensemble de manière efficace, à communiquer de manière transparente et à résoudre les conflits de manière constructive.
Favoriser la transparence : Le Coach Agile encourage les équipes à partager leur travail et leur progression de manière transparente pour favoriser la confiance et la collaboration.
Enseigner et soutenir les pratiques Agile : Le Coach Agile enseigne aux équipes les pratiques Agile telles que la planification de sprint, la gestion de backlog, la revue de sprint, la rétrospective de sprint, etc., et aide les équipes à les mettre en œuvre de manière efficace.
Encourager la réflexion et l’amélioration continue : Le Coach Agile aide les équipes à réfléchir sur leur travail et à identifier des moyens d’améliorer leurs pratiques, leurs processus et leurs résultats.
Conseiller sur les décisions stratégiques : Le Coach Agile peut aider les dirigeants à comprendre les avantages de l’Agilité pour leur entreprise et les aider à prendre des décisions stratégiques pour l’adoption de l’Agilité.
Faciliter la résolution de problèmes : Le Coach Agile aide les équipes à identifier les obstacles et à trouver des solutions pour les surmonter.

En résumé, le rôle du Coach Agile dans un cadre Agile est de faciliter l’adoption de l’approche Agile et d’aider les équipes à améliorer continuellement leurs pratiques pour obtenir de meilleurs résultats. Le Coach Agile est un facilitateur, un enseignant et un conseiller pour les équipes et l’organisation dans son ensemble.

Quelle différence entre Scrum master et Coach agile ?

Bien que le Scrum Master et le Coach Agile partagent certains aspects de leur travail, ils ont des rôles et des responsabilités différents dans un environnement Agile.

Le Scrum Master est responsable de veiller à ce que l’équipe Scrum suive les principes et les valeurs agiles, ainsi que les pratiques Scrum. Le Scrum Master aide l’équipe à comprendre les objectifs de la Sprint, à gérer le backlog de produit et à organiser les réunions Scrum (daily scrum, sprint review, sprint retrospective, etc.). Il s’assure également que l’équipe reste concentrée sur les objectifs de la Sprint, en éliminant les obstacles qui pourraient entraver la progression de l’équipe.

Le Coach Agile, quant à lui, travaille avec l’ensemble de l’organisation pour aider à mettre en œuvre une transformation agile réussie. Il est responsable de la mise en place d’une culture agile dans toute l’organisation et aide à aligner les équipes sur les objectifs globaux de l’entreprise. Le Coach Agile travaille avec les équipes pour aider à améliorer les pratiques agiles, à résoudre les problèmes et à atteindre des niveaux de performance supérieurs.

En résumé, le Scrum Master est responsable de la mise en œuvre des pratiques Scrum pour une équipe Scrum spécifique, tandis que le Coach Agile travaille à l’échelle de l’organisation pour aider à mettre en place une culture agile et pour aider les équipes à améliorer leurs pratiques.

Quelle différence entre Product Owner et Coach agile ?

Le Product Owner et le Coach Agile ont des rôles et des responsabilités très différents dans un environnement Agile.

Le Product Owner est responsable de la définition des fonctionnalités et des priorités du produit. Il est chargé de la gestion du backlog de produit, de la planification des sprints, et de travailler avec l’équipe Scrum pour s’assurer que les fonctionnalités les plus importantes sont développées en premier. Le Product Owner travaille en étroite collaboration avec les parties prenantes, notamment les utilisateurs, les clients et les membres de l’équipe pour s’assurer que les besoins du produit sont compris et respectés.

Le Coach Agile, quant à lui, travaille avec l’ensemble de l’organisation pour aider à mettre en œuvre une transformation agile réussie. Il est responsable de la mise en place d’une culture agile dans toute l’organisation et aide à aligner les équipes sur les objectifs globaux de l’entreprise. Le Coach Agile travaille avec les équipes pour aider à améliorer les pratiques agiles, à résoudre les problèmes et à atteindre des niveaux de performance supérieurs.

En résumé, le Product Owner est responsable de la définition des fonctionnalités et des priorités du produit, tandis que le Coach Agile travaille à l’échelle de l’organisation pour aider à mettre en place une culture agile et pour aider les équipes à améliorer leurs pratiques. Les deux rôles sont donc très différents, mais travaillent ensemble pour assurer le succès du produit et de l’organisation dans son ensemble

Doit-on avoir une expérience de Scrum master pour devenir Coach agile ?

Il n’est pas obligatoire d’avoir une expérience en tant que Scrum Master pour devenir Coach Agile, bien que cela puisse être utile.

Le rôle de Coach Agile est un rôle plus large et plus stratégique que celui de Scrum Master. Il implique de travailler avec l’ensemble de l’organisation pour aider à mettre en place une culture agile réussie. Bien que l’expérience en tant que Scrum Master puisse aider à comprendre certains aspects des pratiques agiles, elle ne suffit pas à elle seule pour devenir un bon Coach Agile.

Un Coach Agile doit posséder des compétences en leadership, en communication, en résolution de problèmes, en coaching et en formation. Il doit également avoir une compréhension approfondie des principes et des valeurs agiles, ainsi que des pratiques agiles telles que Scrum, Kanban, XP, etc.

Par conséquent, il est possible de devenir Coach Agile sans avoir une expérience de Scrum Master, mais il est important d’avoir une solide expérience en gestion de projet et en coaching, ainsi que de se former et de se perfectionner constamment dans le domaine de l’agilité.

unFIX : 8 raisons clés d’adopter ce modèle agile

9 décembre 2023 / Claude BUENO / 0 Comments

Le principe unFIX est une approche novatrice de l’organisation d’équipe pour le développement de produits, qui vise à favoriser la flexibilité, la créativité et l’efficacité au sein des équipes de travail. Cette approche repose sur le concept de « défixation », c’est-à-dire la remise en question constante des structures et des méthodes traditionnelles pour permettre aux équipes de s’adapter rapidement aux changements et de créer des produits de haute qualité.

Le modèle unFIX est une boîte à outils simple qui vous aide à concevoir une organisation polyvalente. Il facilite le changement progressif, les équipes dynamiques et les managers ont un rôle important à jouer. Notre bibliothèque de modèles s’inspire d’entreprises innovantes telles que Haier et Tesla, de divers cadres de travail agiles et d’ouvrages tels que Team Topologies, Dynamic Reteaming et Organization Design.
— Jurgen Appelo, founder unFIX company

unFIX repose sur plusieurs piliers fondamentaux :

Flexibilité organisationnelle : Contrairement aux structures hiérarchiques traditionnelles, unFIX favorise une organisation horizontale, où les membres de l’équipe ont plus d’autonomie et de responsabilité. Les rôles et les responsabilités ne sont pas figés, et les équipes peuvent se réorganiser en fonction des besoins du projet.
Collaboration interdisciplinaire : unFIX encourage la collaboration entre des experts de différentes disciplines. Les équipes sont composées de personnes ayant des compétences variées, ce qui favorise l’innovation et la diversité des idées.
Cycle de développement itératif : Au lieu de suivre un processus linéaire strict, unFIX privilégie un cycle de développement itératif. Les équipes travaillent en petites étapes, recueillent des retours d’information fréquents et ajustent constamment leur approche.
Priorisation des besoins des utilisateurs : unFIX met l’accent sur la compréhension approfondie des besoins des utilisateurs. Les équipes sont encouragées à impliquer les utilisateurs tout au long du processus de développement pour créer des produits qui répondent véritablement à leurs attentes.
Communication ouverte et transparente : La communication est essentielle dans unFIX. Les équipes partagent constamment des informations, des idées et des retours d’information. Cela favorise un environnement de travail ouvert et collaboratif.
Apprentissage continu : unFIX reconnaît que l’apprentissage est un processus continu. Les équipes sont encouragées à tirer des leçons de chaque itération du produit et à s’améliorer constamment.
Adaptabilité face au changement : Les équipes unFIX sont prêtes à s’adapter rapidement aux changements, que ce soient des évolutions du marché, des besoins des utilisateurs ou des nouvelles technologies. Cette capacité à pivoter est l’un des atouts majeurs de l’approche unFIX.
Valeurs humaines : unFIX met en avant les valeurs humaines dans le travail d’équipe. Il encourage la confiance, le respect, l’empathie et l’inclusion au sein des équipes.

En mettant en pratique ces principes, les équipes unFIX sont en mesure de créer des produits innovants, de haute qualité et adaptés aux besoins du marché. Cette approche favorise également l’engagement des membres de l’équipe, en leur donnant un plus grand sentiment de responsabilité et d’autonomie dans leur travail.

Il est important de noter que unFIX n’est pas une approche rigide, mais plutôt une philosophie qui peut être adaptée en fonction des besoins spécifiques de chaque projet et de chaque organisation. Elle s’inscrit dans la lignée des méthodologies agiles, mais va encore plus loin en promouvant une remise en question constante des méthodes et des structures pour rester en phase avec un monde en constante évolution.

User Story dans Agile Scrum

7 décembre 2022 / Claude BUENO / 0 Comments

Dans cet article, je vous propose d’apprendre ce qu’est une User Story et comment en écrire une. La User Story joue un rôle majeur dans la pratique agile Scrum. C’est la partie du processus Agile où, au lieu d’écrire des exigences complètes, nous écrivons une courte description d’une fonctionnalité.

Comme le dit le Manifeste Agile, « un logiciel fonctionnel » plutôt que des « documents complets ».

Qu’est-ce qu’une User Story ?

Une User Story est une description courte et simple de la fonctionnalité ou des exigences du projet. Généralement, les Users Stories sont écrites sur des notes autocollantes ou des cartes d’index comme une perspective basée sur l’utilisateur ou le rôle.

Modèle de User Story

En tant que < type d’utilisateur ou de rôle >, je veux < un objectif > pour que < une raison >.

Le modèle identifie 3 questions – « Qui », « Quoi », et « Pourquoi ».

Si l’équipe ne connaît pas ces trois réponses, cela signifie qu’elle ne comprend pas l’histoire, et si elle ne comprend pas l’histoire, alors il est difficile de bien la scinder.

Modèle de User Story

Dans la carte ci-dessus, vous pouvez voir le format. Chaque histoire a un identifiant d’histoire, un titre d’histoire, un format, des critères d’acceptation, une priorité et des points d’estimation pour accomplir la tâche.

Les 3 C de l’histoire

Carte – Les histoires d’utilisateur sont écrites sur la carte, ayant juste assez de description de l’exigence.
Conversation – Les histoires doivent être conversationnelles, c’est-à-dire une conversation collaborative facilitée par le Product Owner avec l’équipe. Il s’agit d’une conversation en personne.
Confirmation (critères d’acceptation) – Les critères d’acceptation sont utilisés pour déterminer quand la user story a atteint l’objectif de l’utilisateur.

Une bonne user story utilise le modèle « INVEST« .

Indépendante – Dépendances réduites, donc plus facile à planifier.
Négociable – Effort de collaboration pour l’élaboration des détails
Valable – Apporte de la valeur au client et à l’entreprise.
Estimable – Assez petite et bien divisée pour que l’équipe puisse l’estimer.
Suffisamment petit – Peut être réalisé en moins d’une semaine par l’équipe.
Testable – Bons critères d’acceptation

Exemple de User Story

En tant qu’utilisateur, je veux pouvoir saisir mes informations personnelles pour l’inscription, afin de pouvoir m’inscrire et parcourir le tableau de bord de mon application web.

Critères d’acceptation

L’utilisateur doit saisir les données des champs obligatoires, identifiés par *(astérisques).
L’utilisateur doit saisir une adresse électronique et un numéro de téléphone portable valides.
Si l’utilisateur clique sur « Enregistrer », les données doivent être sauvegardées dans les tableaux avec un message de réussite.
Si l’utilisateur clique sur « Réinitialiser », les données qu’il a saisies sont actualisées et les champs sont effacés.

Résumé

Les user stories ne sont pas des documents de haut niveau car, en développement agile, la documentation n’est pas obligatoire. Une user story est un effort collaboratif dont l’intention est de favoriser la collaboration.

Merci de votre lecture.

N’hésitez pas à commenter ci-dessous j’aime vous aider. Si vous avez une suggestion de nouvel article ou tutoriel alors exprimez-vous en commentant.

N’oubliez pas de partager ce tutoriel avec vos amis sur Facebook et Twitter.

Comment réussir la certification Professional Scrum Master ?

17 septembre 2022 / Claude BUENO / 1 Comment

La certification Professional Scrum Master de Scrum.org offre une excellente occasion de valider vos connaissances de Scrum et d’améliorer votre trajectoire de carrière personnelle.

Scrum est un cadre Agile populaire pour la gestion des projets de développement de logiciels. L’acquisition de la certification de Scrum Master professionnel vous aidera à mettre en œuvre et à exécuter des méthodologies agiles réussies dans toute l’organisation.

Cet article détaille les choses à faire et à ne pas faire pour passer votre examen PSM afin de vous assurer que vous êtes bien préparé pour réussir votre examen de certification PSM dès votre premier essai.

Introduction à la certification PSM

La certification Professional Scrum Master (PSM) a été créée par Scrum.org pour valider la capacité d’une personne à encadrer et guider des équipes dans l’utilisation des cadres, des méthodologies et des pratiques Scrum.

La certification de Professional Scrum Master (PSM) est un choix populaire pour ceux qui cherchent à valider leurs connaissances de Scrum. La certification PSM I est destinée aux personnes ayant 1 à 2 ans d’expérience, tandis que la certification PSM II est destinée aux personnes ayant plus de 2 ans d’expérience.

Pour réussir la certification PSM, vous devez être en mesure de démontrer une compréhension approfondie du cadre Scrum et la capacité à l’appliquer dans un contexte réel.

Le certificat PSM a été conçu pour reconnaître le titre d’un Scrum Master individuel qui a non seulement appliqué le cadre Scrum mais qui peut également amener d’autres Scrum Masters à faire de même.

Cette certification garantit que son détenteur possède les connaissances, les compétences et les aptitudes nécessaires pour guider avec succès une équipe qui utilise le cadre Scrum. Elle ne garantit certainement pas qu’une personne puisse encadrer et guider toutes les équipes, mais elle est conçue pour ceux qui ont le désir d’apprendre et de maîtriser les méthodologies Scrum.

Mais avant de vous faire de grands espoirs, il y a beaucoup de choses à savoir sur cette certification.

Conseils pour réussir l’examen de certification PSM

Il y a plusieurs choses que vous pouvez faire pour augmenter vos chances de réussir l’examen de certification PSM.

Commencez par obtenir une copie du programme de l’examen. Cela vous donnera une vue d’ensemble des sujets qui seront abordés dans l’examen.
Une fois que vous êtes familiarisé avec l’ensemble de la matière, vous devez passer en revue les objectifs de certification. Cela comprend toute information détaillée sur l’examen et ce que vous devez savoir, ainsi que toute personne déjà certifiée qui peut vous donner des conseils.
Ensuite, établissez un programme d’étude et respectez-le. Consacrez quelques heures par semaine à l’étude de l’examen.
En plus d’étudier la matière de l’examen, familiarisez-vous avec le format de l’examen. Assurez-vous de comprendre la structure de l’examen et le type de questions qui vous seront posées.
Enfin, n’oubliez pas de passer des examens blancs. Cela vous aidera à vous faire une idée de l’examen réel.

Sur votre chemin vers la certification PSM, vous rencontrerez de nombreux obstacles. Pour vous aider à atteindre la ligne d’arrivée, voici une liste des choses à faire et à ne pas faire dans le processus de certification.

À faire : Familiarisez-vous avec le Guide Scrum. Il s’agit de la ressource la plus importante pour l’examen.
À faire : Comprendre les concepts d’auto-organisation, de transparence et de collaboration.
À faire : S’entraîner avec des exemples de questions. Vous pouvez les trouver en ligne ou dans des guides d’étude.
À ne pas faire : essayer de tout mémoriser. L’objectif est de comprendre les concepts et non de mémoriser des faits.
Ne le faites pas : Ne vous découragez pas si vous ne réussissez pas du premier coup. Vous pouvez toujours repasser l’examen.

Si vous suivez ces conseils, vous devriez être sur la bonne voie pour réussir l’examen de certification PSM

Le modèle d’examen PSM et les prérequis

La certification Professional Scrum Master (PSM) est un titre reconnu mondialement qui dénote un haut niveau d’expertise dans le cadre de Scrum.

La certification est offerte par Scrum.org, l’organisation qui a créé et maintient le cadre de Scrum. Pour obtenir le titre de PSM, les candidats doivent passer un examen rigoureux qui teste leurs connaissances et leur compréhension de Scrum.

L’examen PSM est composé de questions à choix multiples et de questions à développement. Les questions à choix multiples testent les connaissances des candidats sur les principes et les pratiques de Scrum, tandis que les questions à développement évaluent leur capacité à appliquer les concepts de Scrum à des situations réelles. Les candidats disposent de deux heures pour passer l’examen, et ils doivent obtenir un score de 85 % ou plus pour réussir.

La certification PSM est une certification de haute qualité qui vous permet de savoir que la personne certifiée qui a suivi la formation est effectivement capable d’agir de manière responsable.

Elle est valable deux ans, de sorte que la personne certifiée peut utiliser cette période pour prouver ses connaissances et ses compétences à son employeur. Si le candidat n’est pas en mesure de le faire avec succès, la certification sera révoquée.

Facteurs importants à prendre en compte pour la certification PSM

Avant l’examen

Avant de commencer à étudier pour votre certification PSM, il y a quelques choses que vous devriez faire pour vous préparer à la réussite.

Jetez un coup d’œil au Guide Scrum pour rafraîchir votre compréhension du cadre de travail.
Passez en revue les objectifs d’apprentissage de l’examen de certification pour vous assurer que vous êtes sur la bonne voie.
Trouvez un groupe d’étude ou une communauté en ligne pour vous aider dans votre apprentissage.

Pendant l’examen

Il peut être difficile de rester calme pendant l’examen de certification PSM. Il s’agit d’un test rigoureux qui nécessite toute votre concentration pour le réussir. Cependant, il existe plusieurs moyens de calmer vos nerfs et de rester concentré.

La première étape, la plus importante, consiste à comprendre ce qui vous est demandé. Lisez attentivement la question et assurez-vous de bien comprendre ce qui vous est demandé avant d’essayer d’y répondre.
Lorsque vous répondez à une question, prenez votre temps et réfléchissez à votre réponse avant de choisir la meilleure option.
N’essayez pas d’être plus malin que l’examen en devinant les réponses. Si vous ne connaissez pas une réponse, il est préférable de la laisser en blanc plutôt que de la deviner.
Soyez honnête avec vous-même quant à votre niveau de connaissances et n’essayez pas de faire semblant de réussir l’examen.
Étudiez sérieusement et assurez-vous de bien comprendre la matière avant de passer l’examen. Mieux vous serez préparé, plus vous aurez de chances de réussir.

Après l’examen

Maintenant que vous avez obtenu votre certification PSM, il est temps de célébrer. Mais avant de le faire, vous devez garder à l’esprit certaines choses.

Tout d’abord, vous devez établir un calendrier et planifier votre prochaine étape.
Même s’il peut être tentant de se reposer un peu sur ses lauriers, il est sage de continuer à utiliser les connaissances que vous venez d’acquérir.
Vous pouvez continuer à travailler pour obtenir d’autres certifications, développer votre entreprise, etc.

Il est également judicieux de rechercher votre prochaine certification. Avoir une certification PSM, c’est bien, mais il est peut-être préférable de poursuivre votre formation avec d’autres certifications.

Résumé

La certification Professional Scrum Master (PSM) est une étape importante pour les praticiens de Scrum. Elle démontre votre capacité à appliquer Scrum dans un contexte réel et votre engagement envers la profession.

Pour réussir l’examen de certification PSM, vous devez bien connaître le cadre de Scrum et avoir une compréhension approfondie des principes et des pratiques de Scrum.

Les rôles et responsabilités du SAFe® Agilist

15 septembre 2022 / Claude BUENO / 0 Comments

Devenez acteur de l’agilité à l’échelle en entreprise grâce au rôle de SAFe® Agilist. Découvrez le guide des missions et responsabilités du SAFe® Agilist.

Les grandes organisations doivent relever le défi de répondre au changement avec rapidité et une relative facilité.

Qu’il s’agisse du suivi et du contrôle, de la collaboration, de l’intégration des parties prenantes, de la gestion du changement et des méthodes de gouvernance, les problèmes ne font qu’augmenter.
Qu’il s’agisse de l’incapacité à gérer les dépendances entre les équipes, de la gestion de sources multiples d’exigences, de l’alignement entre les équipes techniques et commerciales, de la livraison d’un incrément ou de l’augmentation de la valeur ajoutée, les défis sont innombrables.

Mais existe-t-il une solution ?

C’est vers 2011 que Dean Leffingwell a décidé de conceptualiser le Scaled Agile Framework. SAFe®, une base de connaissances constituée de principes, de pratiques et de compétences éprouvés et intégrés pour atteindre l’agilité de l’entreprise en utilisant Lean, Agile, Systems Thinking et DevOps.

Les entreprises peuvent adopter SAFe® si elles souhaitent concentrer leurs efforts sur la mise à l’échelle de l’agilité au niveau de l’entreprise, en positionnant les objectifs commerciaux et techniques de l’organisation. Il ne suffit pas que les équipes informatiques et logicielles travaillent de manière agile.

Vous avez besoin d’agilité commerciale lorsque l’ensemble de l’organisation utilise les pratiques agiles et Lean pour fournir continuellement des solutions commerciales innovantes plus rapidement que la concurrence.

La mise à l’échelle agile permet également d’utiliser efficacement les compétences des employés, de planifier les livraisons dans les délais et d’améliorer la qualité des solutions. SAFe® est un cadre qui permet non seulement d’aligner l’équipe et le niveau du programme, mais aussi de rester en phase avec la stratégie de l’organisation.

En fin de compte, toutes les organisations veulent se concentrer sur la productivité, la qualité, les délais de commercialisation et l’engagement des employés. Mais cela soulève la question suivante : en tant qu’individu, en quoi SAFe® vous est-il utile ?

37% des organisations ont déclaré utiliser SAFe®. Cette pratique ne peut que connaître une tendance à la hausse. Cela signifie des tonnes d’opportunités pour les professionnels certifiés SAFe®.

Le rôle de premier niveau dans SAFe® est celui de SAFe® Agilist mais quels sont ses rôles et responsabilités.

Qu’est-ce qu’un SAFe® Agilist ?

Un SAFe® Agilist est la personne responsable de la transformation Lean-Agile. Il met en œuvre les principes de base du cadre SAFe® à l’étape primaire du développement du produit.

Un SAFe® Agilist applique les principes Lean, Agile et le flux de développement de produits pour améliorer la productivité, la satisfaction des employés, les délais de commercialisation et la qualité.

Pourquoi un SAFe® Agilist ?

Un SAFe® Agilist a une connaissance approfondie de ce qui est nécessaire pour réorganiser votre processus actuel de développement de produits agiles et atteindre l’agilité commerciale dans l’organisation.

Il possède les compétences nécessaires pour transformer la gestion de portefeuille agile en une organisation productive qui produit une valeur sans faille pour les parties prenantes et les clients dans les délais de commercialisation les plus courts possibles.

Rôle et responsabilités du SAFe® Agilist

Le SAFe® Agilist est un guide qui aide l’organisation et l’équipe à progresser vers l’agilité métier et à mettre en œuvre, adapter et développer continuellement SAFe® dans une entreprise.

Il est ouvert à l’innovation et aide l’équipe à définir les objectifs et les perceptions pour communiquer clairement la vision stratégique. Ils expérimentent et transmettent l’importance de l’innovation aux parties prenantes et aux équipes.

Le SAFe® Agilist joue le rôle de mentor en aidant les membres de leur équipe à progresser dans leur carrière en développant leur expertise. Ils les encouragent à sortir de leur zone de confort et à fournir des résultats conformes aux objectifs, à la vision et à la mission de l’entreprise.

Parlons maintenant du rôle technique et des responsabilités d’un SAFe® Agilist.

1. Planification et exécution de l’incrément de programme.

Un SAFe® Agilist a un plan à long terme basé sur une vision pour réorganiser le processus de développement agile.

Il planifie et met en œuvre des valeurs incrémentales par le biais de la gestion de programme.

2. Planification et exécution des Agile Release Trains

Les Agile Release Trains sont des équipes chargées d’atteindre un objectif technique et commercial commun.

Chaque ART est une équipe composée de 50 à 125 personnes multifonctionnelles qui s’engagent, planifient et exécutent à l’unisson.

Un SAFe® Agilist veille à ce que la planification et la mise en œuvre par le biais des ART soient effectuées de manière appropriée et que le processus de flux de travail soit organisé.

Il promeut les principes des ARTs tels que la fixation des calendriers, l’incrémentation opportune des systèmes, l’application de la synchronisation, l’adoption de l’état d’esprit Agile et des valeurs fondamentales de SAFe®, la planification en face à face, l’innovation et la planification par inspection et adaptation.

3. Vision et mise en œuvre des principes Lean-Agile

Adopter une vision économique
Appliquer la pensée systémique
Assumer la variabilité, préserver les options
Construire de manière incrémentielle avec des cycles d’apprentissage rapides et intégrés.
Baser les jalons sur l’évaluation objective des systèmes en fonctionnement.
Visualisez et limitez l’encours, réduisez la taille des lots et gérez la hauteur des files d’attente.
Appliquez la cadence, synchronisez avec la planification inter-domaines.
Déverrouiller la motivation intrinsèque des travailleurs du savoir
Décentraliser la prise de décision
Organiser autour de la valeur

La mise en œuvre des principes Lean-Agile dans le cadre et le flux de travail SAFe® est la principale responsabilité d’un SAFe® Agilist. Travailler avec les principes agiles lean aide le SAFe® Agilist à construire la gestion de portefeuille agile avec une budgétisation lean.

4. Flux efficace et optimisé des solutions Kanban

Kanban est un cadre privilégié pour la mise en œuvre du développement logiciel Agile et DevOps.

Il exige une communication en temps réel de la capacité et une transparence totale du travail. Les éléments de travail sont écrits sur le tableau, ce qui permet aux membres de l’équipe d’être au courant de l’avancement des travaux.
Le SAFe® Agilist est responsable de la fluidité des solutions Kanban. Tout en suivant les solutions Kanban, le SAFe® Agilist veille à ce que le flux de travail soit tracé et à ce que tout obstacle soit éliminé.

5. Développer une approche collaborative, inter-fonctionnelle et de soutien

Une collaboration sans faille est la clé de la croissance et du progrès de toute entreprise.
Le SAFe® Agilist dirige l’équipe en tant qu’expert du cadre Agile.

Les équipes SAFe® Agile sont motivées lorsqu’elles partagent une vision commune avec une approche collaborative.

Comment obtenir la certification SAFe® Agilist ?

La première étape consiste à s’inscrire à la formation Leading SAFe® où vous apprendrez les compétences nécessaires pour mener la transformation agile dans votre organisation en utilisant SAFe® et ses principes fondamentaux de pensée allégée et de flux de développement de produits.

Cette formation de 2 jours couvre les points suivants

Comment construire des équipes performantes et créer une agilité technique
Regrouper les équipes et regrouper les équipes autour de la valeur du flux
Développer des compétences pour soutenir et exécuter des événements de planification PI et coordonner de nombreux Agile Release Trains (ARTs)
Importance de l’adoption de l’état d’esprit « client d’abord » et de l’approche « design thinking » pour la livraison de produits agiles.
La formation vous aidera à apprendre l’art de l’agilité commerciale afin que vous puissiez développer un avantage concurrentiel sur le marché.

Quel est le profil cible au rôle de SAFe Agilist ?

Le public cible de la certification Leading SAFe® 5.1 est composé des personnes suivantes

PDG, DSI
Gestionnaire de portefeuille, gestionnaire de programme ou de projet
Architecte de solutions ou de systèmes
Ingénieur de formation à la mise en production, Scrum Master
Coach agile, consultant, agent de changement
Chef d’équipe, ingénieur, analyste commercial

Critère d’éligilité pour devenir SAFe® Agilist ?

Le cours SAFe® agilist n’a pas de prérequis mais l’expérience suivante serait bénéfique :

5+ ans d’expérience dans le développement de logiciels, les tests, l’analyse d’affaires, la gestion de produits ou de projets.
Expérience de Scrum

Lecture recommandée : Conseils pour réussir votre examen SAFe® Agilist

Conclusion

SAFe® est en train de devenir rapidement le cadre de travail préféré des organisations à grande échelle. Avec des avantages tels qu’une mise sur le marché plus rapide, des améliorations de la qualité, une augmentation de la productivité, un engagement renouvelé des employés, SAFe® se développe à pas de géant.

Si faire partie d’une transformation agile vous passionne, alors vous réussirez certainement en tant que SAFe® Agilist.