Ce site utilise des cookies à des fins d’analyse et pour améliorer votre expérience. En cliquant sur Accepter, vous consentez à notre utilisation des cookies. En savoir plus dans notre politique de confidentialité.

Auteur/autrice : Claude BUENO

J’aide les équipes à développer leurs pratiques agiles et collaboratives.
Je blogue depuis 2008 sur la transformation numérique, le développement d'applications web et mobile et les pratiques pour les réaliser dans les meilleures conditions.
Sujets de prédilection : agilité, coaching, digital, management, marketing, développement web et mobile

abstraction

Qu’est une abstraction en développement ?

10 décembre 2024 / / 0 Comments

En développement, l’abstraction est un concept clé qui consiste à cacher les détails complexes d’une implémentation tout en exposant uniquement les informations essentielles ou pertinentes. Elle permet de simplifier le travail des développeurs en leur offrant une interface ou un modèle compréhensible sans qu’ils aient besoin de connaître les détails internes du fonctionnement.

Principes de l’abstraction

Cacher les détails complexes

L’abstraction masque la complexité des systèmes sous-jacents pour ne présenter qu’une vue simplifiée.
Exemple : Lorsque vous utilisez une voiture, vous interagissez avec le volant et les pédales, sans avoir besoin de comprendre le fonctionnement interne du moteur.

Mettre en avant l’essentiel

Seuls les aspects pertinents pour l’utilisateur ou le développeur sont exposés. Cela réduit la confusion et améliore l’efficacité.
Exemple : Une méthode en Java comme ArrayList.add(element) cache comment les éléments sont stockés dans le tableau sous-jacent.

Exemples en programmation

1. Abstraction via les classes et méthodes

Dans les langages orientés objet (comme Java), l’abstraction est souvent implémentée avec :

Classes abstraites
Interfaces
Exemple 1 : Classe abstraite
Une classe abstraite définit une structure générale tout en laissant les détails à ses sous-classes.

abstract class Animal {
    abstract void makeSound(); // Méthode abstraite (pas de détail ici)

    void sleep() { // Méthode concrète (avec détail)
        System.out.println("Sleeping...");
    }
}

class Dog extends Animal {
    @Override
    void makeSound() {
        System.out.println("Woof! Woof!");
    }
}

Animal est une abstraction : elle ne décrit pas précisément comment chaque animal produit un son.
Dog fournit les détails spécifiques (Woof! Woof!).

Exemple 2 : Interface
Une interface expose uniquement les comportements nécessaires, sans spécifier comment ils sont implémentés.

interface Vehicle {
    void start();
    void stop();
}

class Car implements Vehicle {
    @Override
    public void start() {
        System.out.println("Car is starting...");
    }

    @Override
    public void stop() {
        System.out.println("Car is stopping...");
    }
}

Interface Vehicle définit l’abstraction d’un véhicule.
Car implémente les détails spécifiques au fonctionnement d’une voiture.

2. Abstraction dans les bibliothèques

Quand vous utilisez une bibliothèque ou une API, vous bénéficiez d’une abstraction.

Exemple avec java.util.ArrayList :
Vous appelez des méthodes comme add() ou get() sans savoir comment les données sont stockées ou organisées (détails masqués).

Avantages de l’abstraction

Simplification :

Les utilisateurs et les développeurs peuvent se concentrer sur l’essentiel sans s’encombrer des détails complexes.

Maintenance facile :

Si l’implémentation interne change, tant que l’interface reste la même, les autres parties du code ne sont pas affectées.

Réutilisabilité :

L’abstraction permet de concevoir des modules ou des composants réutilisables dans différents contextes.

Flexibilité :

Les comportements ou implémentations spécifiques peuvent être modifiés sans impact sur le reste du système.

Exemple dans le quotidien

Imaginez une machine à café :
– L’utilisateur n’a besoin que d’appuyer sur des boutons pour préparer un café (abstraction).
– Les détails du fonctionnement interne (chauffage de l’eau, mélange, pression) sont masqués.

