skip to Main Content
Retour au sommaire         Ce chapitre comporte des contenus cachés. En devenant abonné PREMIUM vous aurez accès aux cinq zones de texte masqué et au QCM dans son intégralité, soit plus de cinquante questions au lieu de vingt pour les visiteurs. Voir les offres d’abonnement.

Scrum, XP et autres méthodes agiles

La gestion agile des projetsDédiées aus projets informatiques, les méthodes dites « agiles » gagnent du terrain. C’est fou comme l’expression « gestion agile » fait briller les yeux des étudiants. Ils y voient la promesse d’un travail sans contraintes, sans stress; d’une équipe de projet qui avance à son rythme sous le regard bienveillant du client. Totale erreur ! La gestion agile demande au moins autant de rigueur que les méthodes classiques, dites « prédictives ». C’est ce que nous allons voir dans ce chapitre.

Cliquez sur la barre de titre pour voir le contenu de la leçon

Raison d'être et historique des méthodes agiles

Historique et raison d’être des méthodes agiles

Projets informatiquesLes projets informatiques ont longtemps été conduits comme les autre, sur la base d’un cycle de vie linéaire. A l’issue de ce processus, d’une durée rarement maitrisée, l’utilisateur découvrait un résultat plus ou moins conforme à ses attentes (souvent moins !). Il s’agit là de l’effet tunnel, très connu en management de projets.
Au début des années 1980 sont apparues dans le monde du développement de logiciels de nouvelles méthodes de management de projet destinées à supprimer cet effet tunnel, à corriger les dérives de délai et surtout à livrer un produit de nature à satisfaire les utilisateurs. Aujourd’hui regroupées sous l’intitulé de « méthodes agiles » elles ont en commun de mettre l’utilisateur au centre de la démarche, de privilégier le respect du délai et de fonctionner suivant un cycle …….. Pour lire la suite souscrivez un abonnement PREMIUM ou si vous êtes déjà abonné connectez-vous 

Le manifeste agile

Les principes communs aux différentes méthodes dites « agiles » ont été mis sur le papier en février 2001, aux États-Unis. Dix-sept spécialistes du développement logiciel s’étaient réunis pour débattre de leurs méthodes respectives. Parmi eux se trouvaient l’inventeur du Wiki et créateur de l’extreme programming ainsi que le fondateurs de Scrum. La synthèse de cette réunion est connue sous le nom de Manifeste agile. Le Manifeste agile est constitué de quatre valeurs et de 12 principes fondateurs.

Les 4 valeurs et les 12 principes du manifeste agile

Les 4 valeurs agiles

Préférer et favoriser :
1. Les individus et leurs interactions plus que les processus et les outils.
2. Du logiciel qui fonctionne plus qu’une documentation exhaustive.
3. La collaboration avec les clients plus que la négociation contractuelle.
4. L’adaptation au changement plus que le suivi d’un plan.

Les principes agiles

Le manifeste agile a établi une liste de 12 principes communs aux différentes méthodes, voici ces principes :

