Gestion de projet – Vers les méthodes agiles
160
détectés dans le cycle de développement, mais ils sont généralement corrigés ultérieurement.
Le raisonnement qui sous-tend cette approche est le suivant : pour tester, il faut avoir
codé ; afin de ne pas perdre de temps en tests inutiles menés sur des versions intermédiaires de l’application, qu’il faudrait rejouer à nouveau, cette activité est planifiée en
fin de projet. L’inconvénient en est que, si l’on a pris du retard dès le début du projet,
la phase de tests sera sacrifiée, faute de temps et de budget, les tests bâclés, les failles
rapidement « colmatées » et le produit final mis en production dans un état de qualité
plus ou moins satisfaisant.
2. Il en va tout autrement avec la stratégie agile puisqu’on intègre le test dès le démarrage du projet, et non dans une phase dédiée. En effet, on considère que la détection
et la correction tardives des défauts coûtent beaucoup plus cher que lorsqu’ils sont
détectés à leur source (principes du pair-programming).
La recherche de défauts est initialisée dès les premiers développements et est permanente tout au long du projet ; la correction des défauts est une activité parallèle aux
développements, qui s’effectue dans chaque itération ; cela répond à l’objectif de
disposer d’une application toujours opérationnelle, même en cours de réalisation.
Comment faire l’impasse sur une phase finale dédiée aux tests ? Car il est impossible de tout
tester dans chaque itération.
1) La réponse de l’expert Freddy Mallet, consultant spécialisé sur les méthodologies agiles.
Commençons par nous poser à nouveau la question de la finalité des tests. Si on a une vision
contractuelle des tests, on a en effet tendance à les considérer comme un mal nécessaire,
délimité temporellement en fin de projet et permettant d’obtenir un sauf-conduit vers l’environnement de production. Bon nombre de services de développement continuent à s’acheter une
bonne conscience au travers de cette phase finale de tests. Les tests sont alors juste un
moyen de valider officiellement ce qui a été développé.
Si maintenant on aborde les tests sous l’angle de la rentabilité, de la productivité et de la
qualité, quels vont être leurs objectifs ? Il s’agit alors de s’assurer le plus rapidement possible
de la satisfaction du client. Le temps a ici une importance primordiale :
– On va d’abord vérifier que les critères d’acceptation sont bien remplis. Si ce n’est pas le cas,
plus on aura attendu pour détecter cette incohérence, plus le coût de la correction sera élevé
et plus les risques d’impact sur le planning initial seront impor tants.
– Si les critères d’acceptation sont remplis, dans une méthodologie classique, le contrat est
rempli. En agilité, comme la finalité n’est pas que le respect du contrat mais surtout la maximisation du ROI (Return On Investment, Retour sur investissement) perçu par le client, c’est le
test fonctionnel réalisé en collaboration avec le client qui va lui permettre d’affiner sa vision du
produit, jusque-là théorique, pour éventuellement la corriger.
Sous cet angle, considérant un projet de 8 mois, si une fonctionnalité a été développée à la fin
du premier mois, pourquoi attendre 6 mois et demi pour la tester ?
Se pose alors un nouveau problème : comment être certain qu’une fonctionnalité métier recettée au bout de un mois et demi n’a pas subi de régressions au bout des 6 mois et demi
suivants ? En poursuivant le raisonnement, si au bout des 6 mois et demi, il y a eu régression
sur le test fonctionnel, qu’aurons-nous réellement gagné ?
GestProjInform Livre Page 160 Vendredi, 3. avril 2009 12:07 12
160
détectés dans le cycle de développement, mais ils sont généralement corrigés ultérieurement.
Le raisonnement qui sous-tend cette approche est le suivant : pour tester, il faut avoir
codé ; afin de ne pas perdre de temps en tests inutiles menés sur des versions intermédiaires de l’application, qu’il faudrait rejouer à nouveau, cette activité est planifiée en
fin de projet. L’inconvénient en est que, si l’on a pris du retard dès le début du projet,
la phase de tests sera sacrifiée, faute de temps et de budget, les tests bâclés, les failles
rapidement « colmatées » et le produit final mis en production dans un état de qualité
plus ou moins satisfaisant.
2. Il en va tout autrement avec la stratégie agile puisqu’on intègre le test dès le démarrage du projet, et non dans une phase dédiée. En effet, on considère que la détection
et la correction tardives des défauts coûtent beaucoup plus cher que lorsqu’ils sont
détectés à leur source (principes du pair-programming).
La recherche de défauts est initialisée dès les premiers développements et est permanente tout au long du projet ; la correction des défauts est une activité parallèle aux
développements, qui s’effectue dans chaque itération ; cela répond à l’objectif de
disposer d’une application toujours opérationnelle, même en cours de réalisation.
Comment faire l’impasse sur une phase finale dédiée aux tests ? Car il est impossible de tout
tester dans chaque itération.
1) La réponse de l’expert Freddy Mallet, consultant spécialisé sur les méthodologies agiles.
Commençons par nous poser à nouveau la question de la finalité des tests. Si on a une vision
contractuelle des tests, on a en effet tendance à les considérer comme un mal nécessaire,
délimité temporellement en fin de projet et permettant d’obtenir un sauf-conduit vers l’environnement de production. Bon nombre de services de développement continuent à s’acheter une
bonne conscience au travers de cette phase finale de tests. Les tests sont alors juste un
moyen de valider officiellement ce qui a été développé.
Si maintenant on aborde les tests sous l’angle de la rentabilité, de la productivité et de la
qualité, quels vont être leurs objectifs ? Il s’agit alors de s’assurer le plus rapidement possible
de la satisfaction du client. Le temps a ici une importance primordiale :
– On va d’abord vérifier que les critères d’acceptation sont bien remplis. Si ce n’est pas le cas,
plus on aura attendu pour détecter cette incohérence, plus le coût de la correction sera élevé
et plus les risques d’impact sur le planning initial seront impor tants.
– Si les critères d’acceptation sont remplis, dans une méthodologie classique, le contrat est
rempli. En agilité, comme la finalité n’est pas que le respect du contrat mais surtout la maximisation du ROI (Return On Investment, Retour sur investissement) perçu par le client, c’est le
test fonctionnel réalisé en collaboration avec le client qui va lui permettre d’affiner sa vision du
produit, jusque-là théorique, pour éventuellement la corriger.
Sous cet angle, considérant un projet de 8 mois, si une fonctionnalité a été développée à la fin
du premier mois, pourquoi attendre 6 mois et demi pour la tester ?
Se pose alors un nouveau problème : comment être certain qu’une fonctionnalité métier recettée au bout de un mois et demi n’a pas subi de régressions au bout des 6 mois et demi
suivants ? En poursuivant le raisonnement, si au bout des 6 mois et demi, il y a eu régression
sur le test fonctionnel, qu’aurons-nous réellement gagné ?
GestProjInform Livre Page 160 Vendredi, 3. avril 2009 12:07 12