Un manuel à suivre scrupuleusement… pour aller dans le mur et rater sa recette fonctionnelle ! 

Ignorez l’aspect iso prod de l’environnement de recette  

Pour une recette bien inefficace : « Ne vous préoccupez pas de reproduire l’environnement de production pour les tests, cela ne sert à rien. » 

L’aspect iso-prod est un caractère très important dans une recette fonctionnelle.  

Qu’est-ce que l’iso-prod ? 

L’iso-prod signifie que l’environnement de recette est identique à l’environnement de production. L’objectif est de reproduire le plus fidèlement possible les caractéristiques fonctionnelles et techniques. Cela garantit que la recette ait vraiment un sens. 

Et en quoi c’est important pour une recette fonctionnelle ? 

Un environnement de recette iso-prod permet de : 

1. Garantir la fiabilité des tests : en ayant un environnement iso-prod, on garantit que les fonctionnalités testées réagiront de la même manière sur l’environnement de production (et éviter au passage le célèbre : “Moi sur ma machine ça fonctionne nickel”)
2. Faciliter la montée en charge : pour des traitements particulièrement lourd, l’iso-prod peut être quasiment le seul allier pour estimer la charge du déploiement. Que ce soit fait de manière complète ou par extrapolation après un traitement partiel, l’aspect iso-prod permet de mesurer le temps d’exécution et l’impact sur les machines.  

Tout ça paraît logique, mais je ne vois pas pourquoi l’environnement de recette serait différent de celui de production 

Voici un exemple concret de l’importance de l’aspect iso-prod dans l’environnement de recette : celui des mises à jour par batch froid. Le système exécute ces traitements automatisés pendant les heures creuses, lorsque l’activité des utilisateurs est réduite (idéalement la nuit). Ils permettent de mettre à jour les données de l’application et d’effectuer des tâches de maintenance. Par ailleurs, les SI les plus anciens utilisent beaucoup cette approche pour synchroniser les données entre leurs différents applicatifs.

Dans certains cas, les équipes peuvent faire varier la fréquence des mises à jour par batch froid entre l’environnement de recette et l’environnement de production.
Par exemple, les mises à jour peuvent être quotidiennes en production, mais hebdomadaires en recette pour réduire les coûts. Cette différence peut entraîner des écarts de comportement entre les deux environnements. Ce qui rend les tests en recette moins fiables et augmente les risques d’incidents en production. 

Ne mettez pas à jour la documentation du projet  

Pour une recette impossible à maintenir : « Ne vous préoccupez pas des changements entre les spécifications et la réalité, cela ne concerne personne. » 

Les parties prenantes se servent de la documentation comme ensemble d’outils pour communiquer dans un projet. Elle vise ainsi à faire perdurer la connaissance fonctionnelle et technique. Si bien qu’une bonne documentation doit être simple à comprendre et permettre à un acteur externe au projet de se l’approprier .

Bien souvent, on n’a jamais le temps pour la documentation. C’est un investissement en temps conséquent.  On doit mettre à jour régulièrement celle-ci et reprendre tout à chaque évolution. Cependant, c’est une étape nécessaire ! Si l’on néglige la documentation en début de projet, on la néglige généralement encore plus à la fin. C’est pourtant le moment où l’on peut faire le point. Autrement dit, c’est l’occasion d’aborder tout ce qui est développé et ce qui avait initialement été demandé. On parle ici de documentation de référence.  

Sur le long terme, un logiciel sans documentation augmente drastiquement les couts de maintenance. Les choix technico-fonctionnels ne sont conservés que dans la mémoire des acteurs projets. Cependant, un gros turn-over peut transformer une situation simplement désagréable en véritable catastrophe. 

N’impliquez pas les utilisateurs dans la recette 

Pour une recette inutile : «  Ne vous préoccupez pas des utilisateurs. Ils ne savent pas ce qu’ils veulent de toute façon, et cela ne sert à rien de perdre du temps à recueillir leur avis. » 

Ne pas inclure l’utilisateur dans la recette est le meilleur moyen d’implémenter un outil qui explore les budgets ou qui ne sera utilisé par… personne. Un projet vise toujours à résoudre un problème pour l’utilisateur. En effet, un bon chef de projet AMOA séparera le besoin de la solution et concevra une solution qui, en plus de répondre aux besoins fonctionnels, pourra être réalisée dans un délai et avec un coût raisonnables.

Dans les faits, on ne peut jamais penser à tout. Et cette affirmation est vraie pour toutes les parties prenantes ! L’utilisateur final peut oublier de vous apporter des précisions triviales pour lui. Le chef de projet et l’expert peuvent se tromper sur le comportement existant de l’application (cf. la partie précédente, il est bien fait cet article quand même). L’acteur peut également oublier d’être convié aux ateliers… Chaque maillon a sa fragilité et l’implémentation de la première version exige des adaptations pour correspondre mieux à la vision de l’utilisateur.  

Les répercussions…

Ces demandes d’évolutions de dernière minute coûtent cher. Autant en temps qu’en argent. Ces dépenses sont par essence difficile à budgétiser. Elles arrivent généralement à un moment où elles sont déjà en dépassement de 10 % avec un retard de deux semaines.

Pour anticiper au mieux ces demandes et aborder le sujet le plus tôt possible, il est important d’impliquer l’utilisateur dans la recette. L’impliquer dans la recette, ça ne veut pas juste dire qu’il exécute des scénarios de tests (ça serait trop facile). Ça veut aussi dire qu’il faut l’intégrer dans la rédaction de ces scénarios et encore mieux : rédiger avec lui des scénarios d’acceptation. Il faut qu’il puisse au plus tôt s’imaginer utiliser l’outil. La rédaction de spécifications sous forme d’US permet de fluidifier ce process.

Et pour conclure  

En conclusion, pour rater efficacement sa recette fonctionnelle, le seul mot d’ordre est NÉ-GLI-GENCE. Ignorez l’importance de l’iso-prod pour environnement de recette ! N’accordez aucune attention à la mise à jour de la documentation du projet et surtout, n’impliquez pas les utilisateurs finaux dans la recette. En suivant scrupuleusement ces étapes, vous vous assurez un échec retentissant et un projet voué à la désolation. Bon courage.