En résumé, l’abstraction est une manière de masquer les détails complexes pour exposer une vue simplifiée et utile, ce qui permet de développer des systèmes robustes, réutilisables et maintenables.

850x567 claudebueno coaching

Les bases de la gestion de projet – Méthode en cascade

12 juillet 2024 /

Je vous propose de démarrer une série de billets sur les bases de la gestion de projet. On va débuter tranquillement avec la méthode que l’on rencontre le plus souvent : la méthode en cascade. Puis par la suite je ferai un focus sur les missions du Chef de projet.

Méthodologie en cascade

Etape par étape, sans retour en arrière.

Etapes :

  • Initialisation
  • Lancement
  • Conception
  • Production
  • Exploitation et maintenance

Initialisation

Vérifier la faisabilité du projet (cadrer / estimer).
Outil : la note de cadrage, c’est un document de synthèse qui pose les objectifs du projet. Elle permet :

  • de reformuler le besoin ;
  • d’identifier les risques techniques, externes ou juridiques

La note de cadrage doit être validée par le client.

Lancement

Le lancement permet de clarifier et approfondir le besoin, d’élaborer les documents et d’attribuer les tâches aux acteurs du projet.

Clarifier et approfondir le besoin

  • Quel(s) cible(s) ?
  • Quelles pratiques du client (va-t-elle s’adapter au produit à fournir ?)
  • Quel contenu ?

Définir et lister toutes les fonctionnalités à faire valider par le client.
Démarrer la production -> estimation du temps par tous les interlocuteurs.
Le Chef de projet constitue le Cahier des charges qui contient :

  • La Note de cadrage ;
  • La liste des fonctionnalités ;
  • Le planning et attribution des tâches.

Conception : formaliser le produit

Définir et organiser les contenus

  • Arborescence ;
  • Charte éditoriale (titre et libellés des catégories) ;
  • Plan de référencement (mots clefs) ;
  • Charte graphique et ergonomique ;
  • Wireframes ;
  • Maquette travaillée par le graphiste ;
  • Fonctionnalités du point de vue du visiteur ;
  • Spécifications techniques.

Production

Le Chef de projet vérifie que le développement correspond au Cahier des charges. Il teste chaque fonctionnalité suivant le Cahier de test.
Le Chef de projet rédige le Cahier de recette à présenter au client pour validation.
Le PV de recette à faire signer au client :

  • avant la mise en ligne ;
  • après la mise en ligne.

Exploitation et Maintenance

Maintenance évolutive (lots supplémentaires)
Maintenance corrective (garantie)

GDevelop

GDevelop : La révolution du développement de jeux vidéo No-Code

28 juin 2024 / / 0 Comments

Le développement de jeux vidéo est un domaine qui a longtemps été perçu comme complexe et inaccessible aux non-initiés. Cependant, avec l’avènement des plateformes de développement no-code, cette perception change radicalement. GDevelop se distingue comme une solution no-code open-source qui démocratise la création de jeux vidéo, permettant à quiconque de donner vie à ses idées sans écrire une seule ligne de code.

Qu’est-ce que GDevelop ?

GDevelop est un moteur de jeu puissant, léger et facile à utiliser. Il est conçu pour être intuitif, avec un système d’événements qui permet aux créateurs de définir la logique de leur jeu de manière visuelle. Cette approche no-code est aussi efficace que la programmation, mais sans la complexité associée à l’apprentissage d’un langage de programmation.

La facilité d’utilisation de GDevelop

GDevelop est une plateforme de développement de jeux vidéo qui se distingue par sa facilité d’utilisation et son accessibilité. Conçu pour les créateurs de tous niveaux, GDevelop permet de créer des jeux sans écrire une seule ligne de code, grâce à son système d’événements intuitif. Les utilisateurs peuvent démarrer rapidement avec une variété de tutoriels et de ressources disponibles en ligne, qui guident à travers les étapes de création d’un jeu, de la conception des personnages à la logique du gameplay.

