Gestion de projet Agile : Scrum et Kanban

Cette leçon définit la méthode Agile comme une approche itérative et incrémentale de gestion de projet, illustrée par l'exemple du développement d'une application mobile de fitness livrée par petits sous-projets successifs. Elle explique comment Agile permet de s'adapter aux changements de priorités du client sans remettre en cause l'ensemble du projet, contrairement aux méthodes de gestion de projet traditionnelles.

Cette leçon illustre l'approche Agile à travers deux exemples concrets : un voyage en voiture planifié étape par étape plutôt que dans le détail à l'avance, et le développement itératif d'une messagerie électronique façon Outlook avec un backlog produit priorisé. Deux mises en situation simples pour bien comprendre le principe d'itération et d'adaptation au cœur de la gestion de projet Agile.

Cette leçon retrace la naissance du Manifeste Agile en 2001, rédigé par dix-sept experts du développement logiciel pour répondre au faible taux de réussite des projets informatiques des années 90. Elle détaille les 4 valeurs fondamentales et un résumé des 12 principes du Manifeste Agile, la référence commune à toutes les méthodologies Agile comme Scrum et Kanban.

Cet article complète la leçon précédente avec le texte intégral des 4 valeurs et des 12 principes du Manifeste Agile en français et en anglais, ainsi que les liens vers les sources officielles. Une ressource pratique à imprimer et garder sous la main pour intégrer l'état d'esprit Agile au quotidien.

Cette leçon rappelle qu'Agile est avant tout une philosophie et un état d'esprit, pas seulement un ensemble de pratiques ou d'outils comme Scrum ou Kanban. À travers la pyramide Agile et un retour d'expérience personnel sur une transformation Agile mal comprise en entreprise, elle explique pourquoi mettre en place des sprints et des daily scrum sans changer les mentalités du management ne suffit pas à obtenir les bénéfices de l'agilité.

Cette leçon détaille le fonctionnement de la méthode de gestion de projet traditionnelle Waterfall, ou en cascade, avec ses phases séquentielles de l'analyse des besoins jusqu'à la maintenance. Elle explique pourquoi ce modèle, né pour des projets militaires dans les années 50, s'adapte mal aux projets actuels qui exigent flexibilité et réactivité aux changements des besoins clients.

Cette leçon présente le triangle de fer de la gestion de projet, qui modélise les trois contraintes que sont le scope, le coût et le temps, et explique comment l'approche Agile inverse ce triangle par rapport à la méthode Waterfall. Alors qu'en gestion de projet classique le scope est fixe et le budget ou le délai s'ajustent, en Agile ce sont le calendrier et les ressources qui restent stables tandis que le périmètre du projet évolue selon les besoins du client.

Cette leçon présente des données chiffrées sur les bénéfices de la gestion de projet Agile : un taux de réussite trois fois supérieur à celui des projets menés en méthode classique selon une étude de 2012, ainsi que le classement des principales raisons pour lesquelles les entreprises adoptent l'agilité (vitesse de livraison, capacité à gérer les changements de priorité, productivité des équipes).

Cette leçon propose un glossaire en français des principaux termes anglais utilisés dans le cadre de travail Scrum : sprint, product backlog, sprint planning, daily scrum, sprint review, sprint retrospective, product owner, scrum master, user story et planning poker. Une ressource pratique à garder sous la main pour suivre sereinement la suite de la formation sur la gestion de projet Agile.

Cette leçon présente une vue d'ensemble du cadre de travail Scrum, né en 1995 sous l'impulsion de Ken Schwaber et Jeff Sutherland : l'équipe Scrum composée du product owner, du scrum master et des développeurs, le product backlog priorisé sous forme de user stories, et le déroulement d'un sprint avec ses quatre évènements. Un aperçu global avant d'entrer dans le détail de chaque rôle et évènement Scrum dans les leçons suivantes.

Cette leçon détaille les responsabilités des trois rôles de l'équipe Scrum : le product owner qui porte la voix du client et priorise le product backlog, le scrum master qui coache l'équipe et protège le sprint des sollicitations externes, et les développeurs qui livrent un incrément de valeur à chaque sprint. Des repères concrets pour comprendre qui fait quoi dans une équipe Scrum et éviter les confusions de rôles fréquentes lors d'une transformation Agile.

