Plan Assurance Qualité et Méthodes Agiles

A la lecture des appels d’offres publics pour la réalisation d’applications logicielles, on assiste ces derniers temps à une percée des méthodes agiles, dont l’utilisation désormais est exigée dans les réponses des candidats ; l’Agile semble donc  enfin unanimement reconnu comme un outil d’amélioration, à la fois du processus de construction des applications, et de la satisfaction des acteurs, qu’il s’agisse des utilisateurs finaux, ou des artisans du système d’information.

Pour autant, la mise en œuvre de l’Agile dans des organisations traditionnelles ne va pas de soi. Le premier problème auquel on se heurte, avant même de commencer le projet, concerne la contractualisation. Ce problème de contractualisation a déjà été abordé sur ce blog. Nous proposons, dans ce billet, de nous concentrer sur un point précis : le Plan Assurance Qualité (PAQ), pièce contractuelle inévitable dans le cadre traditionnel des marchés…

Profitons donc de nos retours d’expérience _ nous avons été récemment amenés à rédiger des PAQ dans un cadre agile, et montrons comment valoriser la qualité dans un projet agile à travers l’exercice du PAQ. Le débutant en agilité trouvera dans ce billet un condensé des pratiques de qualité liées à l’Agile, tandis que l’initié pourra trouver de l’aide pour la rédaction d’un PAQ.

Agile et PAQ : un exercice contre nature ?

A priori, parler de PAQ en Agile peut sembler incongru. En effet, la documentation formelle n’est pas plébiscitée par l’Agile qui préfère le concret, le tangible, à la prose. Par exemple, en Agile, on ne rédige pas de dossiers de spécifications mais on parle de user stories qui sont décrites sous forme de cas de tests. De même, pour la réalisation de la qualité, on préfère dire qu’elle est portée intrinsèquement par la méthodologie plutôt que d’en expliciter les principes dans un document. A fortiori si ledit document doit être rédigé en amont du projet : « stocker » ainsi, en avance de phase, de l’information qui sera amenée à évoluer au cours du projet peut paraître contre-productif. On notera également que l’agile manifesto n’emploie absolument pas le mot qualité… Au-delà de l’anecdote, comment faire quand il s’agit de répondre à un appel d’offres pour lequel la fourniture d’un PAQ quasi finalisé est un élément essentiel de la réponse ?

Rappelons qu’un PAQ, défini selon la norme AFNOR/Z67-100-3, est un « document qui précise les éléments permettant de s’assurer de la mise en œuvre et de l’efficacité des activités prévues pour obtenir la qualité requise ». Il s’agit donc d’expliquer comment l’Agile permet de réaliser la qualité, mais aussi comment on mesure que cette qualité est effectivement réalisée.

Faisons l’exercice.

Avant tout, qu’entend-on par qualité dans le cas d’une application logicielle ? Il nous semble qu’une application de qualité répond aux exigences suivantes :

1. L’application répond au besoin fonctionnel  et permet aux utilisateurs de travailler efficacement
2. Il y a peu, voire pas, d’anomalies
3. L'application est livrée dans les délais  impartis

Comment l’Agile permet-il de répondre à ces exigences ? Examinons chaque point.

L'application répond au besoin fonctionnel et permet aux utilisateurs de travailler efficacement.

En Agile, le besoin fonctionnel est traduit en user stories, elles-mêmes décrites sous forme de tests de recette fonctionnelle. Le simple fait de décrire le test de recette fonctionnelle, tout en fournissant les jeux de données de test, garantit que les développeurs seront en phase avec les attendus. Et si d’aventure, un doute subsiste sur le besoin, la proximité des acteurs prônée par l’Agile permet de le lever sans délai. En effet, équipe fonctionnelle et équipe technique forment une seule et même équipe, qui travaille sur le même plateau projet ; la communication s’en trouve donc largement favorisée. Enfin, l’équipe fonctionnelle recettant au fil de l’eau, les anomalies fonctionnelles sont détectées au plus tôt.

Encore faut-il que les attendus définis par l’équipe fonctionnelle correspondent aux attendus des utilisateurs de l’application. Or, non seulement l’Agile préconise d’associer les utilisateurs finaux au cours d’ateliers de conception fonctionnelle, mais surtout, le développement itératif et incrémental permet de livrer à intervalles réguliers une version fonctionnelle de l’application, qui peut être utilisée pour recueillir le feed-back du métier.

