Voici l’histoire d’un projet comme les autres qui livre une fonctionnalité somme toute simple après 245 jours de délai.

Pour savoir comment on en est arrivé là, commençons par le commencement.

  • L’analyste après interview des utilisateurs, rédige des spécifications pendant 12 semaines.
  • Le client valide le lot de spécifications, et fait des retours pendant 4 semaines.
  • Le chef de projet consomme 2 semaines pour planifier les tâches.
  • L’ensemble des tâches est prévu pour être exécuté sur une période de 14 semaines.
  • L’équipe de développement exécute toutes les tâches, et livre une première version au bout de 20 semaines de développement.
  • L’équipe d’intégration teste l’application pendant 2 semaines, et constate 300 anomalies fonctionnelles et techniques.
  • Le chef de projet consomme 1 semaine pour affecter les tâches de correction d’anomalies.
  • Il prévoit une charge de 4 semaines pour résoudre les anomalies.
  • L’équipe de développement consomme en réalité 8 semaines pour résoudre les anomalies.

Il aura fallu attendre 9,5 mois pour avoir une première livraison de l’application, au lieu des 8 mois prévus. Il aura fallu attendre 2,75 mois supplémentaires pour qu’elle fonctionne correctement.

Au final, l’application aura été livrée en 12,25 mois, au lieu de 8,5 mois.

Stocker n’est pas livrer

Chaque acteur du projet constitue son stock :

  • stock de spécifications,
  • stock de développement,
  • stock de tests,
  • stock d’anomalies …

En accumulant les spécifications, l’analyste constitue un stock. Certaines spécifications manquent de lisibilité, sont sujets à interprétation, ou sont partiellement obsolètes. Ces erreurs seront souvent découvertes au plus tôt pendant la phase de développement, ou plus tard, lors de la phase de test.

De son coté, le développeur constitue un stock de développements. Les implémentations recèlent des anomalies latentes, qui ne seront détectées que lors de la phase de test.

De son coté, le testeur …

Il est long le chemin …

Dans ce modèle, la première fonctionnalité exprimée est livrée à l’issue des étapes suivantes :

  • La fonctionnalité est spécifiée en 3 jours.
  • Elle met 57 jours (12 semaines moins 3 jours) pour sortir du stock de spécification.
  • Elle attend 20 jours pour être validée par le client.
  • Elle est développée en 5 jours.
  • Elle séjourne 95 jours (20 semaines moins 5 jours) en stock de développement.
  • Une anomalie est détectée dans la fonctionnalité pendant la campagne de test.
  • L’anomalie reste dans le stock d’anomalies pendant 20 jours (4 semaines).
  • L’anomalie attend 5 jours avant le début de la campagne de correction d’anomalies.
  • La correction consomme 0,5 jour.
  • La fonctionnalité est finalement livrée à l’issue de la campagne de correction d’anomalies, après 39,5 jours (8 semaines moins 0,5 jour).

Au final …

Au final, le projet a donc mis 245 jours de délai pour livrer une première fonctionnalité, réalisée finalement en 8,5 jours.

Dans l’industrie automobile, Toyota a bien réussi à améliorer la productivité en s’attaquant justement aux stocks, mais aussi à d’autres sources de gaspillage. Pourquoi ne pas s’inspirer du lean manufacturing pour mener à bien nos projets ?

Dans notre prochain épisode, je vous propose de réfléchir à comment livrer la fonctionnalité beaucoup plus tôt et d’essayer de tendre vers les 8,5 jours.

Billets sur le même thème