Cette leçon explique les deux caractéristiques essentielles d'une équipe Scrum : elle est pluridisciplinaire, capable de livrer une fonctionnalité de A à Z sans ressource externe, et autogérée, sans hiérarchie interne. Un retour d'expérience personnel sur une équipe scindée en deux pour rester productive illustre pourquoi il est recommandé de ne pas dépasser une dizaine de personnes par équipe Scrum.

Cette leçon définit le sprint, cycle de travail Scrum d'un mois ou moins au cœur duquel toute la valeur du produit est créée, et rappelle les règles qui encadrent son déroulement : l'objectif du sprint et les standards de qualité restent fixes, tandis que le scope peut être clarifié avec le product owner en cours de route. Elle précise aussi que seul le product owner peut annuler un sprint, et uniquement si son objectif devient obsolète.

Cette leçon détaille le sprint planning, l'évènement Scrum qui ouvre chaque sprint et répond à trois questions : pourquoi ce sprint est important, que peut faire l'équipe pendant le sprint et comment le travail sera réalisé. Elle précise la durée maximale de cette réunion et le rôle de chacun, notamment le fait que ce sont les développeurs, et non le product owner, qui décident de la quantité de travail à laquelle ils s'engagent.

Cette leçon présente le daily scrum, la réunion quotidienne de 15 minutes maximum réservée aux développeurs pour se synchroniser et lever les points bloquants du sprint en cours. Elle donne des bonnes pratiques concrètes comme la méthode des 3 questions et l'intérêt de faire cette réunion debout pour rester efficace et concis.

Cette leçon explique le rôle de la sprint review, l'avant-dernier évènement du sprint pendant lequel l'équipe Scrum présente aux parties prenantes et au client le travail accompli et recueille leurs retours. Elle insiste sur le fait que cette réunion doit être une vraie session de travail collaborative, et non une simple présentation où le client reste spectateur.

Cette leçon détaille la sprint retrospective, le dernier évènement du sprint consacré à l'amélioration continue du processus de travail de l'équipe Scrum plutôt qu'au produit lui-même. Elle explique le déroulement type d'une rétrospective en cinq étapes, de l'ouverture de la session jusqu'à l'élaboration d'un plan d'actions concret pour le sprint suivant.

Cette leçon présente le backlog refinement, une réunion qui ne fait pas officiellement partie du guide Scrum mais que la plupart des équipes utilisent pour clarifier, détailler et estimer les prochains éléments du product backlog. Elle explique qui y participe, à quel rythme l'organiser et comment elle prépare concrètement l'équipe à démarrer le sprint suivant sereinement.

Cette leçon donne une méthode simple pour rédiger une user story claire et compréhensible par tous les acteurs d'un projet Agile : un titre explicite, une phrase suivant le modèle « en tant que… je souhaite… pour… » et des critères d'acceptation. Un exemple concret de fonctionnalité de liste de favoris illustre comment transformer une demande fonctionnelle classique en user story exploitable par une équipe Scrum.

Cette leçon présente le planning poker, la technique d'estimation la plus utilisée en Scrum, basée sur des cartes reprenant la suite de Fibonacci pour estimer l'effort global d'une user story. Elle détaille le déroulement d'une session de vote et comment gérer les désaccords entre développeurs pour converger vers une estimation partagée par toute l'équipe.

Cette leçon présente deux indicateurs de suivi utilisés en Scrum pour mesurer la progression d'une équipe : la vélocité, qui mesure la quantité de travail livré à chaque sprint, et le burndown chart, qui représente visuellement la charge de travail restante par rapport au temps. Elle met en garde contre une mauvaise utilisation de la vélocité par le management, notamment la comparaison entre équipes, qui n'a pas de sens puisque chaque équipe possède son propre système d'estimation.

Cette leçon déroule un exemple complet et concret de projet mené en Scrum, la mise en place d'un système de gestion pour une bibliothèque municipale, de la constitution de l'équipe et du product backlog jusqu'au premier sprint planning, daily scrum, sprint review et rétrospective. Une synthèse pratique qui permet de voir comment tous les rôles, évènements et artefacts Scrum vus dans la formation s'articulent réellement sur un projet.

Cette leçon retrace l'origine de la méthode Kanban, créée dans les années 1950 par l'ingénieur japonais Taiichi Ōno chez Toyota pour optimiser la gestion des stocks avant d'être adaptée au développement informatique. Elle explique le principe du tableau Kanban, où les tâches circulent de colonne en colonne selon leur avancement, et la règle qui limite le nombre de tâches en cours pour gagner en efficacité.

