Press "Enter" to skip to content

En quoi l’agilité change radicalement la vision de la qualité ?

En quoi l’agilité change radicalement la vision de la qualité ?

Lors d’une transformation agile, la notion de qualité change fondamentalement.

L’organisation du travail

Approche traditionnelle vs. approche agile

A priori, le travail à faire ne change pas. Quoi qu’il arrive les étapes traditionnelles (type cycle en V) existent toujours : il y a du travail de conception, du développement, du test, du déploiement…

Ce qui change, par contre, c’est la temporalité d’exécution de ces étapes :

  • Dans une approche traditionnelle, on fait le maximum du travail de chaque étape avant de passer à l’étape suivante — c’est la fameuse cascade (waterfall en anglais)
  • Dans une approche agile, on mélange toutes ces étapes de travail dans chaque itération et même idéalement chaque jour

Une autre différence, qui découle un peu de la première, est dans la structuration des acteurs afin de faire au mieux le travail :

  • Dans une approche traditionnelle, on structure généralement les équipes autour de ces étapes de travail, afin de maximiser leur productivité individuelle ; c’est ce qu’on appelle généralement des silos de compétence
  • Dans une approche agile, on structure des équipes qui seront collectivement responsables de l’ensemble des étapes de travail, afin de minimiser le temps requis pour créer de la valeur— on parle souvent de Feature Teams

Impact sur la qualité

Approche traditionnelle vs. approche agile

Ce changement de structure impacte directement la qualité :

  • Dans une approche traditionnelle, une étape dédiée de “test” ou “validation” est explicitée. Comme toutes les autres étapes, cette étape a son équipe dédiée d’experts, son silo. Par extension, on en arrive à réduire la qualité à leur unique responsabilité : c’est l’équipe “QA” pour Quality Assurance, Assurance Qualité.
  • Dans une approche agile, mes activités de test se mélangent avec toutes les autres avec une responsabilité partagée. “La qualité est le problème de tous.” S’il existe peut-être toujours des testeurs ou QA dans l’équipe, ils sont là pour apporter et partager leur compétence et non plus pour être les seuls garants de la qualité.

Voici quelques exemples de comportements induits par le choix d’une structure ou d’une autre…

Approche traditionnelle

Focus sur sa propre productivité plutôt que sur la rapidité du système total :

Les testeurs vérifieront pour moi que ça marche ! Moi je dois me dépêcher de coder.

Les silos :

Tester c’est pas mon travail !

Approche agile

Responsabilité collective au sein de l’équipe :

Notre “Definition of Done” dit que ça doit être testé, sinon ce n’est pas terminé. Qui peut donner un coup de main et tester ?

TK Responsabilité partagée : faire quelques échanges, genre “les testeurs vérifieront pour moi, moi je dois me dépêcher” vs. respect DoD “c’est pas terminé, let’s go all together”

TK plus loin que ça encore…. Construire la qualité dans le produit + vision holistique de la qualité car approche produit

TK refaire au propre (notamment minification) des écrans/extracts PowerPoint

Approche traditionnelle vs. approche agile

Cascade/cycle en V : qualité = respect de la spécification

Agile : qualité = super produit

Rôle du QA

Pour aller plus loin

  • Article feature teams — silos
  • Qu’est-ce qu’un testeur agile
Top