1. Priorité à la satisfaction du client
C’est le principe le plus important des méthodes agiles. Et pour savoir si le client est satisfait il faut l’impliquer dans le processus de développement,
2. Acceptation des changements
Dans les méthodes agiles la phase de définition du besoin est réduite au minimum. Le besoin se précise au cours du projet. Il est admis que le client fasse évoluer sa demande à tout moment. Chaque évolution est analysée, chiffrée, et priorisée.
3. Livraison précoce puis régulière de versions opérationnelles de l’application
Impliquer le client dans le processus de développement ne suffit pas, encore faut-il lui montrer très vite à quoi ressemblera son application. Il ne sait pas se prononcer sur du code informatique, par contre il verra très bien si telle fonctionnalité lui convient ou pas.
4. Coopération entre l’équipe de projet et les gens du métier
Ce devrait être un comportement normal quelle que soit la méthode utilisée, c’est encore plus vrai en agile.
5. Construction des projets autour de personnes motivées
Une équipe agile doit être motivée pour réussir. Cette motivation se construit notamment sur la stabilité de l’équipe afin que la confiance puisse s’installer.
6. Priorité au dialogue direct
Eviter les moyens de communication modernes mais impersonnels : mail ou plate-formes collaboratives. Préférer toujours les relations directes et verbales.
7. Mesure de l’avancement du projet en fonction de l’opérationnalité du produit
Il ne suffit pas de consommer des heures de travail pour progresser vers l’objectif. Plus que jamais la mesure de l’avancement doit se faire en fonction des livrables validés par le client.
8. Rythme constant et soutenable par tous les intervenants du projet
Inutile de surcharger l’équipe de développement en croyant …….. Pour lire la suite souscrivez un abonnement PREMIUM ou si vous êtes déjà abonné connectez-vous 
Principes agilesLe schéma ci-contre met en lumière les profondes différences entre la gestion classique (dite aussi prédictive) et les méthodes agiles. Plus qu’une simple différence d’organisation il s’agit d’une façon nouvelle de penser les relations MOA-MOE. On passe clairement d’une logique de confrontation (méthodes classiques) à une logique de coopération (méthodes agiles). Par un effet de bascule assez habituel dans la vie des entreprises on revient à une époque où maître d’ouvrage et maître d’œuvre se parlaient d’égal à égal avec comme objectif commun le succès du projet.
Le cycle itératif des méthodes agiles

Le « time boxing » des méthodes agiles

Cycle itératif des méthodes agilesLa particularité la plus marquante des méthodes agiles réside (paradoxalement) dans la rigidité du découpage du temps (d’ou le nom de « time boxing »). A un premier niveau le projet est découpé en séquences de deux à trois semaines (notées « itérations » sur le schéma) et nommées « sprints » dans la méthode Scrum. L’équipe s’engage à livrer au client, à l’issue de chaque sprint, une ou plusieurs parties fonctionnelles du produit que le client va valider et qui font partie du système tel qu’il lui sera livré. A un niveau plus fin c’est quotidiennement, en début de journée, que l’équipe de projet va se réunir très brièvement (pas plus de 15 mn) pour faire le point du travail réalisé et des difficultés rencontrées la veille et pour distribuer le travail pour la journée qui commence. La contrainte de temps est prioritaire, de sorte que si le développement prend du retard, la décision pourra être de réduire le périmètre du projet plutôt que d’accorder un délai supplémentaire.

La nécessité d’une architecture modulaire

L'architecture agileLa contrainte de livrer très tôt des parties fonctionnelles du système peut amener à concevoir différemment la solution, sur un principe modulaire plutôt que monobloc. Le schéma ci-contre illustre cette différence. En haut l’application des méthodes classiques conduit à l’effet tunnel : Le produit s’élabore progressivement, le client ne verra le résultat qu’en toute fin du projet, et sera rarement satisfait ! En partie basse le processus agile. L’équipe montre très tôt des parties que le client peut valider ou pas. Ayant participé activement au processus il n’y a aucune raison qu’il ne soit pas satisfait du résultat final.

Panorama des méthodes agiles
Voici une présentation sommaire des différentes méthodes agiles. Nous ne reprendrons pas pour chacune d’entre elles la totalité de ses caractéristiques mais seulement ce qui la différencie des autres méthodes agiles. Les liens à la fin de chaque paragraphe pointent vers des descriptions plus complètes.

RAD (Rapid Application Development)

