Gestion des Coûts et Projets Agiles

Présentation sur la Gestion des Coûts et les Projets Agiles animée par Time Performance lors de l’Agile Tour 2010.

Gestion des coûts et Projets Agiles

10 façons de se planter avec Scrum et XP

Pour tous les fans de l’Agilité et du développement logiciel, le site d’InfoQ est une mine d’informations et de ressources utiles.

Nous vous invitons à regarder la présentation intitulée: «10 ways to screw up with SCRUM and XP». Réalisée par Henrik Kniberg, elle a été filmée sur l’Agile Tour 2008.

En résumé, voici les 10 façons de se planter avec Scrum et XP:

  1. Croire à un miracle de l’Agilité
  2. Incapacité à définir ce que signifie «Terminé» (Definition of Done) ou à suivre la définition en pratique
  3. Incapacité à gérer la Vélocité (mauvaise utilisation, tricher sur la vélocité réelle…)
  4. Rétrospectives inefficaces
  5. Manque d’engagement de l’équipe
  6. Incapacité à bien gérer la dette technique
  7. Problème de travail en équipe (mauvaise définition des rôles, pb de coopération, interférence du management…)
  8. Problème avec le Product Owner (disponibilité, pouvoir, implication, mauvaise gestion du product backlog…)
  9. Peur de fusionner les développements car trop complexe à faire
  10. Problème d’utilisation du tableau des tâches (mise à jour peu fréquente, complexité…)

Timeboxing

Le Timeboxing est une technique de gestion du temps utilisée dans les méthodes agiles pour la planification et la maîtrise des délais. Cet article en rappelle le principe et souligne les différences avec les approches traditionnelles.

Un concept très simple

Le Timeboxing est une division du temps en périodes successives d’une durée égale et relativement courte. Pour un projet, la durée recommandée des périodes est entre 2 et 6 semaines.

Cette technique est utilisée dans le domaine du développement logiciel pour imposer des livraisons fréquentes et régulières. L’objectif est d’accélérer le cycle de développement et le feedback des utilisateurs. Il s’agit aussi de lutter contre les problèmes bien connus de gestion du temps (cf. effet tunnel, lois de Parkinson et de Hofstadter, syndrome de l’étudiant etc.).

Dans le cas du développement logiciel, chaque période se conclut par une livraison. Elle est assimilable à une boîte dans laquelle il faut faire entrer le maximum de nouvelles fonctionnalités. La taille de la boîte est imposée et correspond à la charge de travail réalisable pendant la période. Le principal enjeu de la planification consiste à optimiser l’espace de chaque boîte en fonction de la priorité de chaque fonctionnalité et du temps nécessaire pour la développer.

Différence avec l’approche traditionnelle

En général, les techniques agiles prennent le contrepied de l’approche traditionnelle. Le Timeboxing n’échappe pas à la règle.

Continuer la lecture de « Timeboxing »

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

De plus en plus d’équipes revendiquent une démarche Agile pour échapper aux lourdeurs des méthodes traditionnelles. Mais connaissent-elles réellement les implications de l’Agilité ?

Suite au précédent article, 5 idées fausses à propos des Méthodes Agiles, nous vous proposons un 2ème opus avec 5 nouveaux préjugés sur l’Agilité.

Idée fausse n°6: les Méthodes Agiles, c’est la liberté de faire à sa façon

Equipe en « autogestion », remise en cause du rôle de chef de projet, redistribution des responsabilités, suppression des aspects contractuels, pas de planification détaillée, absence ou presque de documents, communication principalement verbale…

Tous ces éléments, qui séduisent les équipes, ont un petit goût de liberté et d’émancipation, qui risque d’être mal perçu par le management traditionnel.

Cependant il serait faux de considérer que l’Agilité est synonyme d’absence de règles, de contraintes et de structures.

Continuer la lecture de « 5 autres idées fausses à propos des Méthodes Agiles »

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

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) »

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)

Offshore et méthodes agiles: le mariage impossible…

Depuis quelques années, on voit apparaître dans le domaine du développement informatique des offres mariant l’Offshore et les méthodes agiles.

Comme le souligne ce rapport Forrester, les promesses de cette union sont grandes:

  • coûts très bas,
  • meilleure satisfaction utilisateur
  • et délais plus courts.

Voici donc la solution à tous les problèmes…

Le hic, c’est que tout le monde s’accorde à dire que les 2 approches sont incompatibles et même diamétralement opposées. Il s’agirait donc d’un mariage contre nature. 

Pour illustrer cette incompatibilité, voici quelques éléments.

Il est bien connu que le succès d’un projet Offshore pour le client final repose au moins sur les 2 points clés suivant:

  • avoir des spécifications solides, détaillées et stables;
  • éviter de traiter en direct avec le prestataire Offshore.

Du côté méthodes agiles, l’eXtreme Programming (XP pour les intimes) repose sur 4 valeurs: la communication, la simplicité, le feedback et le courage. SCRUM, quant à elle, repose sur les interactions directes entre les individus et une communication transparente.

On voit alors difficilement comment le fait de travailler via une société intermédiaire avec une société dans un pays étranger, donc avec une autre culture et généralement une autre langue, est compatible avec des méthodes préconisant une communication efficace, des feedbacks rapides et la simplicité des procédures. D’ailleurs, XP fait explicitement la recommandation du « client sur site » (le site étant le site de développement).

De plus, il faut préciser que la raison d’être des méthodes agiles est l’incapacité à produire des spécifications stables et détaillées du fait de la complexité ou de l’imprévisibilité de certains projets; ce qui est difficilement compatible avec le mode Offshore.

Vous trouverez ci-dessous quelques retours intéressants de la part de « ceux qui ont essayé »:

  1. Rapport sur les projets offshore et les méthodes agiles de la part d’une société de conseil en informatique. Ce rapport a d’autant plus de valeur que les problèmes rencontrés n’ont pas été masqués. Le plus significatif est la structure finale de l’organisation du projet qui est, à mon avis, très différente de ce que préconisent les méthodes agiles.
  2. Autre Article. (Rq: en conclusion de l’article, le compromis est d’utiliser le Unified Process qui, pour les puristes, n’est pas une méthode agile.)
  3. Article très détaillé sur les projets en Offshore contenant plusieurs témoignages.

Pour faire de l’Agile en Offshore, il faudra donc faire des compromis ou des adaptations, et surtout, mettre en place des méthodes et des outils de communication pour palier le problème de l’éloignement. D’ailleurs, le logiciel de gestion de projet TimePerformance offrirait de multiples avantages dans ce context: le mode SaaS pour le multi-site, excellente visibilité et  transparence pour facilité la communication entre les parties et totale compatibilité avec les approches agiles.

En conclusion, le mariage entre Offshore et Méthodes Agiles ne sera pas facile mais pas impossible.