Dans de nombreuses équipes, le travail des développeurs se limite à coder. On vérifie l’absence de défauts après le développement. Cette activité est déléguée à d'autres personnes (rôle de “testeur” au sein de l’équipe), voire à d’autres équipes ou même services dans les plus grandes organisations (QA). La qualité devient alors “leur” problème.
Cette situation à plusieurs conséquences :
Elle encourage la déresponsabilisation progressive des développeurs vis à vis du test, et de la qualité en général.
Elle crée une dépendance et un goulot d’étranglement dans le flux de travail.
Elle crée de la tension entre développeurs et testeurs.
Le code est développé mais ne peut être livré.
L’excellence technique requise par l’Agilité impose d’autres pratiques. On parle notamment de qualité intrinsèque du produit (Built-in quality en anglais). Dans cette approche, la qualité est un enjeu de l’équipe. On tire des bonnes pratiques d’eXtreme Programming (TDD, Pair-Programming, intégration continue, refactoring, …). On cherche à détecter au plus tôt les défauts et à réduire leur nombre. Testeurs et développeurs élaborent collectivement une vision globale de la qualité, ces derniers assurant la qualité technique. Un développement terminé signifie alors qu’on pourrait livrer le changement en production immédiatement.
Comments