Les bonnes pratiques issues de l'agilité que vous pouvez appliquer dans un contexte traditionnel
From Transitionagile
(Created page with 'Ci-dessous, voici un ensemble de points qui me semblent apporter de réels gains à la gestion de projet, à appliquer au mieux en fonction du contexte, du type de projet… ==…')
Current revision as of 20:01, 28 September 2010
Ci-dessous, voici un ensemble de points qui me semblent apporter de réels gains à la gestion de projet, à appliquer au mieux en fonction du contexte, du type de projet…
Contents |
Découpage et méthodo pragmatique, privilégiant le résultat à la doc, orga opérationnelle
Cycles courts / des résultats opérationnels au bout d’un mois Un passage immédiat au concret, avec documentation seulement en final (sinon, on doit faire évoluer la doc à chaque évolution ou retouche fonctionnelle) Un travail en binôme utilisateur / développeur (versus chacun en tribu de son côté). Une qualité renforcée par le pair programming (a priori versus a posteriori) Les Test driven développement avec automatisation des tests (pour détecter les régressions) L’apprentissage de la vélocité (points de fonction). L’analyse de la valeur comme principe de planification des itérations Le prototypage dès le premier mois des fonctions à fort risque / enjeu (évite de découvrir le problème après 10 mois). La clarification des rôles Métier : ambassadeur, visionnaire, sponsor, chef de projet, utilisateur. Le référentiel des exigences pour suivre leur évolution dans le temps Utiliser des métaphores pour réduire les incompréhensions dans l’analyse fonctionnelle. Intégration continue des livraisons.
Equipe, état d’esprit, culture
Etat d’esprit collaboratif + que client fournisseur, collégial plus qu’individualiste Un lieu une équipe réduite, maléable Rétrospective meeting : réunions d’équipe pour faire le point sur le processus de travail en équipe et s’améliorer / Debriefer sur le plan et le processus de travail : était-ce le bon plan, le bon processus ? La confiance réciproque, liberté d’expression, sécurité personnelle des participants Le droit à l’erreur : reconnaître ses erreurs, autoriser l’erreur des autres La délégation : être humble, marquer confiance et respect, reconnaître le droit à l’erreur, réfléchir sur les bénéfices (liberté, sérénité) de l’apprentissage (auto-gestion de l’erreur) et l’autonomie de l’équipe. Encourage et donne signe de reconnaissance. Gérer sa hiérachie (manage-up) et protège son équipe. Rôle de facilitateur du chef de projet, du Scrum... mise en avant de l’équipe solidaire L’idée de commencer le projet avec des défricheurs (équipe expérimentée) avant d’introduire des novices (applicable en dehors des méthodes agiles). Principes d’amélioration continue de l’équipe : apprendre, enrichir, s’améliorer pour être plus efficace Travail sur les attentes de chacun vis-à-vis des autres Faire travailler l’équipe sur ses valeurs, ses rites (www.thierrycros.net).
Management, coordination et pilotage
Des objectifs SMART : spécifiques, mesurables, acceptables, réalistes, situés dans le temps. Un tableau scrum / kanban avec les stades fonctionnels (à faire, prioritaire, en cours, test, recetté, terminé) avec un maxi par stade du workflow afin d’éviter engorgement. Le recours au face à face à la place du recours systématique au mail (parapluie) Le brundown chart / burnup chart Le sprint planning meeting Daily stand-up meeting Suivi du planning des livraisons (résultats) au lieu de suivre la mise en oeuvre des tâches (moyens) Le tableau de bord qualité avec analyse des problèmes rencontrés (luxe, gaspillage, bogue, régression, non conformité) et non la seule qualification de la gravité des anomalies (bloquante / mineure) Typologie des risque PMBOK Actions de réduction des risques : évitement, transfert, réduction de probabilité, acceptation, surveillance Analyse de la valeur acquise PMBOK Technique des points de fonction PMBOK Gestion par les risques en commençant par les fonctions à plus gros risque et en faisant gérer les risques par l’équipe La distinction entre la «formation» (le formateur forme) et l’apprentissage (les stagiaires apprennent)... La distinction entre le type d’anomalie (bogue, régression, non conformité, gaspillage...) et leur gravité (bloquant...). Le recours systématique au REX / rétrospective de fin de période en séance collective lors de chaque itération MADA : le plan était-il bon, l’objectif SMART, les ressources adaptées... peut-on s’améliorer ?? Bonnes et mauvaises pratiques, bilan du processus de fonctionnement de l’équipe, origine des anomalies et des dysfonctionnements de l’équipe = amélioration continue, principes du LEAN. Fixer des itérations de dates et durées fixes, avec un contenu adaptable (permet de n’afficher que le succès : design to cost). Auto-apprentissage de l’équipe sur sa vélocité, itération après itération (XP game). Axes de pilotage : PCRPQR / satisfaction client / satisfaction équipe QCM anonyme : sur planning, esprit d’équipe, mode de fonctionnement, amélioration…
Facteurs clés de succès
Agilité préconisée pour les projets complexes sur lesquels il faut rapidement lever les principaux risques (prototypage), projets mono-sites, équipe dédiée, ROI clair / fonctions, rôle essentiel de l’ergonomie, contexte incertain, innovant, besoins instables. L’agilité n’implique pas une baisse du coût et des délais, mais une baisse du risque coût / délai.
Quelques erreurs à éviter parmi d’autres
(glanées dans la littérature et confirmés par ma propre expérience) : • sous utilisation des rétrospectives sur le fonctionnement de l’équipe • incapacité à réunir l’équipe aux réunions de planification, aux daily stand-up meetings... • que le Scrum ou coach XP ne laissent pas l’équipe décider • que le product owner soit indisponible, voire incapable de décider, trancher, prioriser... • que les test soient trop tardifs ou secrets (jalousement conservés par les utilisateurs) • désengagement de la hiérarchie (chèque en blanc) • foncer sur la solution en se trompant de problème (ex. 1 ou 2 factures / besoin de préparer la clôture comptable au fil du mois, de remettre en banque....) • sur-staffer l’équipe par peur de décider seul (une équipe plus conséquente est lourde à manier, ralentit le rythme). • dysfonctionnement de l’équipe par absence de confiance, recherche de coupables (divise), peur du conflit (mise à plat, nettoyage du problème), manque d’implication, fuite devant les responsabilités, manque d’intérêt pour le résultat. • oublier de travailler sur les attentes de chacun vis-à-vis des autres.
