5 idées fausses à propos des Méthodes Agiles

La grande diversité des méthodes agiles et de leur pratique génère de nombreuses idées fausses à leur sujet. L’objet de cet article est de démystifier les idées fausses les plus courantes trouvées dans les débats sur le Web en y répondant factuellement.

L’arrivée des Méthodes Agiles est en train de générer un fossé entre leurs partisans et ceux des méthodes traditionnelles. Cette rupture est renforcée par le fait que les 4 principes fondateurs des méthodes agiles sont des contre-pieds vis à vis de l’approche classique:

  1. Individuals and interactions over processes and tools
  2. Working software over comprehensive documentation
  3. Customer collaboration over contract negotiation
  4. Responding to change over following a plan

(cf. le Manifeste Agile, site officiel: http://agilemanifesto.org/)

L’idée ici n’est pas de prendre parti pour les méthodes agiles contre l’approche classique. Chez Time Performance, nous pensons que chaque approche peut être bonne ou moins bonne selon le contexte.

Idée fausse n°1: Les Méthodes Agiles sont réservées aux « petits » projets

Faux, faux et archi-faux… C’est pourtant l’idée la plus répandue. C’est aussi la plus fausse.

1) Les Méthodes Agiles ont pour raison d’être de permettre au projet de s’adapter facilement aux changements (« Reponding to change.. »). Cela n’a de sens que pour les projets de durée plutôt longue, car le risque de changement est d’autant plus fort que le projet s’éternise. De plus, la durée est nécessaire pour rentabiliser l’investissement lourd qui est fait dans les tests, leur automatisation et la qualité du code, qui sont au coeur des méthodes agiles.

D’ailleurs les méthodes Agiles ont été conçues pour le développement de produit logiciel (d’où le terme de Product Owner qu’on trouve dans SCRUM), dont la durée de vie s’étend sur plusieurs années voir plusieurs décennies.

Cette idée fausse a peut-être été inspirée par la brièveté des cycles de développement. Or un développement itératif a pour but d’éviter le risque d’effet tunnel, qui est d’autant plus important que le projet est long.

Donc les méthodes Agiles sont particulièrement adaptées, voire recommandées, pour les projets de longue durée et non pour les projets courts.

2) Concernant la taille de l’équipe, il est vrai que SCRUM limite la taille des équipes à 8 ou 9 individus, et XP le recommande en pratique, car c’est le fonctionnement optimal. Mais rien n’interdit de constituer plusieurs équipes qui travailleront chacune sur un sous-projet. D’ailleurs SCRUM le prévoit avec un mécanisme de coordination qui s’appelle le SCRUM de SCRUMs. Une équipe de plusieurs dizaines de personnes peut être ainsi constituée.

Idée fausse n°2: La classification « Méthode Agile » détermine un groupe homogène

Les méthodes Agiles sont très différentes les unes des autres. Elles sont même parfois presque totalement complémentaires, comme XP et SCRUM. Si ces 2 dernières méthodes marquent une réelle rupture par rapport à l’approche classique, certaines comme le Unified Process constituent des chaînons intermédiaires de l’évolution des méthodes au cours des 20 dernières années.

Toutes ces méthodes ne s’entendent que sur les 4 principes, ce qui est peu. De plus, le Manifeste Agile offre certaines latitudes en matière d’interprétation. Il est donc hasardeux de parler des Méthodes Agiles en général. Il vaut mieux parler des pratiques proposées par telle ou telle méthode.

A cela, il faut ajouter que les mises en oeuvre de ces méthodes sont encore plus hétéroclites.

Idée fausse n°3: Les Méthodes Agiles sont des méthodes de gestion de projet

Cette partie a été réécrite suite au débat né avec les nombreux commentaires ci-dessous afin de préciser les arguments. Si cette idée est vraiment fausse, comme nous le croyons, elle semble difficile à combattre 😉 .

L’objet principal des méthodes agiles est le processus de développement (logiciel) depuis la définition du besoin jusqu’à la livraison d’un produit. Ceci est attesté par le Manifeste Agile qui représente l’âme de ces méthodes et qui commence par Nous découvrons comment mieux développer des logiciels… (source manifeste agile).

La notion même de projet n’est pas requise pour utiliser SCRUM ou XP. Ce qui compte dans ces méthodes, c’est le développement d’un produit. Or on peut développer un produit en dehors du cadre formel d’un projet et utiliser SCRUM ou XP.

Si une méthode agile est utilisée sur un projet, cela ne remplace pas la mise en place d’une vraie gestion, ne serait-ce qu’au niveau des coûts. Il y a plusieurs autres domaines non couverts par l’agilité: l’établissement d’un cas d’affaire (business case), la gestion des parties prenantes, la gestion des risques, la conduite du changement, les phases amont et aval d’un projet…