A tout seigneur tout honneur, RAD est la première méthode de développement de logiciels où le cycle de développement est en rupture fondamentale par rapport à celui des méthodes antérieures dites « en cascade ». Ce nouveau cycle qualifié d’itératif, d’incrémental et d’adaptatif, se retrouvera dans toutes les méthodes dites « agiles » publiées par la suite. Même s’il n’en est pas le seul inspitateur James Martin a le mérite d’avoir formalisé la méthode RAD et de l’avoir publiée en avril 1991.
RAD introduit des principes dont plusieurs feront florès par la suite :
– La « Timebox » et le « Timeboxing » constituent une innovation pour l’époque, qui consiste à fixer à l’avance une limite de durée à respecter absolument.
– Les « Focus de visibilité » sont des démonstrations de l’application en cours de développement.
– L’ »Equipe SWAT » (Skilled With Advanced Tools ou en français « Qualifiée et pourvue d’outils avancés ») est une petite équipe (2 à 6 personnes) pour une meilleure réactivité et pour éviter les problèmes de communication.
– Le « GAR » (groupe d’animation et de rapport) a pour mission de faciliter les relations maitrise d’oeuvre / maitrise d’ouvrage.
Pour le reste la méthode RAD est structurée de façon très classique en cinq phases : Initialisation, Cadrage, Design, Construction et Finalisation.

Voici quelques liens qui vous permettrons d’en savoir un peu plus sur RAD :
La page Wikipedia sur RAD
Un site francophone dédié à RAD

XP (eXtreme Programming)

XP a été créée par Kent Beck entre 1996 et 1999, alors qu’il travaillait sur un projet pour Chrysler.
Voici quelques particularités de la méthode XP :
– Le coach XP (ce rôle correspond au Scrum Master dans la méthode SCRUM que nous présenterons un peu plus loin) est une sorte le leader de l’équipe de dédeloppeurs. C’est lui qui s’assure que la démarche XP est correctement implémentée, et que la méthode fonctionne comme il se doit dans le cadre du projet. Il fait en sorte que les embûches qui se dressent sur le passage de l’équipe soient éliminées.
– Dans XP les développeurs travaillent en binôme. C’est la notion de Pair programming. L’un écrit le code, l’autre regarde, propose, corrige et commente. Puis on change les rôles, et ainsi de suite. Les connaissances sont ainsi partagées, et les idées émanent plus facilement que dans d’autres types d’organisation. Par ailleurs grace à cette mutualisation des connaissances l’absence de l’un des membres du binôme perturbe très peu l’avancement du projet.
– Autre principe de XP, la recherche de …….. Pour lire la suite souscrivez un abonnement PREMIUM ou si vous êtes déjà abonné connectez-vous 

Crystal

Les méthodes agiles Crystal (car il s’agit d’une famille de méthodes) ont été créées au milieu des années 90 par Alistair Cockburn, un célèbre programmeur américain. Il a notamment participé à la rédaction du Manifeste Agile en 2001 et a publié plus d’une demi-douzaine de livres sur le développement agile. Pourquoi plusieurs méthodes ? Tout simplement parce qu’il y a des projets de différentee tailles et de nature différente, et que tous les organismes qui développent des projets ne se ressemblent pas. Crystal met l’accent sur les hommes, la compétence et la confiance plutôt que sur une méthodologie stricte.
Le plus populaire des méthodes Crystal est Crystal Clear, adaptée aux projets de petite taille. Néanmoins toutes les méthodes (Crystal Clear, Crystal Yellow, Crystal Orange, Crystal Orange Web, Crystal Red, Crystal Maroon, Crystal Diamond et Crystal Sapphire) fonctionnent sur les mêmes principes :
– Une équipe composée d’un facilitateur et de 2 à 7 développeurs
– Une grande salle dédiée équipée de tableau blanc et de paperboards. Ceci pour favoriser la communication osmotique : la communication orale et spontanée est le point fort de Crystal Clear. Tout le monde peut répondre à une question posée.
– La sécurité personnelle des membres de l’équipe. Ceci se concrétise par un environnement de travail sans perturbation. En pratique chaque développeur doit pouvoir coder deux heures d’affilée sans être dérangé. Pas de réunion intempestive, pas de téléphone. Jamais moins de deux journées à travailler sur le même projet.
– Un accès direct et rapide aux experts techniques et métier et aux utilisateurs.
– Un environnement technique performant, avec notamment les tests automatisés, le déploiement automatisé de la solution, la remontée automatique des anomalies, un outil de gestion de configuration…

