Les aspects de la qualité à ne pas oublier lors du démarrage d’un projet Agile

Autant du côté des TI que du côté du client, personne n’oserait dire que la qualité de son logiciel n’est pas importante. Le logiciel doit avant tout être sans faille, sans anomalie visible aux utilisateurs. Mais est-ce suffisant? Déployons-nous suffisamment d’efforts lors du démarrage d’un projet pour bien établir les critères de qualité attendue?

Il est vrai que la qualité est difficile à mesurer et surtout à bien doser en développement logiciel. Tout d’abord, nous ferons la distinction entre deux types de qualités :

• Qualité externe : Elle est visible aux utilisateurs. Elle implique plusieurs aspects comme la fiabilité, la performance, la facilité d’utilisation, la sécurité, etc.

• Qualité interne : Elle n’est pas visible aux utilisateurs. Elle touche surtout l’équipe de développement ou d’installation. Elle implique plusieurs aspects comme la maintenabilité du code, la facilité d’installation, la facilité à tester, etc.

Un bon dosage des deux types de qualité est essentiel. Chaque Product Owner se demande comment livrer de la valeur tout en assurant un produit dont le niveau de qualité interne et externe est constant.

En matière de qualité externe, si les critères n’ont pas été définis, la qualité et les éléments non fonctionnels seront négligés ou, du moins, l’accent sera davantage mis sur les fonctionnalités. Imaginons le développement d’une application qui devra être en mesure de supporter 100 000 utilisateurs simultanément. Il sera essentiel de fixer, et ce, dès le début, les critères d’efficacité et de robustesse attendus. Sur la base de ces critères, le Product Owner devra prévoir au carnet de produit des éléments non fonctionnels prioritaires. De plus, des tests de performance permettant d’assurer une connectivité et un temps de réponse adéquats seront aussi à prévoir le plus rapidement possible dans le projet. De fait, plus les tests sont effectués tardivement dans le projet, plus les corrections à apporter sont coûteuses, le cas échéant.

En ce qui concerne la qualité interne, ça se complique. Comme elle n’est pas visible aux utilisateurs, les clients n’y sont pas toujours sensibilisés. Il est important pour l’équipe de développement de faire part au Product Owner de ses enjeux techniques et aussi de lui faire comprendre l’importance d’investir dans la qualité interne du produit. En particulier, quand le logiciel a une longue durée de vie et qu’il est appelé à évoluer dans le temps. La définition de « terminé » (definition of done ou DoD) utilisée par les équipes Agiles contient des activités comme la revue de code. Mais, est-ce suffisant pour assurer la qualité interne d’un produit? Quels seraient les impacts et les coûts à moyen ou long terme de ne pas se soucier de la qualité interne?

Par exemple, prenons un produit que nous prévoyons livrer en plusieurs étapes. Il est très important de penser comment il s’installera, à savoir ses conditions d’installation (installability). Si l’équipe n’y a pas bien réfléchi et si cet aspect n’est pas bien planifié au cours des sprints, l’installation du logiciel sera pénible et coûteuse (c.-à-d. que ça coûtera plusieurs heures d’inefficacité à l’organisation).

Dès le démarrage du projet, nous avons besoin d’une vision d’affaires et d’une vision fonctionnelle du logiciel à développer. De la même façon, il est essentiel d’avoir une vision non fonctionnelle. Cette dernière définira de quelle façon le produit devra répondre aux aspects relatifs à la de qualité externe et interne.

Pour choisir les critères de qualité qui composeront la vision non fonctionnelle, la norme ISO suivante peut être utilisée :

Pour définir la vision non fonctionnelle, le Product Owner et l’équipe de développement devraient avoir des discussions avec un architecte logiciel. Il peut être utile de se poser les questions suivantes :

• Combien d’utilisateurs utiliseront l’application simultanément?
• Quelle est la croissance estimée de l’application?
• Pendant combien de temps faudra-t-il la maintenir?

Une fois la vision bien établie et clarifiée, il est important de l’afficher pour que l’équipe puisse facilement s’y référer. Une compréhension commune de l’importance des aspects non fonctionnels aidera l’équipe dans l’implémentation de solutions adaptées.

Afin de respecter cette vision, le Product Owner devra inclure des éléments non fonctionnels prioritaires dans son carnet de produit. De plus, il devra les prioriser de façon responsable tout en tenant compte des éléments fonctionnels.

Sous chacun des aspects relatifs à la qualité, il se cache beaucoup de travail. Il est donc très important de bien les comprendre, car le coût de ne pas en tenir compte est de loin supérieur à celui d’être proactif.

Mon prochain billet traitera de méthodes efficaces pour arriver à mettre le tout en place et bien prioriser les aspects relatifs à la qualité…