Méthode « traditionnelle » : le cycle en V III- GESTION DE PROJET « AGILES » avec SCRUM Plan Méthode « traditionnelle » : le cycle en V 1- Introduction à l’approche agile 2- Le Manifeste Agile, un changement culturel 3- La méthodologique Scrum 4- Les rôles dans Scrum 5- Les étapes dans Scrum

Méthode « traditionnelle » : le cycle en V III- GESTION DE PROJET « AGILES » avec SCRUM 1- Introduction Méthode « traditionnelle » : le cycle en V Approche Agile plutôt que méthode Agile Le terme "méthode" est trop réducteur pour parler de cette façon d'aborder la gestion de projet. Il s'agit de bien plus qu'une méthode. On parle plutôt d'état d'esprit agile, de philosophie agile, de culture Agile ou encore d'approche agile, de mouvement agile, de courant agile, etc. On parle cependant de "méthodes agiles" pour définir les méthodes qui relèvent de ce courant.

Méthode « traditionnelle » : le cycle en V III- GESTION DE PROJET « AGILES » avec SCRUM 1- Introduction Méthode « traditionnelle » : le cycle en V Une autre approche de gestion de projet Le terme "agile" définit une approche de gestion de projet qui prend le contre-pied des approches traditionnelles prédictives et séquentielles de type cycle en V. Une approche dite "traditionnelle" attend généralement du client une expression détaillée et validée du besoin en entrée de réalisation, laissant peu de place au changement. La réalisation dure le temps qu'il faut et le rendez vous est repris avec le client pour la recette. Cet effet tunnel peut être très néfaste et conflictuel, on constate souvent un déphasage entre le besoin initial et l'application réalisée. On se rapporte alors aux spécifications validées et au contrat.

Méthode « traditionnelle » : le cycle en V III- GESTION DE PROJET « AGILES » avec SCRUM 1- Introduction Méthode « traditionnelle » : le cycle en V Une autre approche de gestion de projet Il n'est pas rare que certaines fonctionnalités demandées se révèlent finalement inutiles à l'usage alors que d'autres, découvertes en cours de route, auraient pu donner plus de valeur au produit. L'approche Agile propose au contraire de réduire considérablement voire complètement cet effet tunnel en donnant davantage de visibilité, en impliquant le client du début à la fin du projet et en adoptant un processus itératif et incrémental. Elle considère que le besoin ne peut être figé et propose au contraire de s'adapter aux changements de ce dernier. Mais pas sans un minimum de règles.

Méthode « traditionnelle » : le cycle en V III- GESTION DE PROJET « AGILES » avec SCRUM 1- Introduction Méthode « traditionnelle » : le cycle en V Oubliez le cahier des charges, soyez agiles ! Anthony Bleton de Novius; dans la vidéo intitulée Oubliez le cahier des charges, soyez agiles ! explique très bien en quoi l'approche agile se distingue de l'approche traditionnelle.

Méthode « traditionnelle » : le cycle en V III- GESTION DE PROJET « AGILES » avec SCRUM 1- Introduction Méthode « traditionnelle » : le cycle en V Fonctionnement des méthodes agiles Les méthodes agiles partent du principe que spécifier et planifier dans les détails l'intégralité d'un produit avant de le développer (approche prédictive) est contre productif. Cela revient à planifier dans les détails un trajet "Paris - Narbonne" en voiture par les petites routes. Spécifiant chaque villes et villages traversés, l'heure de passage associée, chaque rue empruntée dans les agglomérations, litres d'essence consommés, kilomètres parcourus, etc. Les imprévus ne manqueront pas d'arriver : embouteillages, déviations, travaux, sens de circulation inversés, voire la panne, etc. Rendant votre planification et vos spécifications très vite obsolètes. Combien de temps aurez vous passé à planifier cet itinéraire, comment réagirez vous face à vos frustrations de ne pas pouvoir appliquer votre plan à la lettre ?