Notons que cette idée fausse n’existe pas dans le monde anglo-saxon. Nous n’avons pas trouvé d’exemple parmi toutes les vidéos disponibles sur Internet ou dans des articles en anglais où SCRUM était présenté comme « a project management method » ou « a project management framework ». Amusant, dans la traduction en français du manifeste agile, le principe Welcome changing requirements, even late in development est devenu Accueillez positivement les changements de besoins, même tard dans le projet plutôt que même tard dans le développement. Bizarre, non ?

Idée fausse n°4: Les Méthodes Agiles sont des méthodes de développement rapide ou de prototypage

Des cycles de livraison courts ne signifient pas que les développements sont rapides. Cela implique simplement de valider l’avancement régulièrement et concrètement.

Il y a même fort à parier que les développements seront moins rapides au départ par rapport à un cycle en V, à cause des exigences en matière de qualité de code et de couverture de tests, incluant de nombreux refactorings (redéveloppements). Ce n’est donc pas une bonne approche pour faire du prototypage.

Les projets Agiles sont des marathoniens et non des sprinters. C’est pourquoi ils voyagent légers. Et sur la distance, ils sont en général les plus rapides et consomment moins.

Idée fausse n°5: Les développements agiles sont difficilement maintenables à cause du manque de documentation

La crainte de voir la connaissance du fonctionnement du logiciel partir avec les développeurs à l’issue du projet est parfaitement légitime lorsque la documentation est insuffisante.

Cependant c’est une erreur de considérer qu’il n’y a pas de documentation. A l’instar de l’Open Source, dans une approche Agile, la principale documentation est le code source. Et comme de nombreuses livraisons sont réalisées tout au long du projet, tout est fait pour garantir une parfaite maintenabilité.

D’une part, les règles de codage sont très strictes et leur validation automatisée. Plusieurs pratiques au coeur des méthodes Agiles (le refactoring,  l’absence de Code Ownership, le Pair Programming etc.) garantissent au final un code source propre, bien conçu, lisible et bien documenté.

D’autre part, dans code source il faut inclure les tests (unitaires, intégration, fonctionnel etc.). Les tests sont comme un document de spécifications détaillées et un outil de validation intégrés. C’est un investissement non négligeable mais indispensable pour la maintenabilité et l’évolutivité.

Dans une approche agile, le code source et les tests tiennent lieu respectivement de conception détaillée et de spécification détaillée, exprimées en langage naturel dans les commentaires et en langage informatique. Le gros avantage est de garantir que la documentation est toujours à jour par rapport au code, et que le code reste conforme aux spécifications grâce à l’exécution quotidienne des tests avec l’intégration continue. Un développement agile devrait donc être très facile à maintenir.

En réalité, la vraie question est: « Entre une documentation complète (spécification, analyse, conception etc.) et un code source propre et bien testé que choisiriez-vous? »

Les méthodes agiles donnent la priorité au code source et aux tests. Le cycle en V favorise dans la pratique les documents qui sont générés en amont du projet, au détriment du code et des tests situés en aval du cycle lorsque la pression pour aller vite, trop vite, est beaucoup plus forte.

Cet article a maintenant une suite: 5 autres idées fausses sur les Méthodes Agiles

Version 2.4

Cette version introduit les nouveautés suivantes:

  • Le Panneau des tâches (cf image ci-dessous)Le panneau des tâches permet de visualiser le travail en cours. C’est un outil de la méthode SCRUM où il est utilisé quotidiennement lors du daily scrum.

    Les tâches pour une itération (sprint) donnée sont regroupées en lignes par objectif (user story) et en colonne par statut: A faire, En cours et Terminé.

    L’utilisation de TimePerformance permet d’automatiser la mise à jour du tableau et de remplacer la manipulation de Post-it volants.

  • Ecran de recherche sur les tâchesUn nouvel écran permet de faire des recherches sur les tâches en fonction de plusieurs critères (objectifs, itération, statut, personnes assignées etc.) et de faire une extraction en format CSV (compatible Excel).
  • Réorganisation des rubriques du tableau de bordLes différents éléments du tableau de bord ont été réordonnés pour être regroupés en 4 groupes: Synthèse du Plan, Gestion de l’équipe, Suivi du Projet, Suivi des évolutions.

Panneau des tâches (de SCRUM)

diagramme temps-temps ou courbe à 45 degrés

Gestion des Coûts et Projets Agiles (la vidéo)

