Dans l’épisode précédent, nous avions livré une première fonctionnalité après 245 jours. Et nous nous étions mis au défi de livrer cette même fonctionnalité bien plus rapidement.

Adoptons maintenant une démarche Lean, et regardons de plus près l’organisation de notre production de fonctionnalités.

Que constatons-nous au niveau de notre chaîne de production de logiciel ?

Les stocks en attente dans notre projet sont causés par le plus fondamental des gaspillages : la surproduction !

Des stocks qui dissimulent les défauts

La surproduction engendre l’accumulation de stocks en attente d’utilisation, ou qui ne seront parfois jamais utilisés.

Les stocks vont ainsi dissimuler de nombreux défauts.

Ainsi, le stock de spécifications masque des défauts qui se révéleront plus ou moins tard (et souvent plutôt tard, d’ailleurs) dans le projet :

  • Certaines spécifications deviennent obsolètes. Un besoin fonctionnel exprimé au début du projet voit son périmètre changer significativement.
  • Le client constate que certaines fonctionnalités ne répondent pas aux exigences. Certaines règles de gestion n’ont pas été spécifiées par le fonctionnel.
  • Le jour de la livraison, le client constate l’absence d’une fonctionnalité. Le besoin a échappé à l’attention du fonctionnel.
  • Le fonctionnel croit, de bonne foi, percevoir un besoin fonctionnel qui en réalité n’existe pas.
  • Fier d’ajouter son petit plus à lui, le fonctionnel spécifie des fonctionnalités ne correspondant à aucun besoin fonctionnel exprimé par le client. Mais à son avis, elles pourraient bien servir un jour.

Le stock de développements masque lui aussi de nombreux défauts souvent détectés tardivement, au moment de la recette fonctionnelle ou de la recette client.

  • Bien souvent, les défauts des spécifications sont directement implémentés lors des développements.
  • Le développeur interprète mal la spécification, l’implémentation n’est pas conforme.
  • Le développeur soupçonne un défaut dans la spécification. Par peur de ne pas tenir son délai, il décide de passer le défaut sous silence. Le défaut est propagé.
  • Comme il n’a pas consommé toute sa charge, le développeur ajoute son petit plus. À son avis, ça servira bien un jour.
  • Les développements comportent des bugs et divers défauts techniques.

Non seulement, nous produisons des stocks, mais en plus, pour fabriquer chaque fonctionnalité, nous devons consommer l’intégralité de chaque stock pour passer à l’étape suivante.

Finalement, nous préférons optimiser la production de chaque membre de l’équipe, au lieu d’améliorer notre capacité à produire des fonctionnalités qui marchent.

Réduire le nombre de défaut

N’est-il pas contre-productif de constituer un stock de défauts ?

La première fonctionnalité a été livrée après 245 jours. Nous avions consommé 2 mois de développement pour réparer des défauts, alors qu’1 mois était prévu.

L’équipe explique ce dépassement par le fait que certains défauts sont complexes à traiter pour les raisons suivantes :

  • Les défauts sont liés les uns aux autres.
  • La réparation des défauts provoque souvent l’apparition d’autres défauts.

Comment diminuer le nombre de défauts ?

Simplement, considérer la fonctionnalité comme l’unité de fabrication idéale, et donc produire les fonctionnalités en flux continu.

On imagine aisément que ce mode de production va impacter le nombre de défauts et permettre des corrections plus rapides. La résolution immédiate des défauts au moment de leur fabrication est beaucoup moins couteuse que la constitution d’un stock de défauts… à corriger plus tard.

Produire les fonctionnalités en flux

Dans notre projet, la première fonctionnalité est :

  • spécifiée en semaine 1,
  • implémentée en semaine 19,
  • et testée en semaine 39.

En adoptant une production en flux des fonctionnalités, la première fonctionnalité serait :

  • spécifiée en semaine 1,
  • implémentée en semaine 2,
  • testée en semaine 3,
  • et corrigée en semaine 3.

Or on se heurte rapidement à des problèmes de capacité sur la chaine de production, en particulier au niveau des fonctionnels qui ne produisent pas toujours les spécifications à une vitesse suffisante.

L’équipe de développement est alors dans une phase d’attente. En effet, la rédaction des spécifications nécessite souvent de faire des interviews et le client manque de disponibilité.

Finalement les fonctionnels décident de livrer les spécifications régulièrement, toutes les 2 semaines. La première fonctionnalité est alors :

  • spécifiée en semaine 1,
  • implémentée en semaine 3,
  • et testée en semaine 5.

Notre première fonctionnalité est donc livrée au bout de 5 semaines, soit 25 jours, au lieu des 245 jours initiaux.

Et l’équipe ?

On pressent que le mode de production peut avoir un impact notable sur les modes de travail. Comment les fonctionnels, les développeurs, les testeurs vont-il maintenant travailler ? Nous tenterons de répondre à cette question dans les prochains billets.

Billets sur le même thème