Gestion de la qualité technique en agilité

Pourquoi une telle importance de la qualité en agilité ?

Ce qui différencie la culture produit des méthodes de projet traditionnelles, c’est que notre produit évolue continuellement afin de s’adapter au mieux aux attentes du client.

L’accent est mis sur l'acceptation du changement plutôt que sur un effort de planification.

De plus, lorsque nous utilisons l’agilité, nous sommes par définition dans un environnement complexe et incertain. Nous n’avons donc aucune certitude sur des liens de cause à effet nous permettant d’atteindre sans risques nos objectifs dans le cadre d'un projet.

Dans ce genre d’environnement, le processus à adopter par les équipes de développement et de management est :

poser une intention ;
expérimenter par itérations et tests successifs ;
observer les résultats et adapter.

Rien de nouveau jusqu’ici, ce sont les bases de l’agilité, que la méthodologie employée soit XP, Scrum…

Cela signifie que, toujours dans ces environnements incertains, nous allons devoir adapter nos fonctionnalités (i.e. les défaire, les refaire) de nombreuses fois, et cela jusqu'à ce que la vie du produit arrive à son terme.

Or, sans une qualité suffisante permettant une bonne maintenabilité applicative, ces travaux d’adaptation risquent de rendre l’application ou le logiciel instables et inutilisables pour le client.

Pour réaliser des produits de qualité, nous devons donc répondre à deux enjeux :

faire le bon produit : qui répond aux besoins utilisateurs
faire le produit correctement : d’une bonne qualité technique.

Cette qualité technique qui permettra, entre autres :

de modifier du code en limitant les anomalies et les régressions ;
d'accueillir de nouveaux développeurs dans l'équipe technique, qui pourront prendre possession du code rapidement et sans risques ;
de livrer régulièrement et sans risques un nouveau produit ou de nouvelles fonctionnalités ;
de garder des développeurs motivés et fiers de leur travail.

C'est en s'appuyant sur ce socle que nous pourrons développer ces produits rapidement en plaçant l’utilisateur au centre.
C'est-à-dire proposer des cycles itératifs et incrémentaux les plus courts possible (notamment via des sprints) afin de proposer des fonctionnalités le plus rapidement possible aux utilisateurs et apprendre de leurs retours.

A noter que l'approche en flux porté par les principes Lean et Kanban fonctionnent également parfaitement ici.

Maintenir un travail constant sur la qualité technique est crucial pour assurer l'évolution durable de votre produit.

Peut-on dégrader la qualité technique dans certains cas ?

Notre coach agile a-t-il raison, et cela dépend-il du contexte ?

Eh bien, oui, ça dépend du contexte !

Nous l’avons dit plus haut, vous êtes dans un monde incertain où vous n’êtes pas sûr à 100 % que telle action aura bien l’effet escompté. Mais votre niveau de certitude augmente au fur et à mesure des expérimentations (itérations et tests). C'est là tout l'intérêt d'une gestion de projet agile.

En général, vos premiers tests sont à usage unique et servent seulement à apprendre avant d’être jetés (POC, MVP…). Cela jusqu’à ce que vous soyez assez confiant quant au processus pour “industrialiser” la construction de votre produit.

Si vous êtes sur du jetable, c’est important de le savoir, de le communiquer en interne. Et dans ce cas, vous pouvez assumer de réduire la qualité technique.

La difficulté de cette méthode va être de trouver le bon curseur entre ce qui est de l’apprentissage (et donc jetable) et ce qui est industrialisable (et donc maintenable sur plusieurs années et nécessitant la qualité adéquate).

Lorsque l'on travaille sur du jetable, il est possible de négliger la qualité technique.

Peut-on réduire la qualité technique dans d’autres cas ?

Imaginons : vous souhaitez lancer un nouveau produit ou logiciel sur le marché, et vous apprenez que deux concurrents travaillent actuellement sur le développement de produits similaires.

Dans ce cas, choisir de baisser la qualité et accélérer le processus de développement pour être le premier à proposer votre produit sur le marché est sûrement une méthode adéquate.

On parle alors de dette technique : vous contractez une dette vis-à-vis de l’équipe de développement qui accepte de réduire la qualité et les exigences de conception pour vous faire gagner en rythme de réalisation.

Le problème des dettes, c’est qu’il faut les rembourser : à tout moment, l’équipe technique peut venir vous voir pour vous indiquer que la qualité de l’application ou du logiciel est à risque, et qu’il faut rembourser une partie de la dette de peur de ne plus pouvoir la faire évoluer du tout.

Mon conseil : si vous décidez consciemment de créer de la dette technique avec votre équipe de développement, rendez-la visible (en l’ajoutant à votre backlog par exemple).

Si la santé de votre entreprise ou de votre produit dépend d’une vitesse de réalisation, dans ce cas, réduire la qualité est une méthode à envisager.

Et l’avis des développeurs sur la qualité technique ?

Les bons développeurs aiment mettre l’accent sur la qualité technique et une bonne architecture. C’est d’autant plus important pour eux s’ils doivent maintenir le code pendant plusieurs mois, voire plusieurs années.

Cependant, si vous annoncez à un développeur que cette version du logiciel ou de l'application est jetable, car elle sert à de l'apprentissage pur, il se fera un plaisir de la développer en réduisant la qualité technique. Tout programmeur est content de pouvoir faire du “quick and dirty” tant qu’il n’aura pas à vivre avec les conséquences pendant plusieurs années.

Important : si vous faites développer une première version d’une application ou d'un logiciel jetable et que, par miracle, celle-ci répond parfaitement aux besoins de vos utilisateurs, ne choisissez surtout pas de conserver cette version pour industrialiser un produit dessus. Les développeurs n’apprécieront pas, et rattraper la qualité technique d’un produit codé rapidement est très difficile et peu motivant.

Tout programmeur est content de pouvoir faire du “quick and dirty” tant qu’il n’aura pas à vivre avec les conséquences pendant plusieurs années.