La plateforme utilise un système logique basé sur des conditions (« Si ») et des actions (« Alors »), ce qui rend la conception de jeux extrêmement accessible. Les créateurs peuvent ainsi se concentrer sur l’aspect créatif et ludique du développement de jeux, sans se soucier des détails techniques.

GDevelop est un outil puissant qui rend le développement de jeux vidéo accessible à un public plus large, sans les barrières techniques souvent associées à la programmation de jeux.

La puissance d’une plateforme Open-Source

GDevelop est une solution open-source, ce qui signifie que la communauté peut contribuer à son amélioration continue et partager des extensions et des actifs. Avec la possibilité de publier des jeux sur plusieurs plateformes, y compris iOS, Android et le web, GDevelop offre une voie rapide pour transformer une idée en un jeu jouable et partageable.

Les développeurs peuvent étendre les fonctionnalités de la plateforme en utilisant JavaScript ou en créant de nouveaux événements no-code directement depuis l’éditeur.

Des ressources pour apprendre et créer

GDevelop offre une vaste bibliothèque de tutoriels disponibles sur l’Académie, les utilisateurs peuvent démarrer rapidement, apprenant à utiliser le moteur de jeu grâce à des vidéos courtes et des articles détaillés. Que vous soyez débutant ou que vous cherchiez à approfondir vos connaissances sur une fonctionnalité spécifique, GDevelop fournit des ressources pédagogiques pour tous les niveaux. Les tutoriels couvrent une gamme de sujets, allant de la création de jeux de plateforme à la défense de vagues sans codage, en utilisant des mécaniques de jeu de base aux ennemis et plus encore.

De plus, GDevelop facilite la publication de jeux sur sa plateforme de jeux gd.games, permettant aux créateurs de partager leurs œuvres avec une communauté plus large. Les extensions de développement de jeux, qui ajoutent des fonctionnalités supplémentaires sans nécessiter de codage, sont également mises en évidence comme un moyen d’économiser du temps et de l’énergie dans le processus de développement.

Pour ceux qui cherchent à intégrer des fonctionnalités avancées, la documentation de GDevelop offre des guides sur la manière de gérer des logiques de jeu complexes, comme l’utilisation de machines à états finis (FSM) et le travail en équipe sur des projets de développement de jeux.

Une communauté et un support dynamiques

GDevelop se distingue par sa communauté dynamique et son support réactif, qui sont des piliers essentiels pour les créateurs de jeux de tous niveaux. Que ce soit à travers le forum officiel, où les utilisateurs peuvent échanger des idées, poser des questions et obtenir des réponses de la part d’autres développeurs, ou via le support technique proposé par les ingénieurs logiciels de GDevelop, l’entraide est au cœur de l’expérience. Les options de support varient, allant de l’aide par e-mail à la consultation en direct, garantissant ainsi que les créateurs de jeux peuvent trouver l’assistance dont ils ont besoin pour concrétiser leurs projets.

De plus, la présence de sections dédiées aux différents langages sur le forum témoigne de l’engagement de GDevelop envers une communauté internationale. Enfin, l’accès à des ressources pédagogiques et à une documentation complète permet aux utilisateurs de s’améliorer continuellement et de pousser les limites de leur créativité.

La flexibilité de publication

GDevelop offre une flexibilité remarquable pour les créateurs de jeux, leur permettant de publier leurs créations sur une multitude de plateformes. Que ce soit pour iOS, Android, Steam ou le web, GDevelop simplifie le processus de publication grâce à des fonctionnalités robustes d’exportation.

  • Pour iOS, GDevelop peut empaqueter automatiquement le jeu et même l’envoyer à l’App Store Connect, permettant ainsi aux développeurs de tester leur jeu sur iPhone ou via TestFlight avant la publication finale.
  • En ce qui concerne Android, le service en ligne de GDevelop construit le jeu et fournit un fichier APK ou AAB, prêt à être publié sur le Google Play Store ou l’Amazon App Store.
  • Pour les jeux destinés au web, les développeurs ont la liberté d’exporter leur jeu dans un dossier et de l’héberger manuellement sur n’importe quelle plateforme, ou d’utiliser des outils comme Electron pour créer une application de bureau ou mobile.
  • Enfin, pour Steam, GDevelop permet de créer des packages spécifiques pour Windows, macOS ou Linux, facilitant ainsi la distribution sur cette plateforme populaire.