En bonus voici la vidéo des 10 premières minutes de la conférence sur la Gestion des Coûts et les Projets Agiles animée par Renaud Choné lors de l’Agile Tour 2009.

Continuer la lecture de « Gestion des Coûts et Projets Agiles (la vidéo) »

Diagramme Temps-Temps ou Courbe à 45 degrés

Le diagramme temps-temps, ou courbe à 45°,  est indispensable lorsqu’il y a eu plusieurs versions du planning pour suivre les évolutions des dates des jalons.

En anglais, ce diagramme s’appelle le milestone slip chart.

diagramme temps-temp ou courbe à 45 degrés

Les éléments du diagramme

Chaque courbe représente les évolutions de la date d’un jalon au cours du temps.

La droite en rouge clair d’équation X=Y représente l’intersection entre la planification et le présent. C’est la droite à 45°. Elle marque la séparation entre le prévu (à gauche de la droite à 45°) et le réalisé (à droite).

Les droites en pointillés rappellent la planification de référence (baseline) des jalons.

Interprétation du diagramme

Dans notre exemple:

Le Jalon 1 correspond au cas idéal sans replanification ni retard, donne une simple droite.

Le Jalon 2 correspond au cas où il y a eu un retard de 15 jours (29 septembre au lieu du 14 septembre). La courbe glisse sur la droite à 45° jusqu’à la clôture du jalon.

Le Jalon 3 montre le cas où il y a eu une replanification (suite au retard sur le jalon 2)

Le Jalon 4 montre le cas de 2 replanifications successives à 2 mois d’intervalle.

Ce diagramme est automatiquement généré par le logiciel TimePerformance.

Version 2.2

Cette version propose les améliorations suivantes:

  • Le diagramme temps-temps ou courbe à 45° (cf image ci-dessous)

    Ce nouveau diagramme permet de visualiser l’historique des dates des jalons: la planification de référence, les replanifications, les dépassements et la date de réalisation. Ce diagramme est connu en anglais sous le nom de milestone slip chart. Il peut aussi être représenté dans l’autre sens où le temps est en X et les dates des jalons en Y.

  • Possibilité de s’identifier au choix avec un nom de compte TimePerformance ou son identifiant client.

    Pour les clients qui n’ont pas eu cette option au moment de la souscription et qui souhaiteraient en bénéficier, merci de contacter notre support pour choisir le nom.

Version 2.1

Cette version propose les améliorations suivantes:

  • Feuille de Temps: possibilité de saisir les consommés dans une feuille de temps classiqueCette feuille de temps peut être utilisée conjointement à la liste de tâche ou indépendamment. Elle peut notamment permettre de corriger des valeurs ou faire un rattrapage rapide. Son utilisation est ultra simple, il suffit de cliquer sur la case et de saisir la valeur directement dans le tableau.
  • Possibilité de rouvrir une tâche close ou annuléePour corriger une erreur de clic…
  • Améliorations diverses: obtenir les détails d’une tâche non assignée, période de travail < 5 sec. ignorée, ouverture des éléments (objectifs, itération…) en un clic sur le nom.

Feuille de Temps

feuille de temps

Version 2.0

Cette nouvelle version majeure de TimePerformance introduit les premières fonctionnalités transversales par rapport aux projets:

  • Gestion de la structure de l’organisation (appelée aussi OBS)Les utilisateurs peuvent être rattachés à un service ou une direction. TimePerformance permet de gérer une structure hiérarchique de services et de sous-services. Les utilisateurs peuvent être responsables de service. La première application est la création du rapport mensuel d’activité du service (cf. point suivant).
  • Création d’un rapport mensuel d’activité pour service.Grâce à ce nouveau rapport, les responsables de services ou de département peuvent visualiser l’activité cumulée en coût et en charge de leurs collaborateurs par projet pour un mois donné. (cf. image ci-dessous)
  • Gestion de droits administrateur pour les méthodes.A la manière d’un wiki, les méthodes représentent un savoir collectif. C’est pourquoi dans TimePerformance les méthodes sont partagées et définies par tous ou presque. Cependant, afin d’éviter des erreurs de manipulation irréversibles, les administrateurs d’une méthode sont les seuls à pouvoir supprimer et restructurer ses éléments. L’ajout et l’édition continuent à ne pas nécessiter de droits particuliers.
  • Amélioration du formulaire de création des tâches avec notamment la possibilité de rattacher la tâche au plan à partir de la feuille de route.
  • Nombreuses améliorations d’ergonomie pour la planification, le filtrage des objectifs clos, accès à la feuille de route à partir de la liste des tâches etc.
diagramme de la valeur acquise avec la prévision de coût

