Dans la plupart des équipes où je suis passé, les responsabilités étaient souvent fortement découpées. Le product owner définit, le développeur code, la Q/A valide. Sur le papier, ça semble fonctionner, chacun à son rôle et ses responsabilités sont bien définies. Ce que l’on constate dans la pratique, c’est exactement l’inverse.
Voir la publication originale
Cette dernière est republiée ici afin de ne pas dépendre entièrement d'une plateforme tierce.
Dans cette chaîne de valeur, la qualité est alors l’étape finale. Elle devient un filet de sécurité plutôt qu’une culture d’équipe. Pourquoi le développeur va-t-il s’assurer dans les moindres détails de l’impact de son travail, puisque la validation est la responsabilité du testeur ?
Les bugs remontent alors tardivement et coutent alors plus cher à corriger. Les uns et les autres vont se renvoyer la responsabilité. Le testeur renvoie la balle au développeur, qui va potentiellement remettre en cause la spécification.
Pourtant, j’ai eu la chance de travailler dans des équipes où la qualité est ancrée dans la culture de l’équipe. Et je parle bien de l’équipe entière, pas seulement de quelques membres. Et ça change tout !
Tout le monde travaille main dans la main. Toute l’équipe est intégrée dans le processus de définition et de validation des spécifications produit. Le développeur va intégrer les tests (qu’ils soient automatisés ou manuels) dans son travail en coordination avec les PO et les testeurs. La QA n’intervient pas uniquement en phase finale, mais est intégré en amont pour challenger la conception et les cas à prendre en compte.
La qualité, ce n’est pas une phase du cycle de développement, c’est une responsabilité partagée. La qualité, ça commence avant même l’écrire des premières lignes de spécifications et ça ne s’arrête qu’une fois la fonctionnalité dans les mains des utilisateurs satisfaits.
