Christophe Le Bot

  • Navigation rapide
Pratique de la conception numérique

Derniers commentaires

  • Une excellente thèse sur Simile Exhibit
    • Olivier Rossel | Bonjour. Malgre les annees, avez vous toujours en memoire vos usages d’Exhibit? Je serais ravi d’en discuter avec vous. Cordialement, Olivier Rossel.
  • Utiliser le planificateur de tâches OVH (crontab) avec PHP
    • Max | Bonjour, comme faire pour appeler une version de PHP qui n’est plus proposée par défaut dans le manager ? J’essaie de lancer un cron avec php 5.3 mais le log affiche No such file...
    • Christophe | @absolument Merci pour ces précisions. Je n’ai pas mis en place de tâches cron récemment, mais j’ai reçu quelques notifications étranges d’OVH il y a quelques...
  • Récupérer le dernier auto-incrément MySQL avec PHP
    • Thy | Sujet toujours *très* utile en 2015 ! Je réponds à Serge tsimba qui récupère un « Resource id ». (Et à tous ceux qui ont le même souci mais qui ne le disent pas) :)...
  • Régler l’heure de serveurs virtuels sous Debian
    • Ares_XL | Il semble que sur Débian la commande « tzconfig &ra quo; soit dépréciée et remplacée par : « dpkg-reconfigure tzdata » elle donne accès à une...

Sommaire de la page

 

Une traçabilité fine pour un pilotage global

« Tu as besoin de combien de temps sur cette tâche ? »

Quand on vous pose cette question, vous répondez toujours avec certitude et exactitude, sans qu’il y ait de remise en cause de votre engagement en fin de projet, n’est-ce pas ? Dites-moi oui et je ne vous croirai pas !

Même si les méthodes de gestion de projets donnent des indicateurs satisfaisants, notamment en approche agile, les écarts sur certaines tâches restent problématiques. Les raisons sont multiples : besoins imprécis, évaluation partielle du travail technique, mauvaise compréhension des objectifs, compétences inadaptées, planification défaillante… Si vous cumulez tous ces exemples, ce n’est pas gagné ! Mais en général, c’est plus pernicieux. Tout semble rouler… à part quelques tâches par ci, par là. Celles qui vont grignoter votre marge si difficile à atteindre !

Alors, ne peut-on vraiment pas faire mieux ? Avec une démarche d’amélioration continue, si.

Mais c’est quoi, ce temps qui file ?

J’ai vécu un projet un peu difficile (c’est le moins qu’on puisse dire…) qui m’a poussé à trouver une solution efficace. Sans prétendre vous donner les recettes miracles du projet calé à la minute près, je vous présente simplement un exemple d’approche qui a remis le projet sur les rails et assurer un pilotage de grande précision.

Ce projet, c’est celui de la rédaction de mon livre Magento. Il avait toutes les caractéristiques du projet foireux :

  • Première expérience dans la rédaction d’un ouvrage de référence.
  • Sujet récent qui manquait d’informations de qualité.
  • Projet personnel réalisé en dehors des heures de travail.

Autant dire que mon évaluation de départ n’était pas réaliste : 7 mois de travail qui en sont devenus 14. Mais le pire, c’est qu’après cinq mois, je n’avais toujours pas mesuré qu’il m’en restait 9 ! Le gros du boulot me semblait bien avancé, mais les finitions allaient s’avérer interminables : relecture, corrections, création de l’index, des schémas et des images…

D’où vient le problème ?

Si le projet était personnel, je devais néanmoins le caler avec la feuille de route de mon éditeur. Au fur et à mesure de la rédaction, mes estimations s’affinaient, je connaissais le temps de rédaction pour 100 lignes, le nombre de copies d’écrans réalisées en une heure, le temps de relecture d’un chapitre… Mais, le résultat n’était pas assez précis. Je n’arrivais pas à déterminer les priorités et je débordais souvent. Sans doute à cause de ces milliers de micro-tâches de quelques dizaines de secondes éparpillées dans 550 pages.

Bon sang, mais c’est ça le problème ! Ces micro-tâches, prennent-elles 10 ou 20 secondes ? Sont-elles 200 ou 500 par chapitre ? Voilà les bonnes questions !

Tracer au plus fin

Il fallait trouver le moyen d’évaluer la moindre tâche. Pourtant, on le sait : tout mesurer est inutile et coûteux. Eh bien, non ! C’est même ce qui m’a sauvé. L’astuce a consisté à placer un marqueur dans le texte dès qu’une tâche était identifiée. Ce marqueur permettait de connaître le type de travail et le temps estimé pour le réaliser.

Une image à faire, un marqueur. Une phrase à revoir, un marqueur. Un paragraphe à rédiger, un marqueur. Une page à relire, un marqueur. En quelques jours, j’avais mes milliers de marqueurs… et un premier résultat redoutable : je voyais sous mes yeux le reste à faire presque au double de mes estimations !