Méthode « traditionnelle » : le cycle en V III- GESTION DE PROJET « AGILES » avec SCRUM 1- Introduction Méthode « traditionnelle » : le cycle en V Fonctionnement des méthodes agiles L'idée consiste à se fixer un premier objectif à courts termes (une grande ville par exemple) et se lancer sur la route sans tarder. Une fois ce premier objectif atteint, on marque une courte pause et on adapte son itinéraire en fonction de la situation du moment. Et ainsi de suite jusqu'à atteindre la destination finale. On parle donc d'une approche empirique. Dans le cadre d'un projet de développement logiciel, le client élabore sa vision du produit à réaliser et liste les fonctionnalités ou exigences de ce dernier. Il soumet cette liste à l'équipe de développement, communique directement avec elle (plutôt que par papier) qui estime le coût de chaque élément de la liste. On peut ainsi se faire une idée approximative du budget global.

Méthode « traditionnelle » : le cycle en V III- GESTION DE PROJET « AGILES » avec SCRUM 1- Introduction Méthode « traditionnelle » : le cycle en V Fonctionnement des méthodes agiles L'équipe sélectionne ensuite une portion des exigences à réaliser dans une portion de temps courte appelée itération. Chaque itération inclut des travaux de conception, de spécification fonctionnelle et technique quand c'est nécessaire, de développement et de test. A la fin de chacune de ces itérations, le produit partiel mais utilisable est montré au client. Ce dernier peut alors se rendre compte par lui même très tôt du travail réalisé, de l'alignement sur le besoin. L'utilisateur final quant à lui peut se projeter dans l'usage du produit et émettre des feedbacks précieux pour les futures itérations. La visibilité ainsi offerte est clef. Cette transparence peut également apporter davantage de confiance et de collaboration dans la relation client/fournisseur. Les risques quant à eux sont levés très tôt.

Méthode « traditionnelle » : le cycle en V III- GESTION DE PROJET « AGILES » avec SCRUM 1- Introduction Méthode « traditionnelle » : le cycle en V Fonctionnement des méthodes agiles Si le client a priorisé avec soin son besoin, il peut saisir l'opportunité d'accélérer le "time to market" si il estime que le produit en l'état (partiel) peut aller en production. Économisant ainsi son budget et récoltant un premier retour sur investissement. Il a aussi la possibilité de changer en cours de route la priorité des fonctionnalités qui n'ont pas encore été développées. Afin de retarder une fonctionnalité dont le besoin n'est pas mûr, ajouter une nouvelle fonctionnalité cruciale en échange du retrait d'une autre (respectant ainsi budget et délais), etc. Cette souplesse ainsi offerte est donc un véritable atout pour le client.

Méthode « traditionnelle » : le cycle en V III- GESTION DE PROJET « AGILES » avec SCRUM 1- Introduction Méthode « traditionnelle » : le cycle en V Historique des méthodes agiles Sans rentrer dans les détails, la première chose à savoir est que l'approche Agile n'est pas un effet de mode né de la dernière pluie. En effet la première approche de gestion de projet de développement itératif date de 1986. La première mise en œuvre de la méthode Scrum (la méthode Agile la plus utilisée, documentée et éprouvée aujourd'hui) date de 1993. La seconde concerne un événement majeur rassemblant, en 2001, dix sept figures éminentes du développement logiciel pour débattre du thème unificateur de leurs méthodes respectives. De cet événement est né le Manifeste Agile rassemblant à la lueur des expériences de chacun les critères pour définir une nouvelle façon de développer des logiciels. Le terme "Agile" pour qualifier ce type de méthode est également né à cette occasion.

Méthode « traditionnelle » : le cycle en V III- GESTION DE PROJET « AGILES » avec SCRUM 1- Introduction Méthode « traditionnelle » : le cycle en V Historique des méthodes agiles Aujourd'hui ces méthodes ont fait leurs preuves. Tout le monde (dans le monde de l'informatique) ou presque a au moins entendu parler d'une méthode Agile (Scrum, Kaban, eXtreme Programming, RAD, Chrystal Clear,...). L'outillage associé est maintenant disponible sur le marché y compris dans le secteur Open Source. Les formations, certifications, conférences, livres, blogs se sont multipliés. Nous pouvons également noter la prise de position en faveur de l'approche Agile de la part des organismes faisant "autorité" en matière de gestion de projet informatique :

