La responsabilité du développeur

L'une des conversations qui doit se produire le plus souvent dans notre métier ressemble peu ou prou à cela:

• Ça marche, mais on a des problèmes de qualité parce qu'on a pas de tests automatisés.
• Pourquoi il n'y a pas de tests automatisés?
• [Manager machin] nous a demandé de ne pas les faire pour sortir plus vite, et on nous accorde jamais le temps pour rattrapper la situation. On est pas écouté.

La première étape pour être écouté et pris au sérieux est d'assumer ses responsabilités.

Si on a délivré quelque chose dont la qualité est en-dessous des attentes, implicites ou explicites, c'est notre responsabilité.

Bien sûr, il y a des organisations profondément dysfonctionnelles et de mauvaix managers.

Pour autant, nous devons assumer notre responsabilité: nous produisons le logiciel, c'est donc à nous de garantir qu'il est conforme au niveau de qualité attendu - explicite si possible, implicite souvent.

Si on juge indispensable d'avoir une suite minimale de tests automatisés, la première étape est de ne pas donner prise sur cet élément lors de la négociation de périmètre. (Sidenote: c'est un des effets de bord intéressant du développement dirigé par les tests: l'obtention d'une couverture minimale de tests n'est pas négociable.)

Si on a livré en conscience en-dessous du niveau de qualité qu'on pense nécessaire, c'est notre responsabilité.

Pour être considéré comme des adultes et pris au sérieux dans l'organisation, commençons par nous comporter en adulte.