Le temps qualitatif

Ca m’agace toujours quand j’entends un chef de projet dire à un développeur : pour la tache T23 on avait prévu 2j, tu es déjà à 3j il faut aller plus vite.

Pour moi, on ne peut pas dissocier le temps (3j) de ce à quoi il est consacré. Ca change tout de savoir que :

• pour cette tache on a du faire un refactoring de toute l’application
• pour cette tâche on a du changer de version de composant …

La vraie question c’est plutôt :

• fallait-il ou non faire ces tâches annexes ?
• quel niveau de qualité fallait-il se fixer ?
• Ces choses ont-elles été décidées officiellement ?

Ensuite, il faut rappeler un point : le problème n’est pas que le chef de projet avait prévu 2j, on peut aussi bien passer 4j.

Le problème c’est que l’on a vendu 2j (de budget) ou une date.

Sur la base de quoi ?

Avait-on fait une analyse profonde des caractéristiques des tâches, des tâches sous-jacentes ?

Dans CMMI on capitalise un modèle de charge à passer (en moyenne), mais il n’est pas toujours assez finement paramétré par le niveau d’exigence du client ou les spécificités du projet.

Dans les méthodes agiles, il y a la “definition of done“, mais elle est générale (pour qu’une tâche soit finie, il faut avoir mis à jour la javadoc, passé tous les tests, …) alors que les décisions à prendre sont “locales” : ai-je besoin du même niveau d’exigence ergonomique pour les écrans d’administration, …

Bref, il est surtout urgent se concerter, de faire valider par le décideur (chef de projet ou product owner).

Et s’il faut utiliser des statistiques, d’utiliser des statistiques portant sur le projet en cours (velocité), si tant est qu’il n’ait pas évolué dans la nature de ses tâches (architecture technique stabilisée, bugs suite à mise en production, …).