Les 4 valeurs du développement agile III- GESTION DE PROJET « AGILES » avec SCRUM 2- Le Manifeste Agile, un changement culturel Méthode « traditionnelle » : le cycle en V Le manifeste Agile contient l'essence et la philosophie de l'approche en question. Il illustre à lui seul le changement culturel profond qui est en jeu. Les 4 valeurs du développement agile Individus et échanges plus que processus et outils. Produit fonctionnel plus que documentation pléthorique. Collaboration du client plus que négociation du contrat. Réactivité au changement plus que suivi d'un plan. Nous reconnaissons la valeur des seconds éléments, mais privilégions les premiers.

Méthode « traditionnelle » : le cycle en V III- GESTION DE PROJET « AGILES » avec SCRUM 2- Le Manifeste Agile, un changement culturel Méthode « traditionnelle » : le cycle en V ATTENTION AUX IDÉES REÇUES La dernière phrase a son importance car si on néglige sa lecture, on peut tomber dans les idées reçues très répandues du style : "Sur un projet agile, il n'y a pas de spécifications, de plan, de processus, d'outil et même pas de contrat". Au passage, passons en revue d'autres idées reçues "Un projet Agile ne fonctionne que sur des projets de développement web, qu'avec une dizaine de personnes maximum, qu'avec des super développeurs" ou encore "sur un projet agile, le client change d'avis tout le temps et on tourne en rond à faire et défaire des choses".

Les 12 principes du développement Agile : III- GESTION DE PROJET « AGILES » avec SCRUM 2- Le Manifeste Agile, un changement culturel Méthode « traditionnelle » : le cycle en V Les 12 principes du développement Agile : Notre priorité première est de satisfaire le client en livrant au plus tôt et de  manière constante un logiciel de qualité.  Tout changement, même tardif, des exigences pendant le développement est  bienvenu. Les  méthodes  Agiles  transforment  le  changement  en  avantage compétitif pour le client.  Livrer régulièrement un logiciel fonctionnel, toutes les deux semaines à deux  mois, en préférant la plus petite périodicité.  Maîtrise d'ouvrage et développeurs doivent collaborer quotidiennement tout au  long du projet.  Bâtir le projet avec des personnes motivées. Leur donner l'environnement et le  soutien dont elles ont besoin et croire en leur capacité à accomplir le travail. La plus efficace des méthodes pour transmettre l'information au sein et à  destination d'une équipe est le face à face. 

Les 12 principes du développement Agile : III- GESTION DE PROJET « AGILES » avec SCRUM 2- Le Manifeste Agile, un changement culturel Méthode « traditionnelle » : le cycle en V Les 12 principes du développement Agile : Un logiciel qui fonctionne est le meilleur indicateur de progrès.  Les  méthodes  Agiles  favorisent  un  rythme  de  développement  soutenable. Commanditaires, développeurs et utilisateurs devraient pouvoir  maintenir ce rythme indéfiniment.  Une attention constante à  l'excellence  technique  et  à  la qualité  de la conception améliore l'agilité.  La simplicité - l'art de maximiser la quantité de travail à ne pas faire - est  essentielle.  Les  meilleures  architectures,  spécifications  et  conceptions  sont issues d'équipes auto-organisées.  À intervalle régulier, l'équipe réfléchit aux moyens de devenir plus efficace,  puis modifie et ajuste son comportement dans ce sens.

Méthode « traditionnelle » : le cycle en V III- GESTION DE PROJET « AGILES » avec SCRUM 3- La méthodologique Scrum Méthode « traditionnelle » : le cycle en V Scrum, la méthodologie la plus utilisée parmi les méthodes agiles existantes Elle est donc la plus éprouvée, documentée et supportée. On pourrait pratiquement parler d'un standard Agile. Un autre atout important : Scrum est simple à comprendre.