L’Agile met donc en œuvre des pratiques permettant de garantir la conformité de l’application aux attendus fonctionnels.

Il  y a peu, voire pas, d’anomalies

L’Agile prône de respecter des bonnes pratiques de développement permettant de garantir la qualité du code. Parmi ces pratiques, citons le développement par les tests (TDD _ test driven development), la revue de code, les ateliers collaboratifs de design de l’application et le développement en binôme (pair programming). L'utilisation de TDD permet la construction conjointe du programme et d'un « harnais de tests » de non régression. La revue de code permet d’identifier des bugs avant de les rencontrer au moyen d’une relecture du code par un développeur expérimenté ; elle permet également de garantir l’homogénéité du code, et ainsi, son évolutivité ou sa réversibilité. Les ateliers collaboratifs de design de l’application et le développement en binôme permettent de challenger les choix techniques effectués et donc d’améliorer de manière continue la qualité technique.

En parallèle de ces pratiques, le recours à un outillage de l’environnement de développement via des usines logicielles permet de centraliser le code, d’automatiser le build, d’automatiser les tests unitaires. On réduit ainsi le risque d’introduire des erreurs dans le code tout en libérant les développeurs de tâches récurrentes sans valeur ajoutée. Enfin, les outils de reporting logiciel permettent d’analyser de manière automatique la qualité du code.

L’Agile met donc en œuvre des pratiques de développement et un outillage de l’environnement de développement qui optimisent la réalisation de la qualité logicielle.

L’application est livrée à temps

L’Agile prône le pilotage par la valeur : le backlog, c'est-à-dire la liste des user stories à développer, est priorisé en fonction de ce qui a le plus de valeur pour le métier. Le respect des délais de TTM (Time-to-Market) est garanti, grâce à ce mécanisme de priorisation : si un jalon est fixé, la priorisation du backlog assure de pouvoir délivrer pour le jalon une version cohérente du logiciel.

De plus, le développement par itérations courtes permet de garder une visibilité permanente sur le réalisé et le reste à faire. Le reste à faire et la date d’atterrissage sont prédictibles, d’autant plus que l’équipe de développement apprend en quelques itérations à estimer de manière très fiable la complexité des user stories à développer.

L’Agile repose donc sur un mode de pilotage qui garantit de livrer une application fonctionnelle en temps et en heure.

Nous voyons donc qu’il est aisé de décrire les mécanismes permettant d’assurer la qualité en Agile.

Bouclons l’exercice.

Pour boucler l’exercice, il nous reste à montrer que l’Agile rend mesurable la qualité. En somme, quels KPIs pouvons-nous tirer de la méthodologie ?

L’indicateur phare de l’Agile est la vélocité. Calculée à la fin de chaque itération, la vélocité représente le nombre de points de complexité développés pendant l’itération ; sa valeur moyenne et la tendance permettent d’estimer le délai nécessaire à la réalisation du reste à faire. Il s’agit donc de l’indicateur qui va permettre de s’assurer que l’application est livrée à temps.

A côté de la vélocité, les spécifications par les tests permettent intrinsèquement de mesurer la conformité de l’application au besoin : le nombre de tests de recette qui passent est connu au fur et à mesure que la recette s’effectue.

Enfin, l’outillage de l’environnement de développement, et en particulier l’utilisation d’un outil de reporting logiciel, permet de remonter les KPIs de qualité logicielle, qu’il s’agisse du taux de couverture de tests unitaires, de la complexité cyclomatique, de la cohérence des classes ou encore du respect des règles de qualité du code.

Nous voyons donc que l’Agile porte intrinsèquement ou permet d’extraire facilement les KPIs nécessaires à la mesure de la qualité.

En conclusion

Nous avons donc pu voir que l’exercice du PAQ n’est pas si terrible avec les méthodes agiles : il est aisé de trouver de la matière ! Si l’Agile ne revendique pas haut et fort la qualité et la rigueur permettant de l’atteindre, ces dernières sont bien portées en filigrane dans ses valeurs fondatrices. Et si l’exercice peut paraître rébarbatif, il a le mérite de poser sur le papier les vertus de l’Agile, ce qui lui confie un rôle didactique et pédagogique.