Cette accessibilité à diverses plateformes sans transition complexe rend GDevelop particulièrement attrayant pour les développeurs indépendants et les éducateurs qui cherchent à partager leurs jeux avec un large public.

Monétisation et Analytique

La plateforme fournit des outils pour monétiser les jeux et suivre leur virilité. Les intégrations Admob permettent d’implémenter facilement des publicités dans les jeux mobiles, tandis que les outils analytiques aident à comprendre le comportement des joueurs.

Un moteur de jeu pour tous

GDevelop est bien plus qu’un simple outil de développement de jeux ; c’est une porte ouverte vers l’industrie du jeu pour les créateurs indépendants, les éducateurs et les agences. Avec sa facilité d’utilisation, sa communauté engagée et ses puissantes fonctionnalités, GDevelop est la solution idéale pour ceux qui souhaitent créer des jeux sans les barrières traditionnelles du développement de logiciels.

 

GDevelop représente une avancée significative dans le monde du développement de jeux vidéo. Il offre une plateforme où la créativité n’est limitée que par l’imagination des créateurs. En tant que moteur de jeu no-code, GDevelop est un catalyseur pour l’innovation, ouvrant la voie à une nouvelle génération de développeurs de jeux. Pour les passionnés de jeux, les éducateurs, ou les professionnels cherchant à diversifier leurs offres, GDevelop est une solution incontournable pour entrer dans l’ère du développement de jeux vidéo accessible à tous.

pexels henri mathieu 8355761

Start with Why de Simon Sinek, moteur de motivation et collaboration pour votre équipe

12 mai 2024 / / 0 Comments
start with why simon sinek

Start with Why Simon Sinek

Plongeons au cœur de la puissance du « Pourquoi » de Simon Sinek, et explorons comment cette approche révolutionnaire peut être le catalyseur pour développer la motivation et favoriser une meilleure collaboration au sein de votre équipe.

Alors que je me plonge dans les pages inspirantes de « Start with Why« , je réalise que les enseignements de Simon Sinek vont bien au-delà d’une simple stratégie commerciale. Ils offrent une boussole pour comprendre le véritable moteur qui anime chaque individu au sein d’une équipe. En adoptant cette perspective, nous sommes invités à réfléchir sur la manière dont le « Pourquoi » peut devenir le fil conducteur qui unit les membres d’une équipe, les motivant à travailler ensemble vers des objectifs communs.

Dans cette exploration, nous allons décortiquer les observations de Sinek et découvrir comment le fait de commencer par le « Pourquoi » peut créer une dynamique où la motivation individuelle se transforme en une énergie collective. Démarrons une aventure où le sens profond de votre entreprise devient l’inspiration qui nourrit la collaboration, générant un impact tangible sur la productivité et le bien-être au sein de votre équipe.

Démarrer avec Pourquoi

« Start with Why » commence par examiner pourquoi certaines entreprises et leaders réussissent spectaculairement alors que d’autres, pourtant dotés de ressources et de compétences similaires, échouent. Sinek avance l’idée que la clé du succès durable réside dans la capacité à articuler clairement le « Pourquoi » de son entreprise.

Les observations des grandes entreprises et figures emblématiques

Apple Inc.

Sinek met en lumière Apple Inc. comme l’un des exemples les plus frappants de la puissance du « Pourquoi ». Au lieu de simplement vendre des ordinateurs et des gadgets, Apple a réussi en communiquant son « Pourquoi » : challenger le statu quo et « Think different« . Cette vision a créé une communauté de clients dévoués qui partagent la même passion pour l’innovation.

Martin Luther King Jr.

