7 principes Qualité Agile ?

Savoir prioriser et renoncer

Description

La perfection est atteinte, non pas lorsqu’il n’y a plus rien à ajouter, mais lorsqu’il n’y a plus rien à retirer.

Cette phrase n’est pas de moi mais d’Antoine de Saint Exupéry… Elle date d’une époque où il n’y avait pas encore de service numérique et pourtant elle s’adapte parfaitement à la qualité et aux services numériques.

Proposer un service numérique de qualité c’est un équilibre qu’il faut savoir maintenir entre les différents besoins et aspirations des utilisateurs (et utilisatrices) avec la capacité de l’équipe à livrer ces besoins avec un niveau de qualité suffisant.

Pour réussir cela il est important de hiérarchiser ces besoins et aspirations afin de livrer ce qui a le plus de valeur aussi tôt que possible… avec un niveau de qualité satisfaisant pour les utilisateurs et utilisatrices.

Pour cela, les ressources n’étant pas infinies, il est obligatoire de renoncer à certaines fonctionnalités et se dire que certaines ne seront livrées qu’à moyen ou long terme.

Il est intéressant de noter qu’indirectement, cette pratique essentielle répond en partie à la problématique des obésiciels.

Conséquences

Faire de la qualité c’est aussi accepter de ne pas faire ou de remettre à plus tard. Faire toujours plus n’est pas une solution viable pour un service numérique.

Réussir à bien prioriser et identifier les évolutions qui ont le plus de valeur permet de:

  • proposer des fonctionnalités à forte valeur ajoutée (et ne pas s’éparpiller)
  • affiner les fonctionnalités proposées afin de les livrer avec une qualité optimale
  • proposer une qualité globale qui inclut le non-fonctionnel (accessibilité, performances, sécurité, adaptabilité…) afin de proposer une meilleure qualité à l’usage
  • avoir un service plus facilement maintenable

Cela parait super et évident pour la grande majorité des acteurs travaillant dans l’informatique, néanmoins cela est rarement mis en place.

La raison principale ? Le monde dans lequel nous vivons. Nous sommes habitués à avoir tout, tout de suite:

  • Je veux un nouvel ordinateur ou un nouveau téléphone ? Je le commande sur internet et doit le recevoir dans les 24 heures!
  • J’ai faim ? Je commande depuis mon téléphone et doit être livré dans les 30 minutes ou je me fait chauffer un plat préparé 5 minutes au micro-ondes
  • Nous avons la chance, en France, d’avoir de l’eau et de l’électricité à volonté (cela est moins vrai, surtout pour les personnes précaires, avec l’augmentation des prix de l’énergie)
  • Je veux un nouveau jeu ? Je le télécharge en 5 minutes et y joue directement…

La vraie conséquence de ce principe c’est qu’il faut pour faire de la qualité, que l’ensemble des personnes qui construisent un service numérique, arrive à sortir de ses habitudes de consommation de prendre le temps de bien faire, de faire mieux même si cela revient, à court et moyen terme, à faire moins.

Principes du test liés

Ce principe regroupe pas mal de principes du test.

Le plus évident est que les tests exhaustifs sont impossibles. Ce principe nous oblige à faire des choix dans ce que nous allons évalués en priorisant certains tests et en renonçant à d’autres. Si l’on voulait sortir du test on pourrait traduire ce principe par: « le service numérique total est impossible ».

La priorisation ainsi que le fait de se concentrer sur ce qui va apporter le plus de valeur est assez proche du regroupement de défauts.

Enfin, comme souvent dans les principes que je propose: les tests dépendent du contexte. On ne va pas proposer les mêmes fonctionnalités en fonction de son public.

Exemples

Donner des exemples qui parlent à tous est assez complexe pour ce principe. Je vais essayer d’en proposer plusieurs pour qu’au moins un de ceux-ci vous parle.

  • La suite office 365 qui consomme 171 fois plus de ressources qu’office 2010 (slide 25). Les gains sont-ils à la hauteur ?
  • les jeux vidéos indépendants qui proposent des jeux sur un concept fort (ex: Gris, Loop Hero, Ball Pit, Jusant, Hollow Knight…). Ces jeux, très éloignés des triple A, sont pourtant très bien accueillis par les joueurs
  • Une équipe de joueurs qui a travaillé sur un TAS (Tool Assisted Speedrun) de Mario 64 avait renoncé à quelques améliorations découvertes pendant le travail sur ce speedrun afin de le publier
  • le métier qui arrive tous les 2 jours avec une nouvelle urgence à implémenter pour hier

Ce qu’il faut retenir

Faire de la qualité ne rime pas avec faire plus!

Faire de la qualité c’est bien faire, au bon moment ce qu’il faut faire.

Pour cela il est important de prioriser mais aussi, assez souvent, de renoncer. Ce n’est pas un échec mais des choix que l’on se retrouve à faire très souvent dans le test et qui gagnerait à se faire dans de plus nombreux domaines.

Pensez à rejoindre le groupe « Le métier du test » si vous souhaitez échanger sur le test

Merci à tous ceux qui mettent « j’aime », partagent ou commentent mes articles

N’hésitez pas à faire vos propres retours d’expérience en commentaire.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

image des niveaux de test et du quadrant des tests
Agilité

Correspondance entre niveaux de test et quadrants des tests Agile

La transformation Agile transforme le test Les méthodologies Agiles sont de plus en plus présentes dans l’industrie logicielle. Afin d’être dans le mouvement et de répondre à des impératifs de réactivité de nombreuses sociétés se transforment. Des DSI avec des dizaines voir des centaines d’acteurs et habituées à travailler en

Lire la suite »
logo de la taverne du testeur
Retour d'expérience

Ma première expérience dans le test

Contexte Cadre de l’expérience J’ai de la chance, même si je n’ai pas étudié le test en école d’ingénieur j’ai vite été amené à me plonger dedans. En effet, mon stage de fin d’étude en 2011 était un stage d’AMOA (Assistance à Maitrise d’Ouvrage) mais sur un projet important qui

Lire la suite »
Agilité

Implémenter une US en Scrum

Voici un schéma résumant les phases de test et de validation d’une User Story en Scrum: J’ai fait ce schéma car je n’en ai malheureusement jamais trouvé. Voici mes explications:

Lire la suite »