Voici quelques liens qui vous permettrons d’en savoir un peu plus sur Crystal :
Crystal sur le site Agile utile
Crystal sur le site wikipedia
Crystal sur le site de Thibaud Frichet
Crystal sur le site Nutcache

UP (Unified Process)

Autant les méthodes Crystal sont basées sur l’humain, autant UP et ses avatars sont basées sur une méthodologie stricte, à savoir la méthode UML et ses outils de modélisation : Diagramme des cas d’utilisation, Diagramme de séquence et Diagramme d’état. UP est malgré tout considérée comme une méthode agile car elle procède par itérations amenant progressivement au produit fini. Chaque itération est structurée comme un projet, en quatre phases successives : Etude préliminaire, Elaboration, Construction, Transition.
Les « avatars » de UP dont il est fait état plus haut sont essentiellement :
RUP (pour Rational Unified Process) a été élaborée par Rational Software et plus tard par IBM. RUP est considérée comme un processus lourd.
AUP (pour Agile Unified Process) est une version atténuée de UP mettant l’accent sur l’optimisation et l’efficacité sur le terrain plus que sur le modèle théorique.

Voici quelques liens qui vous permettrons d’en savoir un peu plus sur UP :
UP sur le site wikipedia
Un pdf d’Aurélien Tabart

DSDM (Dynamic Systems Development Method)

La méthode DSDM passe pour être une version anglo-saxonne de la méthode RAD.
Une originalité de DSDM est d’introduire quatre rôles :
– Le Visionnaire définit la … vision. Il donne la direction du projet à travers les objectifs métier.
– Le Sponsor ou « Product champion » est celui qui veut le produit et qui paie pour ça.
– L’Ambassadeur est le représentant des utilisateurs. Il prend les décisions sur le détail des exigences.
– Le Conseiller fournit de l’expertise métier à la demande de l’Ambassadeur.

Voici un lien qui vous permettra d’en savoir un peu plus sur DSDM :
DSDM sur le site Agile utile

FDD (Feature Driven Development)

FDD a été conçu par Jeff De Luca en 1997 pour répondre aux besoins spécifiques d’un projet de développement logiciel dans une grande banque de Singapour. Feature Driven Development se traduit en français par « Développement piloté par les fonctions »

Voici un lien qui vous permettra d’en savoir plus sur FDD :
FDD sur le site Agile utile

APF (Adaptative Project Framework)

APF est un hybride des méthodes prédictives (ou classiques) auxquelles elle emprunte les outils de structuration comme la WBS ou le diagramme de Gantt et les méthodes agiles. La méthode a été créée par Robert K. Wysocki, expert de la gestion de projet et auteur de plusieurs ouvrages sur le sujet.

Voici un lien qui vous permettra d’en savoir plus sur APF :
APF sur le site Planzone

SCRUM

La méthode SCRUM jouit en France comme dans beaucoup d’autres pays d’une grande popularité. Raison pour laquelle cette méthode fait l’objet de la prochaine leçon.

Kanban

Le mot « Kanban » est très connu des spécialistes de la gestion de production (peu de chose à voir donc avec l’informatique). La méthode de gestion de production Kanban est née chez le constructeur automobile Toyota. Sa caractéristique essentielle, et qui nous intérresse ici est d’aboutir à une diminution drastique des stocks intermédiaires. L’application aux projets informatiques est très simple : il ne s’agit pas ici de limiter des stocks de marchandises mais de limiter le nombre de tâches « ouvertes » à un instant donné. La meilleure illustration est donnée dans la vidéo présente un peu plus bas dans cette page et que vous pouvez aussi visionner en suivant ce lien.

Voici deux liens qui vous permettrons d’en savoir plus sur la méthode Kanban :
Kanban sur le site Agile utile
Kanban sur le site My Agile Partner
La méthode SCRUM
Pour beaucoup de gens, agile est synonyme de SCRUM et inversement. La raison en est que la méthode SCRUM a dans beaucoup de pays éclipsé toutes les autres, jusqu’à être la seule enseignée dans les écoles d’informatique.