Le livre explore également des figures emblématiques telles que Martin Luther King Jr. pour illustrer comment son discours « I Have a Dream » a inspiré des millions de personnes à se rallier à sa cause. King a commencé par expliquer son « Pourquoi » avant de détailler le « Comment » et le « Quoi ». Cette séquence a unifié des individus de divers horizons autour d’une vision commune.

Southwest Airlines

Sinek évoque aussi le cas de Southwest Airlines, une entreprise qui a choisi de se démarquer en remettant en question l’industrie de l’aviation. Leur « Pourquoi » était de démocratiser le voyage aérien, le rendant accessible à tous. Cette orientation a créé une culture d’entreprise unique et un service client exceptionnel.

L’Application Pratique du « Start with Why »

Définir le « Pourquoi »

La première étape pour une entreprise cherchant à appliquer le « Start with Why » est de définir son « Pourquoi ». Cela va au-delà de simplement gagner de l’argent. C’est la raison profonde, la mission qui inspire l’existence de l’entreprise. Une déclaration de mission claire et motivante peut devenir la boussole qui guide toutes les actions.

Communiquer le « Pourquoi »

Une fois que le « Pourquoi » est défini, la communication doit en être cohérente à tous les niveaux. Les employés, les clients, les partenaires et autres parties prenantes doivent comprendre le « Pourquoi » avant même de s’intéresser au « Comment » et au « Quoi ». Cela crée une connexion émotionnelle et favorise l’engagement.

Inspiration Interne et Externe

Les entreprises qui réussissent à inspirer leurs employés avec leur « Pourquoi » bénéficient d’une force de travail engagée et motivée. De plus, les clients qui partagent les mêmes valeurs sont plus susceptibles de devenir fidèles à la marque. Cette dualité d’inspiration interne et externe crée une dynamique puissante pour le succès.

Exemple de Zappos

Zappos, le détaillant en ligne de chaussures, est souvent cité comme un exemple exceptionnel d’application du « Start with Why ». Leur « Pourquoi » est centré sur offrir le meilleur service client possible. Cette vision a guidé toutes leurs décisions, conduisant à un modèle d’affaires réussi et à une satisfaction client exceptionnelle.

Développer des Affaires Rentables avec « Start with Why »

Différenciation sur le Marché

En articulant clairement le « Pourquoi », une entreprise se distingue de la concurrence. Cela crée une proposition de valeur unique et attire les clients qui partagent les mêmes convictions. Cette différenciation peut conduire à une position de leader sur le marché et à une rentabilité accrue.

Innovation Axée sur le « Pourquoi »

Les entreprises qui intègrent leur « Pourquoi » dans leur processus d’innovation sont mieux placées pour anticiper et répondre aux besoins changeants du marché. Cette approche favorise la créativité et la recherche de solutions novatrices, renforçant ainsi la pérennité de l’entreprise.

Engagement et Fidélité Client

Lorsque les clients comprennent et partagent le « Pourquoi » d’une entreprise, ils sont plus enclins à rester fidèles à la marque. Cet engagement client accru se traduit souvent par une augmentation de la rétention, des recommandations positives et, en fin de compte, une croissance des revenus.

Start with Why, moteur de collaboration et motivation

Plonger dans l’univers de « Start with Why » de Simon Sinek nous offre bien plus qu’une simple réflexion stratégique pour les entreprises. C’est un guide pour ceux qui cherchent à développer la motivation et à cultiver une collaboration harmonieuse au sein de leur équipe.

L’essence du « Pourquoi » devient la force qui transcende les individus pour les rassembler autour d’une vision commune. C’est un catalyseur puissant de motivation, transformant chaque tâche en une contribution significative à un objectif plus vaste. En comprenant et en communiquant le « Pourquoi », les leaders peuvent inspirer une énergie collective qui va bien au-delà des performances individuelles.

Dans ce contexte, le rôle du Product Manager ou du Product Owner devient crucial. En tant que gardiens de la vision et du « Pourquoi » au sein d’une équipe, ils ont la responsabilité d’insuffler cette motivation profonde à chaque étape du processus. En intégrant le « Pourquoi » dans la conception, le développement et la mise en œuvre des produits, ils créent une connexion tangible entre la mission de l’entreprise et le travail quotidien de l’équipe, renforçant ainsi la motivation et la collaboration.