Après la douche froide, ce fut un vrai plaisir. Les temps estimés étaient respectés, l’analyse des grands lots très précise, la feuille de route bien tracée. Je pouvais organiser mon travail selon mes disponibilités : « Une heure de libre ? Ah tiens, je peux faire les 7 corrections du chapitre 12 et les livrer à l’éditeur ».

Et en pratique, ça donne quoi ?

Mon éditeur m’a laissé le choix des armes : Word ou OpenOffice. Si vous avez déjà tenté de rédiger un ouvrage de quelques centaines de pages sous Word avec un sommaire, des illustrations et des index, vous comprendrez vite pourquoi j’ai choisi OpenOffice, beaucoup plus fiable et adapté aux documents volumineux et structurés. D’ailleurs, l’ouvrage a tenu 14 mois dans OpenOffice sans un seul bug ! Ce que je dis là est valable pour LibreOffice, bien entendu.

Grâce à la recherche par expression rationnelle (regexp en anglais) d’OpenOffice, j’avais de quoi poser des marqueurs dans le texte et les extraire pour analyse. J’ai donc imaginé une nomenclature simple pour décrire les tâches :
-TODO [priorité] [type] [chapitre] [charge] [commentaire] TODO-

  • -TODO : début de marqueur
  • [priorité] : indicateur de priorité (A ou B)
  • [type] : type de tâche (rédaction, création de figure, correction, relecture, etc.)
  • [chapitre] : numéro du chapitre
  • [charge] : temps estimé en h
  • [commentaire] : pour savoir quoi faire
  • TODO- : fin de marqueur

Voici un exemple :

-TODO A WRITE C19 0,4 exemple getData() getDemoName() TODO-

Ce marqueur indique une tâche prioritaire (A) concernant la rédaction (WRITE) dans le chapitre 19 (C19) pour une charge de 0,4h. Le commentaire précise qu’il faut rédiger un exemple d’utilisation de deux méthodes (exemple getData() getDemoName()).

Marqueurs de tâches dans OpenOffice
Exemples de marqueurs de tâches dans une page sous OpenOffice.

La regexp suivante me permettait d’extraire tous les marqueurs du document :

-TODO .* TODO-

Recherche par regexp
Recherche des marqueurs de tâches dans le document OpenOffice.

Le résultat était récupéré dans le tableur OpenOffice Calc pour faire toutes les analyses possibles : temps de charge par chapitre ou par type d’activité, pourcentage d’avancement des chapitres, charge par priorité, etc. J’étais enfin dans le concret !

Liste des tâches dans le tableur
Liste des tâches dans le tableur.
Tableau croisé dynamique de la charge
Tableau de la charge par chapitre et par type d’activité.
Graphique de la charge
Graphique de la charge par chapitre.
Graphique des taux d'avancement
Graphique des taux d’avancement par chapitre.
Graphique de priorité
Graphique des priorités et de la charge par chapitre. Sans doute l’outil le plus utile pour prendre les bonnes décisions.

Et ça marche pour tout ?

L’énorme avantage de ce système, c’est d’affiner au fur et à mesure les estimations de charge des tâches. Le temps réel est facilement comparable au temps estimé, directement sur chaque marqueur du document de travail. Par expérience, on est donc de plus en plus précis sur les estimations des tâches qui se ressemblent.

Peut-on extrapoler ce principe à d’autres activités ? Oui, mais pas toutes. La rédaction d’un ouvrage est une activité particulière, assez « linéaire » : il faut remplir le contenu page après page. D’autres activités nécessitent des tâches plus imbriquées, plus diversifiées. Dans ce cas, il est difficile d’utiliser des marqueurs communs dans des outils et contenus différents.

A mes yeux, il existe une activité pour laquelle l’approche est pertinente et efficace : le développement informatique. Depuis très longtemps, les éditeurs de code acceptent des marqueurs pour gérer le travail des développeurs. Il y a même le fameux @todo pour lister les tâches à réaliser ! Alors pourquoi ne pas aller jusqu’au bout ? Dans les solutions complexes comme Magento, il n’est pas toujours facile d’estimer l’ensemble des micro-tâches autour du développement d’un module : implémentation des méthodes, optimisation des objets, modification des interfaces, calage des feuilles des styles, optimisation des performances, refactorisation, tests, etc.

Grâce à vos marqueurs, vous verrez bien plus vite qu’un module presque terminé nécessite encore le double de travail ! L’inverse est vrai aussi : quand vous allez plus vite que l’estimation, vous le voyez plus tôt, ce qui vous permet d’optimiser votre plan de charge ! Et les développeurs sont heureux : ils n’ont pas à sortir la tête du code pour faire leur compte-rendu au chef de projet 😉