Le vocabulaire de la méthode Scrum

Backlog de produit : Le produit est décomposé en fonctionnalités, ou exigences, ou briques élémentaires, rédigées sous la forme de « stories ». L’ensemble de ces fonctionnalités est appelé backlog de produit. Chaque fonctionnalité est affectée d’un poids représentatif de sa complexité et d’un ordre de priorité.
Backlog de sprint : Ensemble des fonctionnalités prises dans le backlog de produit et que l’équipe se propose de réaliser au cours du sprint.
Burndown chart : Représentation graphique du reste à faire d’un sprint ou du projet.
Impediment list : liste de tous les obstacles qui nuisent à la productivité et à la qualité du produit, tenue à jour par le Scrum master.
Planning poker : Technique d’estimation en groupe utilisant un jeu de cartes. L’expression désigne à la fois le jeu de cartes et la séquence collective d’estimation des charges de travail. Les cartes s’inspirent de la suite de Fibonacci. Le but est de se mettre d’accord de manière collective sur un ordre de grandeur de l’estimation. Un jeu de cartes téléchargeable vous sera proposé un peu plus loin.
Product owner : C’est le porteur du projet. Il a une connaissance complète du produit, tant en ce qui concerne l’aspect fonctionnel que l’architecture et les solutions à mettre en œuvre. Le Product Owner définit les fonctionnalités du produit. Il représente les futurs utilisateurs. Il priorise les fonctionnalités à réaliser. Le Product Owner est assimilable au maître d’ouvrage des méthodes classiques.
Retrospective de sprint: Réunion de toute l’équipe en fin de sprint. L’équipe fait le point sur ce qui s’est passé dans le Sprint (inspecter) dans le but d’améliorer (adapter) les processus pour le prochain Sprint.
Scrum (méthode) : Le mot « scrum » désigne la mélée au jeu de rugby. Scrum est un processus agile de gestion de projet pour construire un logiciel de façon incrémentale, itérative et adaptative.
Scrum board Tableau de progression des travaux. Généralement présenté sous la forme de post-its collés sur un tableau.
Scrum daily meeting : ou « Daily stand-up » ou encore « Daily scrum meeting ». Réunion quotidienne de 10 à 15 minutes à l’occasion de laquelle l’équipe fait le point du travail réalisé la veille. Les participants de la réunion restent debout. Chaque membre répond à ces 3 questions : qu’ai-je fait hier, que vais-je faire aujourd’hui, quels sont les problèmes que je rencontre. Il revient ensuite (après la réunion) au Scrum Master de résoudre les problèmes soulevés.
Scrum master : C’est l’animateur d’une équipe scrum. Il encadre les les Team member et s’assurent qu’ils travaillent dans les meilleures conditions. Le Scrum Master est assimilable au chef de projet maîtrise d’œuvre des méthodes classiques.
Sprint : Période (ou itération) de 2 à 4 semaines à l’issue de laquelle un certain nombre de fonctionnalités auront été produites, validées par le client et intégrées dans le produit final.
Sprint Backlog : Liste des fonctionnalités (stories) à réaliser pendant le sprint.
Sprint planning : Réunion pendant laquelle l’équipe planifie le travail qui va être réalisé durant le sprint à venir (qu’est-ce qui va être fait, comment on va le faire, et quel est le but global du sprint) C’est aussi pendant le sprint planning que les tâches sont estimées collectivement en terme de …….. Pour lire la suite souscrivez un abonnement PREMIUM ou si vous êtes déjà abonné connectez-vous 

L’expression du besoin : User stories et Backlog du produit

