Que fait-on dans la dernière itération ?
24 juin 2006 Olivier Azeau En français 3
Dans un billet récent, Claude Aubry rapporte l'existence de plusieurs articles sur l'agilité dans l'édition de juin 2006 de 'Software Test & Performance'. Un de ces articles, signé Dean Leffingwell, décrit les méthodes agiles du point de vue de l'activité de test. Cet article est de bonne qualité, ou presque. Dans la toute dernière partie, celle où l'on décrit le passage de la théorie au monde réel, il y est raconté à quel point il est impossible de tout tester dans chaque itération et que certains aspects du logiciel ne peuvent, en fin de compte, n'être testés qu'à la fin lors d'une itération dite de "durcissement".
S'il est vrai que la dernière itération peut avoir un statut particulier (le RUP parle, par exemple, de phase de transition), on peut légitimement se demander si les activités de test et de correction de bugs décrites dans cet article y ont véritablement leur place. J'ai abordé ce point en commentaire sur le billet de Claude Aubry mais, en réfléchissant un peu, je me suis dit qu'il y avait matière à creuser un peu plus le sujet.
Dean Leffingwell écrit :
In addition to finalizing any testing activities described above, a hardening iteration may be needed to:
Est-ce que l'on fait des tests de performance sur le système cible dans la dernière itération ?
On peut en faire mais qu'est-ce que cela va rapporter ? Soit on trouve de bonnes performances et on est content. Soit on trouve des performances moyennes et tout ce que l'on peut dire c'est qu'il faudrait un système avec plus de CPU/RAM/Disque (rayer les mentions inutiles).
Si l'aspect performances est important, ce n'est pas au dernier moment qu'il faut s'en préoccuper. Imaginons un système qui, pour bien fonctionner, doit effectuer des batchs de consolidation durant la nuit afin que les utilisateurs puissent travailler le lendemain matin. La performance de ce système est critique : si le batch ne peut pas passer pendant la nuit par manque de temps, tout autre développement est inutile. Il serait impensable de tester les performances d'un tel système après avoir écrit tout le code. Les tests en question doivent être impérativement automatisés (quoi de plus simple que d'automatiser la mesure du temps d'exécution d'un batch ?) et attentivement surveillés durant tout le développement.
Ce cas de besoin de performance est peut être un cas limite mais pour tous les autres qui ne le sont pas, a-t-on vraiment besoin de se préoccuper de performance quand celle-ci n'est pas ressentie comme un besoin ?
Est-ce que l'on teste sur des plateformes différentes dans la dernière itération ?
La question est similaire à celle de la performance évoquée précédemment : soit on se rend compte que notre toute nouvelle application tourne aussi sous Windows 3.1 et on est content, soit on se rend compte que ce n'est pas le cas et on entérine le fait...
Soyons clairs : ce n'est pas en testant au dernier moment diverses plateformes que l'on peut espérer développer un logiciel multi-plateformes !
Est-ce que l'on corrige des bugs mineurs dans la dernière itération ?
Non. De manière générale, je pense qu'il faut éviter de toucher à son compilateur. Par définition, il ne peut pas y avoir de fonctionalité à rajouter ou de bug à corriger. Le client ayant fixé ses priorités, tout ce qui est demandé au dernier moment est forcément moins attendu que ce qui a été demandé avant. N'ayant plus, par la suite de possibilité de rattraper une erreur, il vaut mieux ne pas prendre le risque de casser des choses qui fonctionnent et qui sont plus prioritaires.
Est-ce que l'on fait du nettoyage technique dans la dernière itération ?
Pourquoi pas mais la vraie question c'est 'Pourquoi le nettoyage en question n'a-t-il pas été fait avant ?' Une bonne approche agile va faire du nettoyage technique dans chaque itération. Dans de telle conditions, il est acceptable de continuer dans la même logique et d'effectuer le nettoyage manquant. Mais cela ne constituera pas une nouvelle itération, on est plutôt dans la terminaison de l'itération précédente. Dans l'hypothèse où aucun nettoyage n'a été effectué précédemment, les choses sont claires : le risque est trop grand de casser ce qui fonctionne déjà.
Est-ce que l'on écrit la documentation utilisateur dans la dernière itération ?
On pourrait mais je ne crois pas que cela soit une bonne idée.
Un gain important issu d'une démarche agile est la planification réaliste de la charge de travail. eXtreme Programming, entre autres méthodes, utilise la notion de vélocité pour prédire au mieux les possibilités d'effort à venir en ayant mesuré les efforts passés. Cette pratique n'est possible que si les travaux sont de même nature au fil des itérations. Ce n'est bien évidemment pas le cas si l'on rédige de la documentation alors qu'auparavant on n'a fait que du code.
Il est beaucoup plus sain de rédiger cette documentation au fil de l'eau : si un manuel utilisateur doit être livré, une user story ne devrait pas être terminée tant que le manuel n'a pas été mis à jour en conséquence.
Cela, bien sûr, suppose que l'équipe de développement écrive la documentation utilisateur ce qui n'est pas toujours le cas car il peut y avoir une équipe de rédacteurs dédiée -- mais dans un tel cas la mise en oeuvre d'une démarche agile pose d'autres problèmes.
Alors que fait-on ?
Le bon reflexe agile serait de dire : "on s'adapte". On fait ce qu'il était effectivement impossible de faire avant. Par exemple :
Mais le point le plus important c'est, à mon avis, le manifeste agile qui nous le donne :
Quel meilleur moment que la livraison d'une version pour prendre un peu de recul sur la façon de travailler et en tirer les enseignements qui s'imposent ?
S'il est vrai que la dernière itération peut avoir un statut particulier (le RUP parle, par exemple, de phase de transition), on peut légitimement se demander si les activités de test et de correction de bugs décrites dans cet article y ont véritablement leur place. J'ai abordé ce point en commentaire sur le billet de Claude Aubry mais, en réfléchissant un peu, je me suis dit qu'il y avait matière à creuser un peu plus le sujet.
Dean Leffingwell écrit :
In addition to finalizing any testing activities described above, a hardening iteration may be needed to:
- Perform system level and performance testing in the context of a production environment
- Test on all platforms (OS, databases, Web servers, etc.), rather than just the reference platform that was used for primary development
- Reduce lower priority defect counts that may have grown during previous iterations
- Reduce or eliminate technical debt: minor refactors, bottlenecks, etc., that may have accrued
- Finalize other whole product artifacts: user manuals, release notes, read me, sales materials, etc., that may also lag or need to be put into more final form
Est-ce que l'on fait des tests de performance sur le système cible dans la dernière itération ?
On peut en faire mais qu'est-ce que cela va rapporter ? Soit on trouve de bonnes performances et on est content. Soit on trouve des performances moyennes et tout ce que l'on peut dire c'est qu'il faudrait un système avec plus de CPU/RAM/Disque (rayer les mentions inutiles).
Si l'aspect performances est important, ce n'est pas au dernier moment qu'il faut s'en préoccuper. Imaginons un système qui, pour bien fonctionner, doit effectuer des batchs de consolidation durant la nuit afin que les utilisateurs puissent travailler le lendemain matin. La performance de ce système est critique : si le batch ne peut pas passer pendant la nuit par manque de temps, tout autre développement est inutile. Il serait impensable de tester les performances d'un tel système après avoir écrit tout le code. Les tests en question doivent être impérativement automatisés (quoi de plus simple que d'automatiser la mesure du temps d'exécution d'un batch ?) et attentivement surveillés durant tout le développement.
Ce cas de besoin de performance est peut être un cas limite mais pour tous les autres qui ne le sont pas, a-t-on vraiment besoin de se préoccuper de performance quand celle-ci n'est pas ressentie comme un besoin ?
Est-ce que l'on teste sur des plateformes différentes dans la dernière itération ?
La question est similaire à celle de la performance évoquée précédemment : soit on se rend compte que notre toute nouvelle application tourne aussi sous Windows 3.1 et on est content, soit on se rend compte que ce n'est pas le cas et on entérine le fait...
Soyons clairs : ce n'est pas en testant au dernier moment diverses plateformes que l'on peut espérer développer un logiciel multi-plateformes !
Est-ce que l'on corrige des bugs mineurs dans la dernière itération ?
Non. De manière générale, je pense qu'il faut éviter de toucher à son compilateur. Par définition, il ne peut pas y avoir de fonctionalité à rajouter ou de bug à corriger. Le client ayant fixé ses priorités, tout ce qui est demandé au dernier moment est forcément moins attendu que ce qui a été demandé avant. N'ayant plus, par la suite de possibilité de rattraper une erreur, il vaut mieux ne pas prendre le risque de casser des choses qui fonctionnent et qui sont plus prioritaires.
Est-ce que l'on fait du nettoyage technique dans la dernière itération ?
Pourquoi pas mais la vraie question c'est 'Pourquoi le nettoyage en question n'a-t-il pas été fait avant ?' Une bonne approche agile va faire du nettoyage technique dans chaque itération. Dans de telle conditions, il est acceptable de continuer dans la même logique et d'effectuer le nettoyage manquant. Mais cela ne constituera pas une nouvelle itération, on est plutôt dans la terminaison de l'itération précédente. Dans l'hypothèse où aucun nettoyage n'a été effectué précédemment, les choses sont claires : le risque est trop grand de casser ce qui fonctionne déjà.
Est-ce que l'on écrit la documentation utilisateur dans la dernière itération ?
On pourrait mais je ne crois pas que cela soit une bonne idée.
Un gain important issu d'une démarche agile est la planification réaliste de la charge de travail. eXtreme Programming, entre autres méthodes, utilise la notion de vélocité pour prédire au mieux les possibilités d'effort à venir en ayant mesuré les efforts passés. Cette pratique n'est possible que si les travaux sont de même nature au fil des itérations. Ce n'est bien évidemment pas le cas si l'on rédige de la documentation alors qu'auparavant on n'a fait que du code.
Il est beaucoup plus sain de rédiger cette documentation au fil de l'eau : si un manuel utilisateur doit être livré, une user story ne devrait pas être terminée tant que le manuel n'a pas été mis à jour en conséquence.
Cela, bien sûr, suppose que l'équipe de développement écrive la documentation utilisateur ce qui n'est pas toujours le cas car il peut y avoir une équipe de rédacteurs dédiée -- mais dans un tel cas la mise en oeuvre d'une démarche agile pose d'autres problèmes.
Alors que fait-on ?
Le bon reflexe agile serait de dire : "on s'adapte". On fait ce qu'il était effectivement impossible de faire avant. Par exemple :
- Former l'ensemble des utilisateurs
- Mettre en route un déploiement
- ...
Mais le point le plus important c'est, à mon avis, le manifeste agile qui nous le donne :
At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.
to become more effective, then tunes and adjusts
its behavior accordingly.
Quel meilleur moment que la livraison d'une version pour prendre un peu de recul sur la façon de travailler et en tirer les enseignements qui s'imposent ?
Du coup, il n'y a plus qu'à supprimer cette dernière itération !