Qu’est-ce que la qualité intrinsèque ? (built-in quality)
Au cœur de Lean-Agile, Software Craftsmanship et Product Management
La qualité intrinsèque ou built-in quality en anglais est essentielle au développement logiciel moderne.
C’est, en quelques mots :
Construire la qualité dans le produit plutôt que de la vérifier après coup.
Approche traditionnelle VS. qualité intrinsèque
Voici un tableau qui illustre la différence entre une approche traditionnelle de la qualité et la qualité intrinsèque ou built-in quality :
Approche traditionnelle de la qualité :
- La qualité est le problème de la QA ou des testeurs.
- On vérifie l’absence de bugs après le développement.
- Dans le Definition of Done, le codage est fait mais le produit ne peut pas encore être livré.
Qualité intrinsèque ou built-in quality :
- La qualité est un enjeu collectif.
- Bonnes pratiques de développement tirées d’Extreme Programming : TDD, Pair-Programming, intégration continue…
- On améliore les process de développement pour réduire le nombre de bugs générés.
- Les testeurs apportent une vision globale de la qualité ; la qualité technique est assurée par les développeurs.
- Dans le Definition of Done, un développement terminé implique qu’on pourrait livrer le produit en production.
Scrum
Les éléments décrivant la qualité intrinsèque font directement écho à Scrum.
Terminé = on pourrait livrer en production
En particulier, le fait que le Definition of Done implique qu’on pourrait livrer le produit en production est explicité dans la définition de l’incrément produit du Guide Scrum :
Incrément
L’incrément est constitué des éléments du Backlog produit « Finis » pendant le sprint ainsi que de la valeur cumulative des incréments livrés dans les sprints précédents. À la fin d’un Sprint, le nouvel incrément doit être « Fini », ce qui implique qu’il doit être dans un état publiable et qu’il correspond à la définition de « Fini » (Definition of Done) de l’équipe de développement. Un incrément est la partie d’un travail fait, qui prend en charge l’empirisme, et vérifiable à la fin du Sprint. L’incrément est un pas vers une vision ou un but. L’incrément doit être dans un état publiable, sans égard à la décision du Product Owner de le publier ou non.
Quoi qu’il arrive, un développement terminé doit être “dans un état publiable” — et qui plus est, cela doit arriver à chaque fin de Sprint.
Qualité = enjeu collectif
Scrum met tout en place pour que le produit construit et sa qualité soient une responsabilité collective de l’équipe. Voici la définition de l’équipe de développement tirée du Guide Scrum :
L’équipe de Développement
L’équipe de développement se compose de professionnels qui fournissent un incrément « Fini » potentiellement publiable (Releasable) à la fin de chaque Sprint. Un incrément « Fini » est requis à la revue de sprint. Seuls les membres de l’équipe de développement créent l’incrément.
Les équipes de développement sont structurées et habilitées par l’organisation à s’organiser et gérer leur propre travail. La synergie résultante optimise l’efficience et l’efficacité globale de l’équipe de développement.
Les équipes de développement ont les caractéristiques suivantes :
• Elles sont auto-organisées. Nul (pas même le Scrum Master) n’indique à l’équipe de développement comment transformer les éléments du Backlog Produit en incréments de fonctionnalités potentiellement publiables ;
• Elles sont pluridisciplinaires, avec toutes les compétences nécessaires, en tant qu’équipe, pour créer un incrément produit ;
• Scrum ne reconnaît aucun titre aux membres de l’équipe de développement, indépendamment du travail effectué par une personne ;
• Scrum ne reconnaît pas d’équipes au sein de l’équipe de développement indépendamment des domaines qui doivent être couverts tels que l’exécution de tests, l’architecture, la gestion opérationnelle ou l’analyse fonctionnelle ; et,
• Les membres de l’équipe de développement peuvent détenir individuellement des compétences et des centres d’intérêt spécifiques, mais c’est l’équipe de développement dans son ensemble qui est tenue responsable.
En Scrum :
- Il y a des experts mais ils ne sont jamais tenus responsables individuellement, c’est toujours un effort collectif
- L’équipe peut restreindre certains types de travaux à certains de ses membres, mais l’équipe reste tenue responsable collectivement de cette décision et de ses conséquences
- L’objectif de Sprint, la seule chose qui compte réellement pendant le Sprint, est un objectif collectif pour toute l’équipe
- Le Definition of Done précise les critères de “fini” mais pas qui s’en charge ; c’est une responsabilité collective de l’équipe
À aucun moment la qualité n’est le pré carré de certains membres de l’équipe — c’est tout le contraire !
Amélioration des process de développement
L’amélioration continue est au cœur de Scrum.
En particulier, la Rétrospective est un moment formel pour échanger de la manière dont fonctionne l’équipe et l’améliorer.
Cela inclut bien entendu les process de développement pour être plus efficace bien entendu, mais aussi et surtout améliorer la qualité — en particulier diminuer le nombre de bugs générés.
La section dédiée à la Rétrospective de Sprint du Guide Scrum nous dit :
Le Scrum Master encourage l’équipe Scrum à améliorer, dans le cadre de travail Scrum, son processus de développement et ses pratiques afin de les rendre plus efficaces et agréables pour le prochain Sprint. Lors de chaque rétrospective de Sprint, l’équipe Scrum propose des moyens adéquats pour accroître la qualité du produit tout en améliorant les processus de travail ou adaptant la définition de « Fini », quand cela est nécessaire et non conflictuel avec les normes du produit ou celles de l’organisation.
On en parle également dans la section sur le Definition of Done ou Définition de “Fini” :
Au fur et à mesure que les équipes de Scrum mûrissent, on s’attend à ce que leurs définitions de « Fini » se développent pour inclure des critères plus stricts pour une meilleure qualité.
Pour aller plus loin
Concevoir la qualité autrement
Cet article propose une classification des différents niveaux d’approches de la qualité :
Dans ce webinar hébergé par Applause j’expliquais quelques clés du changement de mindset, de pratiques et de structure pour réussir un passage à l’agilité de la QA :
Le support de présentation est disponible indépendamment ici :
La responsabilité collective de l’équipe Scrum
SAFe
Qu’on aime ou qu’on n’aime pas le Scale Agile Framework, la Built-In Quality fait partie des 4 Core Values de SAFe.
Que pensez-vous de cet article ?
Si vous avez aimé cet article, merci d’applaudir 👏 et de le partager !
Et pensez à souscrire à ma future newsletter : je prévois de quitter Medium, et cela sera le meilleur moyen de rester en contact.
À bientôt 😊
