Je vois assez souvent passer dans mon fil d’actualité LinkedIn des posts évoquant le triangle qualité / coût / délai, souvent sous forme de trois bulles « Rapide », « Pas cher », et « De bonne qualité ». Ce triptyque vient de la gestion de projet dite « classique ». Il nous dit principalement qu’il n’est pas possible d’avoir un projet rapide, pas cher et de bonne qualité.

Comment l’utiliser ?

Je me souviens de mes cours de gestion de projet, où le professeur nous expliquait qu’il fallait se positionner sur ce fameux triangle.

Triangle Qualité – Coût – Délai

Un exemple assez souvent utilisé est celui de la construction d’une fusée. En effet la construction d’une fusée est un projet que nous pouvons considérer comme critique, car un défaut de qualité peut entraîner des répercussions dramatiques. De ce fait, il n’est pas possible de lésiner sur la qualité, entraînant de fait, un coût important et des délais rallongés.

A contrario, si nous souhaitons mettre un produit de grande distribution sur le marché, et ceci avant notre concurrent principal. Nous allons privilégier le délai quitte à sacrifier la qualité du produit et à mettre tous les moyens financiers nécessaire pour être le premier sur le marché.

De la même façon, si nous souhaitons un coût très faible, nous allons certainement sacrifier la qualité et rallonger les délais.

Bien sûr, nous ne sommes pas obligés de nous positionner sur un des coins du triangle. Nous pouvons nous positionner sur une arrête et ainsi avoir, par exemple, un coût assez faible et un délai assez court, si nous acceptons de diminuer la qualité du produit.

Nous pouvons même décider de nous positionner à n’importe quel autre endroit, comme le centre, et dans ce cas nos trois contraintes seront à égalité. Un projet de qualité moyenne, dans un délai moyen et pour des coûts moyens. Pourquoi pas…

Pourquoi ça ne fonctionne pas sur un projet informatique ?

J’en reviens donc à mon postulat de départ, qui est de voir souvent ce fameux triangle d’or être repris d’une façon ou d’une autre. Je suis embêté car je travaille dans le monde du numérique et cette vision ne me semble pas adaptée à ce que nous observons… Je m’explique ! En effet réfléchissons aux conséquences d’un défaut de qualité dans un projet informatique. Nous pouvons considérer que ce défaut de qualité va entraîner de la dette sur notre projet. De la dette fonctionnelle, plus communément appelé des « bugs » ou anomalies, et de la dette technique.

Qualités des produits logiciels

Commençons par les anomalies… Etant visibles du client et des utilisateurs, elles sont souvent corrigées assez rapidement, voir en priorité. Pendant ce temps l’équipe ne travaille pas, ou moins, sur les nouvelles fonctionnalités attendues, entrainant de fait un ralentissement des développements. Pour résumer grossièrement… Il est plus rapide de faire bien du premier coup ! La dette technique, quand-à elle, est- un concept inventé par Ward Cunningham en 1992. Il nous dit :

Sortir une première itération de code, c’est comme s’endetter. Une petite dette accélère le développement tant qu’elle est remboursée rapidement par une réécriture… Le danger survient lorsque la dette n’est pas remboursée. Chaque minute passée sur un code pas tout à fait correct compte comme un intérêt sur cette dette. Des organisations entières peuvent être paralysées sous la charge de la dette d’une implémentation non consolidée.

Ward Cunningham, 1992

La dette technique s’accumulant, les développements vont devenir de plus en plus complexes et risqués, et donc les délais pour développer les fonctionnalités à venir vont s’allonger dans le temps. Cette dette à tendance à s’accumuler car non-visible du client ou des utilisateurs. Le remboursement de cette dette technique n’est donc que trop rarement priorisé.

Diagramme Vélocité – Dette

En conclusion, nous observons que les délais sont liés à la qualité sur les projets informatiques, remettant en question le principe même du triangle d’or. Qu’en est-il du coût ? Le coût principal étant le coût de l’équipe sur le projet, et même s’il existe d’autres sources de coûts, nous pouvons facilement faire un lien entre les délais de développement et le coût du projet, reliant par la même occasion les coûts à la qualité.

Que nous dit l’agilité ?

Un des douze principes de l’agilité est :

Une attention continue à l’excellence technique et à une bonne conception renforce l’Agilité.

Principe #9 du manifeste agile

J’irais même plus loin avec cette fameuse phase… Il n’y a pas d’agilité sans qualité !

Du coup, comment faire pour réduire les coûts ?

Le livre « Green IT – Les clés pour des projets informatiques plus responsables » nous informe qu’en moyenne, seul 20% des fonctionnalités développés sur nos projets sont très régulièrement utilisées.

Couverture du livre « Green IT – Les clés pour des projets informatiques plus responsables »

Il parait donc plus judicieux de chercher à développer moins de fonctionnalités, en se concentrant sur les plus utiles, plutôt que de chercher à développer vite. D’ailleurs les principes de l’agilité vont dans ce sens :

La simplicité – c’est-à-dire l’art de minimiser la quantité de travail inutile – est essentielle.

Principe #10 du manifeste agile

Conclusion

Nous avons vu que les coûts et les délais se rallongent avec un défaut de qualité. Et qu’il semble souvent possible de réduire le nombre de fonctionnalités développées. Pour ce faire nous allons chercher à prioriser ces fonctionnalités en fonction de leur valeur ajoutée, le tout en allant chercher du feedback très régulièrement afin d’être le plus pertinent possible sur cette priorisation. Le premier principe de l’agilité nous dit d’ailleurs :

Notre plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutée.

Principe #1 du manifeste agile

Nous pouvons conclure avec ces deux phrases :

  • La qualité sur un projet informatique, n’est pas négociable !
  • Pour satisfaire notre client, nous allons chercher à optimiser la valeur livrée en fonction des contraintes de coût, de délai, et du périmètre fonctionnel embarqué.
Triangle Agile

Sources

Vous avez besoin d’être accompagnés ?

Nos équipes sont à l’écoute !

Contactez-nous