Ainsi, en embrassant la philosophie de « Start with Why », les équipes peuvent cultiver un environnement où la motivation intrinsèque et la collaboration deviennent la norme. Que ce voyage à travers les principes de Sinek inspire chacun d’entre nous à donner un sens plus profond à notre travail et à forger des équipes qui transcendent les attentes, guidées par le pouvoir transformationnel du « Pourquoi ».

 

Sprint Revue

Qu’est-ce qu’une Sprint review ?

10 mai 2024 / / 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.

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.

XP

Les 12 pratiques XP pour Ninjas du code

12 avril 2024 / / 0 Comments

Dans le dojo de l’eXtreme Programming (XP), les pratiques ne sont pas seulement des mouvements de code aléatoires, mais des techniques affûtées, prêtes à transformer n’importe quel projet logiciel en une œuvre d’art agile. Alors, jeunes padawans du clavier, préparez-vous à découvrir les douze pratiques concrètes de l’XP qui feront de vous des maîtres du développement logiciel.

Les 12 pratiques XP pour Ninjas du code

1. Planning Game :

C’est le moment où les clients et les développeurs se réunissent pour une partie de poker… planning poker ! Ici, on estime les tâches, on planifie les sprints et on distribue les cartes du projet. Attention, pas de bluff permis !

2. Petites Releases :

Dans l’XP, on aime les sorties fréquentes et les petits pas. Pourquoi ? Parce que c’est comme goûter un gâteau cuillère par cuillère pour s’assurer qu’il est parfait à chaque bouchée.

3. Métaphore :

Chaque projet a besoin d’une histoire, d’une vision. La métaphore est le fil rouge qui guide le développement, un peu comme un GPS pour ne pas se perdre dans le code.

4. Design Simple :

Pourquoi construire une cathédrale quand une cabane suffit ? L’XP prône un design aussi simple que possible, mais pas plus simple. C’est l’art de la simplicité élégante.

5. Tests :

Ah, les tests ! Dans l’XP, on teste tout, tout le temps. C’est comme avoir un garde du corps personnel pour votre code, prêt à dégainer à la moindre erreur.

6. Refactoring :

Le code, c’est comme une garde-robe, ça se range et ça s’entretient. Le refactoring, c’est l’art de nettoyer son code sans changer son comportement, un peu comme repasser sa chemise préférée.

7. Programmation en Binôme :

Deux têtes valent mieux qu’une, surtout quand il s’agit de coder. La programmation en binôme, c’est partager un clavier pour doubler l’intelligence et diviser les bugs.

8. Propriété Collective du Code :

Ici, le code n’appartient à personne et à tout le monde en même temps. C’est la version logicielle de « ce qui est à toi est à moi ».

9. Intégration Continue :

Intégrer son code souvent, c’est comme faire des check-ups réguliers chez le médecin. Ça permet de s’assurer que tout fonctionne bien ensemble.

10. 40 Heures par Semaine :

L’XP dit non au surmenage. Travailler 40 heures par semaine, c’est rester frais et dispo pour coder avec brio.

11. Client sur Site :

Avoir le client à portée de main, c’est comme avoir un coach sportif personnel. Il motive, il guide, et parfois, il fait transpirer.

12. Normes de Codage :

Pour que tout le monde parle la même langue code, l’XP impose des normes. C’est la grammaire et l’orthographe du développement logiciel.

Voilà, vous avez maintenant en main les douze pratiques de l’eXtreme Programming, prêtes à être déployées pour affronter les défis du développement logiciel. Alors, enfilez votre kimono de codeur, saisissez votre clavier, et que la force de l’XP soit avec vous !.

Comment mettre en place XP dans une équipe ?