Question sur les rôles de Product Owner et de Scrum Master

question_markDans la méthode SCRUM, il n’y a plus de Chef de Projet mais un Product Owner (Directeur Produit) et un Scrum Master.

Ce changement d’organisation engendre en pratique de nombreuses questions.

Par exemple:
– Quels rôles auront dans SCRUM les « anciens » chefs de projet ?
– Peut-on être à la fois Product Owner et Scrum Master ?
– Le Product Owner fait-il partie de l’équipe ?
– Comment le Product Owner et le Scrum Master travaillent-ils ensemble ?
– Qui est la bonne personne pour devenir le Product Owner ? le Scrum Master ?
– …

Vous trouverez de nombreux éléments de réponse dans l’article «Scrum Roles – an Unsolvable Puzzle?» par Anna Forss dans le numéro Eté 2009 de Methods And Tools, téléchargeable gratuitement.

Les Méthodes Agiles sont-elles compatibles avec l’utilisation d’un progiciel de gestion de projet ?

A l’origine des méthodes agiles, il y a le rejet des méthodes et des outils classiques de gestion de projet.

Les pionniers de l’Agilité ont donc dû revenir à la feuille Excel pour gérer leurs projets. Qu’en est-il aujourd’hui ?

La très forte augmentation de la compétition a obligé les entreprises à évoluer toujours plus vite, avec des concepts comme le Time-To-Market. La visibilité sur l’avenir s’est réduite. Les projets, toujours plus complexes, sont soumis à des changements permanents.

Ceci est incompatible avec une planification détaillée sur laquelle se fonde l’approche classique de la gestion de projet.

Les logiciels axés sur le diagramme de Gantt, le Pert ou la recherche du chemin critique, sont donc inadaptés pour les projets qui requièrent de l’agilité.

Faut-il utiliser un progiciel de gestion de projet lorsqu’on est Agile ?

Non, si le logiciel choisi est basé sur les techniques de planification détaillée. Il ne pourrait qu’introduire de la lourdeur et de la rigidité pour finalement n’apporter aucune valeur. Une feuille de calcul est alors préférable.

Oui, car il existe des nouveaux logiciels conçus pour les approches Agiles et plus efficaces qu’une simple feuille de calcul.

La gestion et la comptabilité de projet ou d’entreprise sont des fonctions qui ont vocation à être informatisées par des solutions d’entreprise.

Le logiciel de gestion de projet TimePerformance facilite le travail du chef de projet en lui fournissant des fonctions essentielles pour le pilotage et le suivi:

  • suivi 100% automatisé des coûts et des charges,
  • un tableau de bord ultra-complet en temps réel,
  • la traçabilité des évolutions,
  • le support méthodologique…

Le tableau de bord de TimePerformance fournit les indicateurs recommandés par tous les standards de la gestion de projet (PMBoK etc.). C’est particulièrement important pour l’image du projet vis à vis du Management et du Client.

Ainsi le logiciel TimePerformance évite la marginalisation des projets agiles.

Cliquez ici pour en savoir plus sur TimePerformance.

Cliquez ici pour plus de détails sur les concepts agiles supportés par TimePerformance (dans le cas particulier de la méthode agile SCRUM)

Version 1.8.5

Nouvelles fonctionnalités et améliorations:

  • Possibilité de définir une planification de référence qui sert de base de comparaison.Cette référence est utile pour figer le budget et le délai d’un projet (ex: projet au forfait).

    Dans les diagrammes, la zone en rouge est la zone d’alerte indiquant un dépassement de budget ou de délai par rapport à cette référence (cf. le diagramme ci-dessous).

    Un rapport sous forme de tableau permet de comparer de manière chiffrée le plan actuel et la référence (cf. ci-dessous).

  • Prévision des coûts réels basée sur l’estimé à terme (estimate at completion) disponible dans le diagramme de la valeur acquise.C’est la courbe en pointillés qui prolonge la courbe des coûts réalisés (cf. le diagramme ci-dessous).
  • Pour être cohérent avec la version 4 du PMBoK sortie cette année, la formule de calcul de l’estimé à terme a été modifiée dans TimePerformance.La nouvelle formule est la version dite « pessimiste » où l’indice de performance est égal à CPI * SPI (ou IPC * IPD en vf.).
  • Possibilité pour le chef de projet de clore, annuler ou mettre en pause les tâches des autres membres.
  • Changement de terminologie: les étapes s’appellent dorénavant des itérations. Un autre synonyme pour itération est « sprint ».
diagramme de la valeur acquise avec la prévision de coût
comparaison du plan actuel et du plan de référence