Méthodes Agiles

Introduction

L'objectif de la gestion d'un projet en mode agile est la maîtrise de celui-ci, au lieu de subir les délais, le budget, la finalisation, comme on peut le voir si souvent. Cela passe par l'optimisation de la productivité et de la qualité qu'apportent les méthodes agiles.

Chaque projet est un nouveau projet, malgré les idées reçues qui pensent le contraire : nouveaux hommes, nouvelles techniques et technologie, nouveau fonctionnel.

Selon des études effectuées sur les projets, on se retrouve souvent avec un facteur 2 sur l'estimation initiale en nombre de jours, le % de changement d'exigences (fonctionnalités) peut aller jusqu'à 50 %. Parmi les fonctionnalités offertes dans un produit, on a la répartition suivante :

  • + de 45 % ne sont pas utilisées
  • 19 % rarement
  • 16 % parfois
  • 13 % souvent
  • 7 % toujours

De ces constats, des méthodes ont été développées (selon un manifeste qui, sur 4 principes, détermine les grands principes de l'agilité), afin de penser autrement la gestion des projets : Scrum, inventée en 1992, XP en 1998.

Principes agiles

Avec la méthode Scrum, une itération va de 2 à 4 semaines (appelée Sprint), la date de sortie est fixe (timeboxing) : fourniture d'un produit partiel, potentiellement utilisable. Approche agile : modèle empirique vs prédictif (méthodes traditionnelles).

Une mêlée (le scrum) quotidienne est organisée : ne dure pas plus de 1/4 d'heure et se déroule debout, commence à l'heure et finie à l'heure, chaque membre parle, avec bienveillance, et répond à 3 questions : "qu'as-tu fait hier ?", "quelles difficultés as-tu rencontrées ?", "que feras-tu aujourd'hui ?".

Un backlog (liste de fonctionnalités macroscopiques) est déterminé, chacune des fonctionnalités sera priorisée (selon la valeur apportée à l'utilisateur) afin de respecter le timeboxing (découpe du projet en itérations de durée fixe). Bien entendu le backlog peut évoluer afin de s'adapter au contexte (retard éventuel, besoins moins prioritaires, ...), la variable d'ajustement pour tenir la date devient alors les besoins (les réduire in fine, d'où la priorisation). Tout ceci afin d'éviter l'effet tunnel, propre aux méthodes dites traditionnelles (V, cascade, etc.), et également une meilleure gestion de la pression, on ne subit plus, on gère et maîtrise le projet : l'équipe est canalisée sur les fonctionnalités à produire, celles-ci ayant été retenues pour l'itération de façon raisonnable, on s'engage à leur réalisation, la qualité s'en trouve alors améliorée (ie: on ne finalise plus des fonctionnalités à la va-vite).

L'évaluation de la charge des fonctionnalités est comptée en nombre de points et non en nombre de jours. On parlera alors de product burndown chart, le reste à faire en termes de points de fonctionnalités. La vélocité d'une équipe correspond à sa capacité dans une itération à réaliser N points de fonctionnalités, cette vélocité est affinée à chaque itération, on arrive au fur et à mesure à connaître combien de points on peut réaliser en 4 semaines. De là, on peut s'engager sur un nombre de fonctionnalités à réaliser, on devient responsables et impliqués. Dans les méthodes dites traditionnelles, on pense à l'envers : à la date T, on doit tout faire (que le besoin soit réel ou non...), absolument tout pour tenir coute que coute la date, et non en termes de jours (ie : voyons en 4 semaines ce que l'on peut développer, l'utilisateur décidera des fonctionnalités à X points à développer dans cette itération, et même si on sait qu'on ne tiendra pas, on descope : on réduit les exigences).

Maîtrise des projets

Il y a 4 manières de maîtriser un projet, les 3 1ères étant le réflexe des anciennes méthodes, la 4ème la bonne pratique (et de bon sens), issue de l'agilité :

  1. par le temps : décaler la mise en ligne par exemple, et ...doubler le délai de livraison : on augmente le temps, d'où avenant, d'où perte de confiance de chaque partie (MOA / MOE), et les parapluies commencent à s'ouvrir bien souvent,
  2. par les ressources : rajouter à une équipe déjà en retard, des développeurs supplémentaires : il est prouvé que cela donne l'effet inverse, car les nouveaux développeurs seront à former du point de vue fonctionnel et technique,
  3. par l'abandon des bonnes pratiques de développement (refactoring, tests, ...), on est en retard alors on "pisse" de la ligne, la qualité s'en trouve affectée, désastre bien entendu pour la "maintenabilité" du projet,
  4. par la réduction des fonctionnalités : soyons raisonnables, on sait que l'on ne pourra pas tout développer à la date T, alors réduisons le périmètre fonctionnel. La date de fin de l'itération étant fixe, il n'y a pas d'autres moyens que de retirer ou de rajouter (si on est en avance...) des fonctionnalités

A chaque fin d'itération (fin des 4 semaines), on effectue un bilan de celle-ci, afin de réajuster la vélocité de l'équipe (nombre de points développés), on capitalise alors sur le savoir-faire, et l'équipe apprend à se connaître.

La pression nous l'avons toujours mais elle est maîtrisée. Il vaut mieux une petite pression à chaque fin d'itération, en ajustant selon les besoins de l'utilisateur qu'une grosse à la fin de plusieurs mois, où le chaos s'installe bien souvent, parce qu'on n'a pas compris ce que voulait l'utilisateur, et là, chacun se dé-responsabilise, les parapluies s'ouvrent, les mails pleuvent...Chaque partie prenante rejette la faute sur l'autre.

La MOA, de peur de se tromper, à l'habitude d'en mettre souvent plus dans son cahier des charges, trop, bien souvent ("on ne sait jamais si j'oubliais quelque chose", "pourvu que je n'oublie rien", ...). Le cahier des charges COMPLET est une UTOPIE, on procède à beaucoup de conjectures, d'hypothèses sur les éventuels futurs besoins des utilisateurs, dur en effet dans ce cas d'avoir confiance et d'être dans une collaboration, on en vient à être plus dans une relation trop contractuelle (le contrat protège, rassure dans l'imaginaire des personnes). Tout cela n'est pas être agile.

C'est pourquoi les contrats au forfait sont une catastrophe, on privilégiera le co-sourcing (régie), ou des équipes mixtes sur le site client.

Être agile :

  • utilisateur et MOA : nous savons ce que nous voulons en 1er,
  • itérations courtes pour un feedback le plus tôt possible,
  • privilégier la communication directe, éviter les relais, où 50 % de l'information est perdu. On évitera de trop envoyer des mails, notamment, le mail qui dé-responsabilise, en renvoyant l'autre soi-disant à ses responsabilités, non, c'est faut, on se protège ainsi soi, on casse l'esprit collaboratif,
  • intégration continue : l'ensemble du projet compile et s'exécute,
  • livrer plus de valeurs aux utilisateurs : fonctionnalités essentielles, les plus simples,
  • tests (approche TDD, les maintenir), refactoring du code,

Comment démarrer un projet agile ? l'acquisition d'une démarche agile implique :

  • d'énormes changements d'habitudes et de mentalité,
  • de ne plus penser par le consommé, mais ce qui reste à faire,
  • de commencer à développer tout de suite,
  • sortir du mode de recherche du bouc émissaire (la culture du blâme très courante dans notre culture française),

Commencer par une 1ère itération : se faire aider par un coach externe, se former, d'avoir un mentor technique (tests, refactoring, ...bonnes pratiques à mettre en place).

Livres conseillés

Projets offshore et agilité

Un projet offshore s'organise selon 2 équipes : le frontoffice (fonctionnel, tests, en local, proche du client) et le backoffice (conception/développement, délocalisé à Bangalore par exemple, on trouvera un Technical leader qui coach des équipes de dév/conception), un coordinateur est nécessaire pour faire le pont entre les 2.

Différents rôles

Selon les principes de l'agilité, le CP a plusieurs missions :

  • insuffle l'esprit d'équipe en rassemblant et non en divisant,
  • est solidaire avec l'équipe,
  • rappel et porte l'objectif du projet,
  • est localisé sur le lieu de l'équipe projet

le coordinateur qui a également des compétences en gestion de projet :

  • pont entre les équipes distantes,
  • rôle transversale clé (compétences en CP, bon relationnel, bonne communication),
  • des outils seront utilisés, tel qu'un Wiki,
  • travail tous les jours avec les équipes

on trouvera parmi les différents rôles du projet, le champion fonctionnel qui passera des spécifications au product backlog, mènera les discussions en face à face. Le technical leader est le référent technique, et coach une équipe de développeurs, ses compétences sont multiples :

  • bon technicien,
  • développeur confirmé,
  • encadre techniquement l'équipe,
  • s'assure que chaque développeur est capable de faire son travail,
  • fera la revue de conception/code,
  • pair programming si besoin,
  • collabore avec le team leader

Le multi-sites enlève tout l'implicite que l'on peut retrouver dans une structure localisée au même endroit : machine à café, copinage, réseau, culture d'entreprise. Aussi, la communication s'en trouve plus difficile, le temps de réaction augmente, les conflits d'intérêts apparaissent, les cultures s'entrechoquent .

Ces derniers points ont des impacts sur le projet :

  • perte de confiance : ce qui amène plus de contrôle, au lieu d'une collaboration basée sur le feedback,
  • creuse le fossé entre les personnes,
  • dissolvent l'esprit d'équipe

Motivations d'un mode offshore

On trouvera plusieurs intérêts à ce mode de développement :

  • augmentation de la capacité de production (ie : moins cher donc plus de développeurs disponibles),
  • intérêt économique,
  • valorisation des équipes actuelles vers d'autres fonctions,
  • recentrage vers des activités métiers

Quelques règles de base dans ce mode de fonctionnement :

  • garder en local les activités trop complexes,
  • éviter d'expérimenter et favoriser les activités maitrisées,
  • tenir compte des différences de formations et d'expérience,
  • être réactif et utiliser le décalage horaire

Afin de mettre en place la conduite du changement, la direction doit communiquer pour conter les idées reçues, également le management a sa part de travail.

Raisons majeures des échecs des projets offshore

Côté décideur :

  • espoir irréaliste de gains de coûts au lieu d'une stratégie à long terme,
  • absence de plan B en cas d'échec,
  • absence de contrat ou flou sur les engagements

Côté gestion de projet :

  • organisation projet mal définie,
  • manque de visibilité,
  • vision projet non partagée,
  • manque de motivation des équipes => provoquera un turnover important,
  • manque d'outils de type Wiki

Facteurs de succès

  • affaire d'Hommes avant tout,
  • définir clairement les rôles et responsabilités de chacun (matrice RACI),
  • gérer rigoureusement les exigences (=> product backlog),
  • estimer et mesurer fréquemment (vélocité, le burn down chart, itération du backlog),
  • apprendre à connaître l'autre

Slides en ligne

Les présentations fournies par les intervenants :