Cette leçon détaille les 4 principes fondamentaux de la méthode Kanban : commencer par ce que l'on fait déjà, accepter les changements incrémentaux, respecter les rôles et processus existants dans l'organisation, et encourager le leadership à tous les niveaux. Elle explique pourquoi Kanban, contrairement à Scrum, ne demande pas de transformer l'organisation existante pour être mis en place.

Cette leçon présente les 5 pratiques centrales de Kanban pour organiser le travail d'une équipe : visualiser le travail, limiter le nombre de tâches en cours, mesurer et gérer la progression, établir des règles claires et reconnaître les opportunités d'amélioration continue. Des repères concrets pour mettre en place un board Kanban efficace au sein d'une équipe projet.

Cette leçon montre concrètement comment fonctionne un tableau Kanban à travers une démonstration sur Trello, avec ses colonnes à faire, en cours, à tester et terminé. Elle explique comment une équipe autogérée choisit ses tâches par ordre de priorité sans qu'un responsable les assigne, un principe clé de la gestion de projet Agile en Kanban.

Cette leçon compare Kanban et Scrum : Kanban est un système visuel de gestion des processus plus léger que le cadre de travail Scrum, sans rôles prédéfinis ni sprints, ce qui en fait une méthode plus simple à mettre en place. Elle évoque aussi le Scrumban, qui combine les deux méthodologies, ainsi que l'intérêt d'un stand up quotidien pour lever les points bloquants même en Kanban.

Cette leçon illustre la méthode Kanban à travers un exemple concret de gestion des incidents clients vécu par le formateur en tant qu'analyste fonctionnel, avec les différentes colonnes du tableau Kanban et la règle qui limite chaque personne à une seule tâche à la fois. Elle donne aussi des conseils pour écrire des tâches Kanban claires et actionnables, que ce soit pour améliorer un processus existant ou développer un nouveau produit.

Cette leçon présente deux métriques Kanban utiles pour suivre la progression d'une équipe : le lead time, ou délai total entre la création et l'achèvement d'une tâche, et le cycle time, la durée entre sa prise en charge et sa finalisation. Elle explique comment ces indicateurs permettent de repérer des problèmes d'organisation ou des points bloquants qui ne seraient pas visibles autrement.

Cette leçon présente la notion de swimlane, ou couloir de nage, qui permet de regrouper visuellement les tâches d'un tableau Kanban par catégorie ou par niveau de priorité à l'aide de codes couleurs. Une technique particulièrement utile pour les grandes équipes pluridisciplinaires qui ont besoin de se repérer rapidement parmi un grand nombre de tâches.

Cette leçon conclut la partie Kanban de la formation en rappelant que cette méthode peut s'appliquer bien au-delà du développement informatique, y compris à l'organisation de la vie quotidienne, et insiste sur l'importance de finir les tâches commencées avant d'en prendre de nouvelles pour éviter la procrastination et le multitâche, qui réduit la productivité individuelle.

Cette leçon répond à une question fréquente sur Kanban : qui définit et priorise les tâches à réaliser dans le tableau Kanban ? Elle explique que ce rôle revient généralement au chef de projet, au chef de produit, à un analyste fonctionnel ou à un développeur expérimenté, et clarifie la différence entre le nombre de tâches dans la backlog et la limite imposée uniquement sur les tâches en cours.

Cette leçon répond à une question récurrente : peut-on appliquer la méthode Agile en dehors de l'informatique ? À travers l'exemple concret de la création d'une salle de sport gérée en mode Agile et l'utilisation d'un tableau Kanban pour organiser la vie quotidienne d'une famille, elle montre qu'Agile est avant tout un état d'esprit qui s'adapte à de nombreux contextes, à l'exception des secteurs où l'erreur n'est pas permise, comme le développement d'un médicament.

Cette leçon de conclusion félicite les participants pour avoir terminé la formation sur la gestion de projet Agile, Scrum et Kanban, et les encourage à mettre en pratique les concepts vus tout au long du cours.

Cette leçon indique comment rester en contact avec le formateur et suivre son actualité au-delà de la formation.

Cette leçon bonus donne accès à des ressources complémentaires liées à la gestion de projet Agile, Scrum et Kanban.

Cette leçon explique comment obtenir votre certificat de fin de formation sur la gestion de projet Agile, Scrum et Kanban.