User stories agilesUn des aspects les plus intéressants de Scrum est la façon dont est recueilli et exprimé le besoin des utilisateurs, sous la forme de « user stories » (en français récits utilisateurs). Dans les méthodes classiques le besoin est exprimé par des fonctions. Prenons le cas d’un formulaire en ligne à l’usage des demandeurs d’emploi. L’expression d’une fonction pourrait être « (Le système doit) Permettre au candidat de limiter sa recherche aux départements de son choix ». En terme d’user storie cela donne : « En tant que demandeur d’emploi (rôle) je veux sélectionner les départements (fonctionnalité) dans le but d’obtenir les offres correspondant à mon périmètre de recherche (bénéfice). C’est la même chose mais c’est totalement différent : l’expression fonctionnelle se concentre sur ce que fait le produit, les user stories centrent l’attention sur ce que veut l’utilisateur. Il est beaucoup plus facile pour un individu de dire « je veux pouvoir bénéficier de ceci » que « le futur système doit faire ceci ». L’expérience montre que les réunions de travail en mode « user stories » sont plus dynamiques et productives, jusqu’à être parfois carrément ludiques.
Une bonne User Story doit aussi respecter les caractéristiques réunies sous le sigle INVEST :
Indépendante : assure l’indépendance d’une User Story vis-à-vis des autres user stories du backlog;
Négociable : une User Story doit être un support de discussion en vue d’une amélioration du besoin initial;
Valorisable : la réalisation d’une User Story doit rendre un service à l’utilisateur. En un mot, une User Story n’a de sens que si elle apporte une valeur métier;
Estimable : une User Story doit être bien définie pour être facilement chiffrable;
Suffisamment petit : une User Story doit être réalisable sur un sprint;
Testable : une User Story doit être accompagnée de ces critères d’acceptabilité pour faciliter sa validation.

Estimer l’effort avec le planning poker

Le planning poker agileLe planning poker est l’outil d’estimation utilisé pour le développement des applications informatiques avec la méthode Scrum. Le planning poker est une variante intelligente et ludique des méthodes à dire d’expert. Il s’inspire de la méthode Delphes pour ce qui est de l’estimation secrète précédant la recherche du consensus. Le but n’est pas d’estimer les charges de travail mais de classer les différentes fonctionnalités par rang de complexité. La traduction en charge de travail se fait ultérieurement par le biais de la vélocité. Comme la plupart des outils des méthodes agiles, le planning poker est parfaitement transposable à tous types de projets en dehors du seul domaine des projets informatiques. On peut faire une séance de Planning Poker au début du projet, puis en refaire d’autres plus tard quand le groupe a acquis une meilleure connaissance du contenu.
Le matériel nécessaire se compose de jeux de 11 cartes de valeurs 0 – 0,5 – 1 – 2 – 3 – 5 – 8 – 13 – 20 – 40 – 100, plus une carte joker et une carte infini. Chaque participant dispose d’un jeu de cartes. Un tableau mural, divisé en autant de colonnes que de valeur possible permettra …….. Pour lire la suite souscrivez un abonnement PREMIUM ou si vous êtes déjà abonné connectez-vous 

Les outils de planification des méthodes agiles

Planning agile : le Scrum board

Le planning agileDans la méthode Scrum les travaux sont pilotés à l’aide d’un planning constitué d’un simple tableau (board) sur lequel sont collés des étiquettes de type « Post-it » représentant chacune l’une des tâches à accomplir. La version manuelle utilise un vrai tableau mural et de vrais post-it. Les nombreuses solutions informatiques développées autour de Scrum reproduisent à l’écran ce tableau et ces étiquettes. Bien entendu la version informatique permet d’automatiser les calculs de temps passé et de reste à faire. Le tableau est partagé en colonnes verticales de façon à créer un flux d’étiquettes de la gauche (à faire) vers la droite (en production) en passant par les étapes intermédiaires « en cours » et « à l’approbation ». Une forme particulière de planning agile, nommée « Kanban » ajoute un perfectionnement supplémentaire : le nombre d’étiquettes figurant dans la colonne « à faire » est volontairement limitée de façon à éviter l’effet d’engorgement et de surcharge de travail des contributeurs.