Méthode « traditionnelle » : le cycle en V III- GESTION DE PROJET « AGILES » avec SCRUM 4- Les rôles dans Scrum Méthode « traditionnelle » : le cycle en V Le "package" Scrum : Les rôles Scrum est considéré comme un cadre ou « framework » de gestion de projet. Ce cadre est constitué d'une définition des rôles, de réunions et d'artefacts. Scrum définit 3 rôles Le « Product Owner » qui porte la vision du produit à réaliser (représentant généralement le client). Il s'agit d'« une personne et non d'un comité ». C'est lui qui définit l'ordre dans lequel les fonctionnalités seront développées. Il prend les décisions importantes concernant l'orientation du projet.

Méthode « traditionnelle » : le cycle en V III- GESTION DE PROJET « AGILES » avec SCRUM 4- Les rôles dans Scrum Méthode « traditionnelle » : le cycle en V Le "package" Scrum : Les rôles Scrum définit 3 rôles Le « Scrum Master » garant de l'application de la méthodologie Scrum. communiquer la vision et les objectifs à l'équipe ; faciliter les rituels de scrum ; coacher l'équipe de développement ; aider l'adoption des méthodes agiles au niveau de l'entreprise ;

Méthode « traditionnelle » : le cycle en V III- GESTION DE PROJET « AGILES » avec SCRUM 4- Les rôles dans Scrum Méthode « traditionnelle » : le cycle en V Le "package" Scrum : Les rôles Scrum définit 3 rôles L'équipe de développement qui réalise le produit. L'équipe de développement est constituée de 3 à 9 personnes et a pour responsabilité de livrer à chaque fin d'itération une nouvelle version de l'application enrichie de nouvelles fonctionnalités. Elle est pluridisciplinaire et comporte toutes les compétences pour réaliser son projet, sans faire appel à des personnes externes à celle-ci.

Méthode « traditionnelle » : le cycle en V III- GESTION DE PROJET « AGILES » avec SCRUM 5- Les étapes dans Scrum Méthode « traditionnelle » : le cycle en V La Gestion de Produit Agile en deux mots! .

Méthode « traditionnelle » : le cycle en V III- GESTION DE PROJET « AGILES » avec SCRUM 5- Les étapes dans Scrum Méthode « traditionnelle » : le cycle en V Le "package" Scrum La vie d'un projet Scrum est rythmée par un ensemble d'étapes et de réunions clairement définies et strictement limitées dans le temps.

Méthode « traditionnelle » : le cycle en V III- GESTION DE PROJET « AGILES » avec SCRUM 5- Les étapes dans Scrum Méthode « traditionnelle » : le cycle en V Scrum définit 6 étapes - Vision du produit et product backlog - Planification du Sprint - Sprint - Mêlée quotidienne - Revue de Sprint - Rétrospective de Sprint

Méthode « traditionnelle » : le cycle en V III- GESTION DE PROJET « AGILES » avec SCRUM 5- Les étapes dans Scrum Méthode « traditionnelle » : le cycle en V Vision du produit et product backlog La première étape consiste à formaliser la vision du produit (logiciel) que l’on souhaite réaliser. Cette vision décrit les principaux objectifs, jalons, utilisateurs visés. Etablir la liste des exigences fonctionnelles et non fonctionnelles du produit. Chaque exigence est ensuite estimée par l’équipe de développement avec la technique de Planning Poker *. A la lueur des estimations, la liste ainsi complétée est ordonnancée. Les exigences seront converties en fonctionnalités utilisables selon cet ordonnancement. Le principe étant de convertir en premier les exigences qui apportent le plus de valeur ajoutée au commanditaire. Il s’agit donc de faire remonter les exigences fonctionnelles de la plus haute valeur ajoutée** en haut de la liste. Cette liste est appelée le Product Backlog Le changement est non seulement autorisé mais encouragé afin de pouvoir éliminer les idées de départ qui s’avéreront mauvaises et de prendre en compte les nouvelles idées qui arriveront en cours de route. Cette activité de construction du Product Backlog est collaborative, elle implique le Product Owner et l’équipe de développement

