Méthodes traditionnelles ou méthodes agiles ?
CHAPITRE 2
71
– Le code source soit couvert par des tests unitaires qui limitent considérablement les risques de
régression et les bogues détectés en production (test driven development).
– Les standards de développement soient réellement suivis (collective code ownership) et
vérifiés (intégration continue).
– Votre architecture applicative soit en phase avec le besoin métier auquel elle répond (refactoring).
– Le niveau d’exigence de vos développeurs sur la qualité de leur propre code soit élevé
(rétrospectives).
– La qualité soit l’affaire de tous et non d’un service dédié.
Cela étant, la qualité n’est pas une finalité au sein des méthodologies agiles, c’est simplement
un moyen pour atteindre un niveau de satisfaction client.
2) La réponse de l’expert Antoine Contal, ScrumMaster et coach XP.
Avant d’entrer dans un débat sur la qualité, j’ai pour habitude d’expliciter les différentes réalités
que ce terme peut couvrir. Mon expérience m’a amené à distinguer trois acceptations majeures du terme : la valeur pour le client (qualité-valeur), la conformité aux exigences (qualitéconformité) ou le respect des normes et standards de l’entreprise (qualité-obéissance).
J’ai vécu une expérience frappante dans le cadre d’une entreprise avec un de ces fameux gros
manuels qualité, dont la culture était clairement celle de la qualité-obéissance. Un de mes
projets avait été jugé « de qualité » car j’avais coché les bonnes croix dans les check-lists et
que j’avais obtenu les bonnes signatures pour mes formulaires de validation. Pourtant, ce
projet a abouti à un naufrage désastreux. À peine mise en production, l’application a modifié
des données sensibles de manière aberrante et irréversible. Pire, le service dont elle devait
diminuer la charge de travail a constaté que c’était l’inverse qui se produisait, car il devait
désormais effectuer des ajustements manuels tous les mois.
Dans la même organisation, j’ai participé à un projet dont les enjeux étaient suffisants pour que
je puisse déroger à de nombreuses règles en toute impunité. Ce projet a été un succès éclatant. La date de livraison promise a été tenue. La mise en production a été un non-événement.
Les indicateurs fonctionnels étaient dans le vert. Il a fallu 3 mois avant qu’un défaut, mineur,
soit remarqué. J’ai attiré l’attention de responsables sur cette corrélation inverse entre le
succès du projet et le respect des normes édictées, mais mon message dérangeait, et ils ont
persisté à imposer ces normes.
Par contraste, l’agilité m’incite à privilégier la qualité-valeur. En laissant le client contrôler les
priorités et les changer à chaque itération, je peux optimiser la valeur produite à chaque itération. Et en refusant tout endettement technique ou humain, je garantis que notre capacité à
produire de la valeur plus tard ne diminuera pas. L’agilité favorise aussi la qualité-conformité,
au travers du feedback régulier du client sur site et des tests de recette définis pour chaque
scénario client, mais uniquement sur le périmètre des exigences priorisées jusque-là. L’agilité
ne s’intéresse pas à la qualité-obéissance, mais je peux proposer au client de financer des
scénarios « non fonctionnels » pour faire migrer le logiciel vers une forme respectant les standards de son choix. Simplement, je lui conseillerai d’attendre que l’application ait démontré à
la fois son retour sur investissement et sa pérennité.
GestProjInform Livre Page 71 Vendredi, 3. avril 2009 12:07 12
CHAPITRE 2
71
– Le code source soit couvert par des tests unitaires qui limitent considérablement les risques de
régression et les bogues détectés en production (test driven development).
– Les standards de développement soient réellement suivis (collective code ownership) et
vérifiés (intégration continue).
– Votre architecture applicative soit en phase avec le besoin métier auquel elle répond (refactoring).
– Le niveau d’exigence de vos développeurs sur la qualité de leur propre code soit élevé
(rétrospectives).
– La qualité soit l’affaire de tous et non d’un service dédié.
Cela étant, la qualité n’est pas une finalité au sein des méthodologies agiles, c’est simplement
un moyen pour atteindre un niveau de satisfaction client.
2) La réponse de l’expert Antoine Contal, ScrumMaster et coach XP.
Avant d’entrer dans un débat sur la qualité, j’ai pour habitude d’expliciter les différentes réalités
que ce terme peut couvrir. Mon expérience m’a amené à distinguer trois acceptations majeures du terme : la valeur pour le client (qualité-valeur), la conformité aux exigences (qualitéconformité) ou le respect des normes et standards de l’entreprise (qualité-obéissance).
J’ai vécu une expérience frappante dans le cadre d’une entreprise avec un de ces fameux gros
manuels qualité, dont la culture était clairement celle de la qualité-obéissance. Un de mes
projets avait été jugé « de qualité » car j’avais coché les bonnes croix dans les check-lists et
que j’avais obtenu les bonnes signatures pour mes formulaires de validation. Pourtant, ce
projet a abouti à un naufrage désastreux. À peine mise en production, l’application a modifié
des données sensibles de manière aberrante et irréversible. Pire, le service dont elle devait
diminuer la charge de travail a constaté que c’était l’inverse qui se produisait, car il devait
désormais effectuer des ajustements manuels tous les mois.
Dans la même organisation, j’ai participé à un projet dont les enjeux étaient suffisants pour que
je puisse déroger à de nombreuses règles en toute impunité. Ce projet a été un succès éclatant. La date de livraison promise a été tenue. La mise en production a été un non-événement.
Les indicateurs fonctionnels étaient dans le vert. Il a fallu 3 mois avant qu’un défaut, mineur,
soit remarqué. J’ai attiré l’attention de responsables sur cette corrélation inverse entre le
succès du projet et le respect des normes édictées, mais mon message dérangeait, et ils ont
persisté à imposer ces normes.
Par contraste, l’agilité m’incite à privilégier la qualité-valeur. En laissant le client contrôler les
priorités et les changer à chaque itération, je peux optimiser la valeur produite à chaque itération. Et en refusant tout endettement technique ou humain, je garantis que notre capacité à
produire de la valeur plus tard ne diminuera pas. L’agilité favorise aussi la qualité-conformité,
au travers du feedback régulier du client sur site et des tests de recette définis pour chaque
scénario client, mais uniquement sur le périmètre des exigences priorisées jusque-là. L’agilité
ne s’intéresse pas à la qualité-obéissance, mais je peux proposer au client de financer des
scénarios « non fonctionnels » pour faire migrer le logiciel vers une forme respectant les standards de son choix. Simplement, je lui conseillerai d’attendre que l’application ait démontré à
la fois son retour sur investissement et sa pérennité.
GestProjInform Livre Page 71 Vendredi, 3. avril 2009 12:07 12