Mettre en place l’eXtreme Programming (XP) dans une équipe est un processus qui nécessite une compréhension approfondie des principes et pratiques de cette méthode agile. Voici un guide étape par étape pour intégrer XP au sein de votre équipe de développement logiciel.

Étape 1 : Sensibilisation et Formation

Avant tout, il est crucial que toute l’équipe comprenne les valeurs et les principes de l’eXtreme Programming. Organisez des sessions de formation pour discuter des cinq valeurs fondamentales de XP : communication, simplicité, feedback, courage et respect. Ces valeurs sont le socle sur lequel les pratiques de XP sont construites.

Étape 2 : Adoption des Pratiques de XP

Introduisez progressivement les pratiques de XP telles que l’intégration continue, le développement piloté par les tests (TDD), la programmation en binôme, la conception simple et le refactoring. Commencez par implémenter une ou deux pratiques et augmentez graduellement à mesure que l’équipe gagne en confiance et en compétence.

Étape 3 : Mise en Place d’une Communication Efficace

La communication est la clé du succès de XP. Assurez-vous que l’équipe dispose des outils et des processus nécessaires pour faciliter une communication ouverte et transparente. Cela inclut des réunions quotidiennes de stand-up, des tableaux de bord de projet et des outils de collaboration en ligne.

Étape 4 : Création d’un Environnement de Travail Adapté

L’environnement de travail doit encourager la collaboration et le partage des connaissances. Un espace ouvert où les développeurs peuvent facilement travailler en binôme et partager leurs écrans est idéal pour l’XP.

Étape 5 : Encouragement de la Rétroaction Rapide

Mettez en place des mécanismes pour obtenir des retours rapides, tant de la part des clients que de l’équipe. Cela peut inclure des démonstrations fréquentes du logiciel aux clients et des revues de code régulières au sein de l’équipe.

Étape 6 : Gestion du Changement

Préparez l’équipe à gérer les changements. XP est flexible et s’adapte bien aux exigences changeantes, mais cela nécessite une équipe prête à réagir et à ajuster ses plans rapidement.

Étape 7 : Mesure et Amélioration Continue

Mettez en place des indicateurs de performance pour mesurer l’efficacité des pratiques de XP. Utilisez ces données pour améliorer continuellement les processus et les pratiques de l’équipe.

L’adoption de l’eXtreme Programming est un voyage qui peut transformer la façon dont une équipe développe des logiciels. En suivant ces étapes et en restant fidèle aux valeurs de XP, votre équipe peut réduire le Time to Market tout en produisant un logiciel de haute qualité. Pour plus d’informations sur la mise en place de l’XP et le développement de l’esprit d’équipe, consultez des ressources supplémentaires qui offrent des conseils pratiques et des stratégies éprouvées.

XP

Qu’est-ce que la méthode eXtreme Programming (XP) ?

12 avril 2024 / / 1 Comment

La méthode eXtreme Programming (XP) : une révolution agile dans le monde du développement logiciel.

Ainsi naquit XP

Ah, l’eXtreme Programming (XP), cette méthodologie de développement logiciel qui a secoué le monde de la technologie comme un smoothie trop plein dans un mixeur sans couvercle. Créée par Kent Beck entre 1996 et 1999, XP est née de la frustration face aux méthodologies traditionnelles, plus rigides qu’un manchot dans une compétition de bras de fer.

Kent Beck - eXtreme Programming

Kent Beck – eXtreme Programming

L’histoire raconte que Beck, travaillant sur le projet de paie C3 pour Chrysler, s’est dit un jour : « Et si on prenait les meilleures pratiques de développement logiciel et qu’on les poussait à l’extrême ? » Et voilà, XP était née, prête à transformer le développement logiciel en une sorte de sport extrême, mais sans les fractures.

La motivation derrière XP ?

Simplifier, accélérer et améliorer la qualité du logiciel en s’adaptant continuellement aux exigences changeantes des clients. Imaginez un peu : des cycles de développement courts, des tests dès le début, et une collaboration intense entre tous les membres de l’équipe. C’est comme si on avait donné à chaque développeur une cape de super-héros et dit : « Allez, sauvez le monde du code médiocre ! ».