Méthode « traditionnelle » : le cycle en V III- GESTION DE PROJET « AGILES » avec SCRUM 5- Les étapes dans Scrum Méthode « traditionnelle » : le cycle en V Vision du produit et product backlog * Planning Poker Permet de mettre à profit les expériences de chacun et de parvenir rapidement à une estimation optimale et objective. Avant ou pendant les estimations, le Product Owner pourra être sollicité afin de répondre aux questions de l’équipe de développement. Déroulement Les participants s'installent autour d'une table, placés de façon que tout le monde puisse se voir. Le responsable de produit explique à l'équipe un scénario utilisateur (user story). Les participants posent des questions au responsable de produit, discutent du périmètre du scénario, évoquent les conditions de satisfaction qui permettront de le considérer comme "terminé". Chacun des participants évalue la complexité de ce scénario, choisit la carte qui correspond à son estimation et la dépose, face vers le bas, sur la table devant lui. Au signal du facilitateur, les cartes sont retournées en même temps. S'il n'y a pas unanimité, la discussion reprend. On répète le processus d'estimation jusqu'à l'obtention de l'unanimité.

Méthode « traditionnelle » : le cycle en V III- GESTION DE PROJET « AGILES » avec SCRUM 5- Les étapes dans Scrum Méthode « traditionnelle » : le cycle en V Vision du produit et product backlog ** Valeur ajoutée Exemple pour la réalisation d'un site d'e-commerce : L'unité de coût (ou complexité) de la colonne "Estimation" est arbitraire, on procède généralement par relativité en définissant un étalon de base. Par exemple, "voir le détail d'un article" étant une exigence simple, elle servira d'étalon et son estimation convenue sera par exemple de "1 point", "modifier les caractéristiques d'un article" étant 2 fois plus compliquée, son estimation sera de "2 points", etc. Le recours à une telle unité (plutôt que des jh ou €) permet de faciliter l'ordonnancement du Product Backlog, la planification des sprints et des releases. D'autre part il souligne le fait qu'il ne s'agit que d'une estimation (par définition fausse) et non pas un chiffrage en tant que tel.

Méthode « traditionnelle » : le cycle en V III- GESTION DE PROJET « AGILES » avec SCRUM 5- Les étapes dans Scrum Méthode « traditionnelle » : le cycle en V Réunion de planification du Sprint (Sprint = itération) Durée maximum : 2 heures par semaine de sprint Phase 1 : Le « Quoi » Une fois que le Product Backlog est suffisamment complet et ordonnancé, on peut planifier un sprint. Le Product Owner revoit alors avec l’équipe de développement la vision du produit, la roadmap, le plan de livraison (jalons et deadline), l’objectif du sprint et le Product Backlog. L’équipe de développement sélectionne en haut du Product Backlog les exigences qu’elle se sent capable de convertir en fonctionnalités utilisables d’ici la fin du sprint.

Méthode « traditionnelle » : le cycle en V III- GESTION DE PROJET « AGILES » avec SCRUM 5- Les étapes dans Scrum Méthode « traditionnelle » : le cycle en V Réunion de planification du Sprint (Sprint = itération) Phase 2 : Le « Comment » L’équipe de développement fait ensuite l’inventaire des tâches qui permettront de convertir les exigences sélectionnées en fonctionnalités utilisables d’ici la fin du sprint. Elle doit aller suffisamment loin dans l’effort de conception pour pouvoir vérifier sa prévision. Si elle constate après analyse des exigences sélectionnées, que sa prévision est erronée, elle peut réajuster avec le Product Owner la liste des exigences sélectionnées. Les tâches de développement sont centralisées dans le Sprint Backlog et ajoutées au tableau des tâches physique (aussi appelé Kanban). L’idéal est de parvenir à un découpage relativement fin (inférieur ou égal à une journée de travail).