Le planning agileVoici une variante très proche de la version précédente : une couleur a été affectée à chaque membre de l’équipe, et les données nécessaires au suivi de l’avancement figurent en bas de tableau.

La « Burndown chart »

La burndown chart agileLa burndown chart est une représentation graphique de l’évolution de quantité de travail restante (le reste à faire) par rapport au temps. Le travail restant se situe sur l’axe vertical et le temps sur l’axe horizontal. L’axe vertical (reste à faire) est gradué en points de complexité. Les valeurs sont issues des séances de planning poker. Lorsque l’équipe de projet est employée à plein temps sur le projet, le profil idéal est une droite diagonale descendante. La position des valeurs réelles au-dessus ou au-dessous de la diagonale renseigne immédiatement sur la tendance : Valeurs réelles au-dessus signifie que l’on prend du retard et qu’il faut prendre immédiatement des mesures correctives. La burndown chart donne lieu à deux visions suivant le niveau de granularité : l’un pour chaque sprint (sprint burndown chart) et l’autre globale au niveau du projet (Release burndown chart)

Vidéo de présentation des méthodes agiles
Ne ratez pas cette vidéo explicative sur les méthodes agiles. Son auteur est Henrik Kniberg et elle a été doublée en français par Florent Lothon du site l’agiliste

Quelques ressources complémentaires

Autres ressources sur le web

  • Le site Aubryconseil, dédié à la méthode Scrum
  • Le site de Florent Lauthon, l’agiliste

Quelques solutions informatiques pour la gestion agile

  • Le logiciel PMA de Time performance, dédié aux projets agiles
  • L’application en ligne scrumwise avec une interface simple, agréable et ergonomique. (uniquement en anglais)
  • De même, Leankit également en anglais et très réussi

Plus de liens vers les logiciels agiles à la page Comment choisir un logiciel de gestion de projet de Time performance, dédié aux projets agiles

Testez vos connaissances

Vous êtes identifié comme visiteur. A ce titre vous avez accès à une version limitée du QCM (20 questions). Pour accéder à la version intégrale (20 questions prises au hasard parmi plus de 50) vous devez souscrire un abonnement PREMIUM. Je souhaite voir les offres d’abonnement PREMIUM

C’est parti pour 20 questions

Questionnaire sur ------------------------Bienvenue dans ce test.
Ce questionnaire comporte 20 questions.
Le temps n’est pas limité.
Munissez-vous d’un papier, d’un crayon et d’une calculette.
Bon travail et bonne chance !

Quelques précisions sur ce test sur les méthodes agiles

– La participation à ce test sur les méthodes agiles est totalement libre : pas besoin de laisser vos coordonnées, elles ne vous seront pas demandées. La bonne réponse à une question ainsi que des explications supplémentaires vous seront fournies avant que vous ne décidiez de passer à la question suivante.
– Vous devez répondre à 20 questions, toutes portent sur les méthodes agiles. Chaque bonne réponse vaut 1 point. A la fin du test, vous aurez votre note sur 20 ainsi que notre commentaire.

Voici quelques-uns des thèmes abordés dans les différentes questions :

– Principes agiles – Méthodes agiles – Burndown chart – Sprint – User stoty – Planning poker – Daly meeting – Product backlog – Product owner – Scrum master – Rétrospective de sprint – Time box – Kaizen – Sprint backlog – Sprint planning – XP (eXtreme Programming) – TDD (Test Driven Development) – Scrum – UP (Unified Process) – RAD (Rapid Application Development) – FDD (Feature Driven Development) – Manifeste agile – Kiss (Keep It Stupidly Simple) – CRYSTAL – Refactoring – Vélocité – Grille INVEST – DSDM (Dynamic Systems Development Method) – APF (Adaptative Project Framework) – Timeboxing – Focus de visibilité – Equipe SWAT (Skilled With Advanced Tools) – GAR (Groupe d’Animation et de Rapport) – Scrum board –

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

WordPress Video Lightbox
Back To Top