Avant XP, le développement logiciel était souvent synonyme de délais interminables et de documents de spécifications plus épais que la trilogie du Seigneur des Anneaux. Après XP, c’est devenu une affaire de réactivité, de qualité et de satisfaction client. On est passé d’une approche « on verra ça dans six mois » à « tiens, voilà une nouvelle fonctionnalité pour ton café du matin ».

Les exemples d’utilisation de XP ?

Ils sont aussi variés que les goûts de glaces chez votre marchand préféré. Des petites équipes agiles aux grandes entreprises, XP a prouvé qu’elle pouvait s’adapter à toutes les tailles de projets, que ce soit pour développer une application mobile révolutionnaire ou pour refondre un système de gestion d’entreprise.

En somme, l’eXtreme Programming, c’est un peu comme mettre des roulettes à un éléphant pour lui apprendre à faire du patin à glace : ça semble fou, mais avec les bonnes pratiques, tout est possible. Et si vous n’avez pas encore essayé XP dans vos projets, peut-être est-il temps de chausser vos patins et de rejoindre la piste glacée de l’agilité extrême !

Les 5 valeurs de XP

Les Valeurs Clés de l’eXtreme Programming : Un Cocktail Agile aux Saveurs Uniques

L’eXtreme Programming, ou XP pour les intimes, c’est un peu comme une recette de cocktail réussie dans le monde du développement logiciel. Chaque ingrédient doit être dosé avec précision pour créer une expérience inoubliable. Alors, quelles sont ces fameuses valeurs qui font de l’XP un mojito plutôt qu’un simple soda ? Accrochez-vous, car nous allons plonger dans le shaker agité de l’XP pour découvrir ses cinq valeurs clés qui mettent tout le monde d’accord.

  1. Communication : Imaginez un monde où les développeurs, les clients et les testeurs parlent la même langue, où les malentendus sont aussi rares qu’une licorne dans un métro. C’est le premier ingrédient de notre cocktail : une communication claire, directe et sans fioritures. Sans elle, autant essayer de coder avec des moufles.

  2. Simplicité : Ah, la simplicité, cette quête éternelle pour l’élégance minimaliste dans un océan de complexité. Dans l’XP, on aime les solutions aussi simples qu’une tartine de beurre. Pourquoi faire compliqué quand on peut faire simple et efficace ? C’est l’art de ne pas s’emmêler les pinceaux avec des designs surchargés.

  3. Feedback : Le feedback, c’est le zeste de citron dans notre cocktail. Il donne du peps et permet d’ajuster le tir en continu. Dans l’XP, on ne se contente pas de supposer que tout va bien, on vérifie, on teste, on écoute, et on améliore. C’est un peu comme demander à votre grand-mère si votre pull de Noël est à la bonne taille.

  4. Courage : Oui, vous avez bien lu, le courage ! Il en faut pour remettre en question le statu quo, pour jeter le code qui ne sert à rien et pour dire au client que son idée « révolutionnaire » est aussi innovante qu’une roue carrée. Le courage dans l’XP, c’est oser dire non, oser changer, oser être différent.

  5. Respect : Le respect, c’est la cerise sur le gâteau, ou plutôt, sur le cocktail. C’est respecter ses collègues, le travail réalisé, et les besoins du client. C’est comprendre que chaque membre de l’équipe a une valeur inestimable, comme les perles dans un collier de grand-mère. Sans respect, autant essayer de mixer un cocktail avec une fourchette.

Voilà, vous avez maintenant les cinq valeurs clés de l’XP, prêtes à être mélangées pour créer le meilleur des environnements de développement logiciel. Alors, à vos shakers, prêts, codez ! Et n’oubliez pas, l’XP, c’est comme la danse : il faut suivre le rythme, mais aussi savoir improviser quand la musique change. Santé !

Lean

Glossaire Lean

30 mars 2024 / / 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

Agile,Scrum

Glossaire Agile – Scrum

30 mars 2024 / / 1 Comment

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