Méthode « traditionnelle » : le cycle en V III- GESTION DE PROJET « AGILES » avec SCRUM 5- Les étapes dans Scrum Méthode « traditionnelle » : le cycle en V Réunion de planification du Sprint (Sprint = itération) Phase 2 : Le « Comment » Chacun peut personnaliser les colonnes de son tableau des tâches, ou code couleur des post-it..

Méthode « traditionnelle » : le cycle en V III- GESTION DE PROJET « AGILES » avec SCRUM 5- Les étapes dans Scrum Méthode « traditionnelle » : le cycle en V Réunion de planification du Sprint (Sprint = itération) Phase 2 : Le « Comment » Une fonctionnalité peut être rédigée selon le principe de la « User Story » : Courte : généralement une ou trois phrases environ. Négociable : elle peut être discutée avec l’équipe. Source de valeur : elle doit être porteuse d’une valeur pour le client ou l’utilisateur. Indépendante des autres histoires d’utilisateur. Estimable : elle peut être estimée par l’équipe de réalisation avec un risque d’erreur faible. D’une taille appropriée : sa taille doit être relativement petite afin de faciliter son estimation.

Méthode « traditionnelle » : le cycle en V III- GESTION DE PROJET « AGILES » avec SCRUM 5- Les étapes dans Scrum Méthode « traditionnelle » : le cycle en V Sprint Durée de 2 à 4 semaines Au cours du Sprint, l’équipe se concentre sur l’accomplissement des tâches du Sprint Backlog. Le but est de développer les fonctionnalités de bout en bout (de la conception aux tests) au fil de l’eau au cours du sprint. Autrement dit d’éviter un mini cycle en V au sein du sprint. Le tableau des tâches physique rempli de post-it est pratiquement indispensable. Il permet d’avoir une vision claire du travail à accomplir, en cours et terminé. Il peut également s’avérer précieux lors des réunions quotidiennes. Le tableau facilite également l’affectation des tâches par l’équipe en ayant une vision d’ensemble du sprint en un coup d’œil. Il faut se détacher d’une approche prédictive et des diagrammes de Gantt. Ce sont les développeurs qui « tirent » les tâches et non pas le Scrum Master qui les affecte.

Mêlée quotidienne ou « stand-up meeting » Durée maximum : 15 minutes. III- GESTION DE PROJET « AGILES » avec SCRUM 5- Les étapes dans Scrum Méthode « traditionnelle » : le cycle en V Mêlée quotidienne ou « stand-up meeting » Durée maximum : 15 minutes. Cette réunion qui se fait debout. Elle permet quotidiennement aux membres de l’équipe de se synchroniser, de remonter les obstacles rencontrés, de s’entraider, de vérifier l’avancement du sprint. Elle contribue également à faire naître l’esprit d’équipe. Chaque personne répond à 3 questions : Qu'ai-je fait hier qui a aidé l'équipe de développement à atteindre l'objectif Sprint ? Que vais-je faire aujourd'hui pour aider l'équipe de développement à atteindre l'objectif Sprint ? Est ce que je vois des obstacles susceptibles de m'empêcher ou d'empêcher l'équipe de développement d'atteindre l'objectif du Sprint ?

Méthode « traditionnelle » : le cycle en V III- GESTION DE PROJET « AGILES » avec SCRUM 5- Les étapes dans Scrum Méthode « traditionnelle » : le cycle en V Mêlée quotidienne ou « stand-up meeting » Durée maximum : 15 minutes. Le Scrum Master est ainsi immédiatement au courant des obstacles rencontrés, il doit impérativement les prioriser, les suivre et bien sûr s’efforcer de les lever au plus tôt afin de garder l’équipe pleinement concentrée et productive. La mêlée quotidienne se déroule à lieu et heure fixes (devant le tableau des tâches physique de préférence) déterminés par l’équipe de développement. Au début le Scrum Master peut avoir à rappeler qu’il est l’heure de la mêlée et animer cette dernière en rappelant les 3 questions et évitant l’instruction des problèmes ou obstacles en séance afin de ne pas dépasser les 15 minutes imparties. L’objectif du Scrum Master consiste cependant à viser l’appropriation de la mêlée par l’équipe de développement.

