Étiquette : Méthodes Agiles

Agilité et suivi des temps, pour quoi faire ?

Le suivi des temps déchaîne rarement l’enthousiasme dans les équipes et bien des managers traditionnels peinent à le mettre en place. Cependant il trouve un nouveau sens et se renouvelle en mode agile en devenant une source précieuse de feedbacks pour toute l’équipe, principe fondamental de l’Agilité.

Feedback et Suivi des temps (Time Tracking)

timetrackingEn matière de gestion de projet, le processus d’estimation reste un exercice difficile et approximatif, alors qu’il est essentiel pour déterminer la viabilité du projet. Et le suivi des temps est le seul moyen d’obtenir un feedback pertinent sur ce processus critique.

Dans le domaine du développement logiciel, les tentatives de rationalisation du processus d’estimation ont abouti à des résultats médiocres malgré la complexité des modèles analytiques développés (points de fonction, Cocomo etc.). En général, estimer un projet reste un processus empirique basé sur l’intuition et l’expérience des équipes, agrémenté de techniques de recherche de consensus. Mais la fiabilité des processus empiriques est soumise à caution et on constate en pratique des marges d’erreur importantes.

En mode Agile, on a la chance de pouvoir vite améliorer le processus d’estimation empirique. Il suffit de fournir à l’équipe le feedback adéquat: les écarts entre les estimations et le temps réellement passé au niveau de chaque item du backlog.

Alimenter en informations chiffrées les rétrospectives (SCRUM) est le premier objectif du suivi des temps en mode Agile. L’équipe fournit un retour qualitatif et humain, le suivi des temps le complète par un feedback quantitatif et objectif.

L’indicateur de Vélocité seul ne permet pas d’identifier les causes des problèmes. En effet, calculé au niveau du Sprint (= itération), c’est un indicateur trop macroscopique influencé par de nombreux facteurs. De plus, la Vélocité n’est pas une mesure mais le paramètre d’un modèle linéaire simple entre complexité et charge de travail.

Le suivi des temps permet aussi d’avoir une mesure précise du facteur de concentration (focus factor) pour ceux qui l’utilisent.

Pour être utile, le feedback doit se faire au même niveau de détails que le processus d’estimation (i.e. backlog item, user story, la fonctionnalité…). C’est à ce niveau que le suivi des temps prend toute sa valeur (et non au niveau des tâches). Il permet de mesurer la fiabilité de chaque estimation, prise séparément. Il est alors possible d’ajuster le processus d’estimation pour prendre en compte d’autres facteurs que ceux du modèle générique.

Voici quelques leçons apprises chez Time Performance grâce au suivi des temps avec TimePerformance:

  • Nous passons environ 30% du temps sur des sujets qui ne font pas partie de la feuille de route du produit.

    Dans ces 30%, on retrouve les refactorings, les corrections d’anomalies, les petites améliorations, les tests utilisateurs…

    Le suivi des temps nous a permis de budgéter pour les itérations suivantes ce qui n’était pas dans la feuille de route.

  • Les tâches les plus complexes ne sont pas celles qui relativement prennent le plus de temps.

    Certaines tâches sont très simples techniquement mais prennent néanmoins du temps. Et la relation entre complexité technique et charge de travail n’est pas linéaire.

    Par exemple, il peut être nécessaire de faire de nombreuses retouches avec des allers-retours avec les utilisateurs. Il y a aussi des «coûts fixes», car même pour une fonctionnalité simple, il faut écrire des tests et de la documentation.

    Attention donc à ne pas sous-estimer le temps nécessaire sous prétexte que c’est simple techniquement.

  • Notre perception du temps est très subjective, bien plus qu’on ne le pense.

    Certaines heures paraissent être des minutes et certaines minutes paraissent durer des heures. Tout dépend si ce qu’on fait nous plaît ou non.

    Par exemple, certains se font une montagne de devoir remplir une feuille de temps alors que cela ne prend que quelques minutes par semaine. Et on retrouve les mêmes à la machine à café en train de discuter depuis 45 minutes sur le temps qu’il fait. L’exemple fonctionne aussi avec l’écriture des tests, de la documentation… Tout le monde se reconnaîtra, nous les premiers.

    Le suivi des temps peut permettre à chaque individu d’objectiver le temps qu’il passe réellement sur les tâches.

  • Notre marge d’erreur sur les estimations était plus importante sur les nouvelles fonctionnalités que sur les évolutions.

    En y réfléchissant, c’est assez logique. D’abord le risque est plus important pour une fonctionnalité importante et totalement nouvelle. La solution imaginée au moment de l’estimation peut ne pas marcher et nécessiter plusieurs ajustements. Les impacts sont aussi plus importants et des refactorings du code et des tests existants sont très probables.

Un suivi des temps efficace est absolument essentiel pour les équipes agiles pour maîtriser leur processus d’estimation. Cela mérite bien qu’on y passe quelques minutes par semaine.

Suivi des temps et gestion du projet

Traditionnellement, la feuille de temps sert principalement à suivre les coûts réels du projet en comptabilisant le nombre de jours travaillés.

En mode Agile, il est recommandé des équipes stables et des affectations à plein temps, ce qui rend la feuille de temps inutile.

Cependant la réalité des entreprises est souvent bien différente du cas idéal:

  • les personnes participent à la vie de l’entreprise (réunion de service, aider un collègue, veille, réorganisation…);
  • les personnes travaillent sur le projet mais peuvent être appelées en urgence sur d’autres sujets;
  • la spécialisation d’une personne ne permet pas une affectation à plein temps;
  • Une compétence rare est réclamée par de nombreux projets …

En pratique, le suivi des temps est indispensable pour connaître le temps réellement passé sur le projet. Il permet notamment de constater un écart entre affectation prévue et affectation réelle, qui explique dans de nombreux cas les retards dans les projets.

Même en mode Agile, le suivi des temps est en général nécessaire pour gérer le projet.

Vaincre les résistances

La mise en place du suivi des temps dans une équipe est un moment délicat où il faut faire preuve de leadership pour porter la vision.

Voici les 3 clés pour réussir la mise en place du suivi des temps:

  1. Donner du sens. C’est l’objet de cet article et la principale mission du manager ou du SCRUM Master.
  2. Faciliter la saisie par l’équipe. C’est ce que nous avons fait chez Time Performance avec notre logiciel TimePerformance en proposant 2 moyens complémentaires pour suivre facilement  son temps: une feuille de temps (déclaration a posteriori) et une liste de tâches avec une fonction type «chronomètre» (suivi au fil de l’eau).
  3. Montrer des résultats, c.-à-d. exploiter les informations et communiquer les résultats à l’équipe. C’est sans doute le plus important et ce qui permettra de convaincre les plus sceptiques.

Il y a encore quelques années, écrire des tests ou documenter le code n’étaient pas plus populaires que le suivi de temps parmi les développeurs. Aujourd’hui, c’est le quotidien des équipes agiles qui s’en font une fierté. Dans quelques années, un bon suivi des temps pourrait devenir le signe de maturité et d’autogestion d’une équipe…

 

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.