Méthode « traditionnelle » : le cycle en V III- GESTION DE PROJET « AGILES » avec SCRUM 5- Les étapes dans Scrum Méthode « traditionnelle » : le cycle en V Revue de Sprint Durée maximum : 1 heure par semaine de sprint Fréquence : A la fin de chaque sprint. L’objectif de la revue de sprint est d’inspecter l’incrément produit au cours du sprint écoulé, faire un point sur l’avancement de la Release et adapter au besoin le plan et le Product Backlog. L’équipe de développement présente à tout acteur projet intéressé (à minima le Product Owner idéalement accompagné d’utilisateurs finaux) les nouvelles fonctionnalités développées au cours du sprint. Le Product Owner donne un feedback à l’équipe de développement, il accepte ou refuse les fonctionnalités présentées. L’équipe de développement calcule sa vélocité en additionnant les points d’estimation associées aux fonctionnalités acceptées. Une fonctionnalité partiellement terminée ne rapportera aucun point car une telle fonctionnalité n’est pas utilisable. La vélocité ainsi calculée va permettre de mettre à jour le graphique d’avancement de Release et de vérifier l’avancement de cette dernière. C’est l’occasion de vérifier que le nombre de sprints de la Release demeure adapté ou non.

Méthode « traditionnelle » : le cycle en V III- GESTION DE PROJET « AGILES » avec SCRUM 5- Les étapes dans Scrum Méthode « traditionnelle » : le cycle en V Rétrospective de sprint Durée maximum : 45 minutes par semaine de sprint Fréquence : A la fin de chaque sprint. La rétrospective qui a généralement lieu après la revue de sprint est l'occasion de s'améliorer (productivité, qualité, efficacité, conditions de travail, etc) à la lueur du "vécu" sur le sprint écoulé (principe d'amélioration continue). Tous les domaines peuvent être abordés en rétrospective : humain, organisationnel, pratiques, processus, outillage, qualité de vie au travail, conflits, interactions avec le métier. Le compte rendu de la dernière rétrospective, les graphiques d’avancement de sprint et release, les événements du sprint, les feedbacks de la revue de sprint sont autant d’éléments qui alimentent les conversations

Méthode « traditionnelle » : le cycle en V III- GESTION DE PROJET « AGILES » avec SCRUM 5- Les étapes dans Scrum Méthode « traditionnelle » : le cycle en V Graphique d’avancement (Burndown Chart) Pour connaître votre avancement, vous allez avoir besoin de tracer le Burndown Chart du sprint en cours. Ce graphique est simple, il s’agit du tracé de la charge de travail restante (généralement en heures) en fonction du temps (en jours). Pour tracer ce graphique, il suffit de mettre à jour (lors de chaque mêlée quotidienne par exemple) le sprint backlog Exemple de Sprint Backlog Exemple de Burndown Chart de Sprint

III- GESTION DE PROJET « AGILES » avec SCRUM Conclusion Méthode « traditionnelle » : le cycle en V Aller plus loin : Scrum et XP depuis les Tranchées Méthodes Agile en action

Méthode « traditionnelle » : le cycle en V III- GESTION DE PROJET « AGILES » avec SCRUM 6- La contractualisation agile Méthode « traditionnelle » : le cycle en V La contractualisation agile La contractualisation d'un projet agile n'est pas la partie la plus facile étant donné que le périmètre est par définition variable. En France et ailleurs, le contrat au forfait domine; surtout sur les gros projets. Malheureusement pour le fournisseur - dans le cadre d'un forfait classique - tous les risques sont pour lui (aussi bien sur un projet agile que sur un projet traditionnel). On peut limiter ces risques en prenant quelques précautions, mais on limite également la souplesse offerte par une approche Agile. La forfaitisation de chaque itération avec la possibilité pour le client d'arrêter le contrat à la fin de chaque itération est assez intéressante. Ainsi que le principe de troc d'exigence : réalisation d'une exigence imprévue en échange du retrait d'une autre moins importante, de priorité faible et de même coût.