Au préalable, arrêtons-nous sur ce qu’est le livrable dans le projet. Le livrable “produit”, composante essentielle au projet (celui qui nous occupe) participe à la réalisation de la solution informatique. Les livrables “projet” ne subissent pas les traitements commentés dans cet article.

Le livrable “produit” existe pour une simple et logique raison : un besoin de spécification doit être exprimé par un auteur n’a pas compétences pour produire le résultat attendu ou la solution qu’il souhaite. Si le métier savait développer, structurer des données ou un réseau, intégrer ou déployer; si le développeur savait produire une solution souhaitée sans exigence décrite; si le testeur savait les résultats produits pas le système sous test sans objectifs de test préalablement analysés, etc etc; dans ces conditions, de livrable nous n’entendrions pas parler.

Un livrable peut donc être l’expression ou la spécification d’un besoin métier, d’un composant logiciel, technique ou d’architecture, d’un modèle de conception ou de traçabilité, de jeux de données, d’environnements, d’un plan de test, d’un référentiel d’exigences métier ou de test, d’un backlog, d’une user story ou epic, d’une matrice de risques, d’un guide utilisateur, d’un manuel d’exploitation – je m’essouffle !

Et, peu importe qu’elles soient manuelles ou automatisées, les activités usent et produisent du livrable.

Ensuite, un livrable est déterminé par des attributs indispensables à la prochaine activité ou au prochain processus qu’il servira en tant qu’entrant : une origine, un rédacteur, un objectif, le niveau de détail de son contenu, un destinataire, le délai pour sa réalisation, les critères de sa validation…

Comment cette composante essentielle au projet, le livrable, est appréhendé dans le projet ?

Conservons maintenant, au regard de la liste précédente, les livrables de type “document”, généralement reconnu sous le vocable de spécification; dont l’origine est typiquement le métier, la maitrise d’ouvrage et les destinataires la maitrise d’œuvre et le test, sachant que ces derniers produisent aussi de la documentation (script, bouchons, conditions et cas de test…).

En cycle en V ou dans les projets séquentiels le livrable, attendu comme documentation exhaustive, est reconnu bien malgré lui comme un frein à l’avancement général du projet.

En méthodes agiles – celles réalisées selon le manifeste agile, bien sûr ! – le dialogue est privilégié à la documentation, n’abstenant pas l’équipe à réaliser et maintenir des livrables, que sont backlogs, user stories et cas de test, ainsi que le code.

Dans les 2 cas, les mêmes difficultés concernant le livrable sont souvent ou trop rencontrées, que ce soit pour définir le niveau de détail de son contenu ou pour suivre son statut d’avancement, que ce soit pour s’assurer de sa validation au moment opportun, que ce soit pour préciser les conditions de sa maintenabilité ou de la mise en œuvre des moyens de traçabilité ou ceux de prise en compte des changements qui l’impacteront.

Deux exemples typiques et choisis parmi tant d’autres pour illustrer ces constats :

• Est-ce utile de fournir au développeur une spécification fonctionnelle ou une user story très détaillée pour réaliser un composant ? Pas nécessairement si son code est scripté avec méthode pour supporter une validation sémantique ou fonctionnelle et correctement adapté aux maintenance et évolutions.
• L’absence d’entrants ou des documents non aboutis soutiendront-ils les activités d’analyse et de conception de test du testeur ? La spécification des jeux de données de tests requis et les campagnes de test planifiées ne seront pas pertinentes ni la couverture des objectifs de test appropriée; les tests exploratoires ont leurs limites.

Des solutions envisageables

Des solutions sont souvent entrevues et réalisables autour des phases de préparation et la mise en place de bonnes pratiques.

Préparation

Parce que l’ensemble des activités projet réalisées en équipes dans des contextes contraints, challengeants, complexes (qualifier vos projets comme il le méritent) nécessitent d’être préparés, les objectifs étudiés, les méthodes, outils et ressources sélectionnés, les risques identifiés…C’est ainsi que le processus projet démarre par une pré étude, un avant-projet, que le plan de test initie le démarrage du processus de test. Le Cléa’ch, Coville ou Joyon n’ont pas largué leurs amarres cet hiver la clope au bec et le nez au vent ! Emery n’est pas parti défier le Barça après un apéro au 3 Obus ! Comparaisons exagérées ?

Bonnes pratiques

Parce qu’elles donnent les moyens d’harmoniser des méthodes de travail au sein des équipes, mono ou pluridisciplinaires, d’assurer des transferts de compétences cohérents. Les chantiers des marins suscités n’ont pas changé leurs formules de stratification en cours de construction de leurs machines volantes; la devise d’un de ses chantiers démontre le principe des bonnes pratiques : “ce n’est pas le bateau qui compte, c’est la démarche“.

Revenons aux livrables et aux moyens à mettre en œuvre pour lui apporter valeur ajoutée et efficience, considérant le livrable comme un outil.

Voici une liste personnelle de bonnes pratiques à évaluer pour préparer la qualification des livrables :

La méthode GQM

Adapter la méthode GQM – “Goal Questions Metrics” – qui sert habituellement la définition et l’identification des indicateurs. Des questions typiques donnent des pistes pour qualifier un livrable : quels sont les critères de validation du livrable ? De quel niveau de détail a besoin le destinataire ? Est-ce que le destinataire peut démarrer sa tâche sur une version non validée ? Le contenu et les liens de traçabilité sont-ils mis à jour et comment dans le cadre de la gestion des changements intégrée ou associée au projet ?

Les revues en tant que test statique

Promouvoir les revues, ces méthodes plus ou moins formelles montrent toute leur efficacité pour s’accorder sur un contenu. L’autre avantage incontestable des revues, en tant que technique de test statique, décrite dans l’ ISTQB, est l’identification tôt de défauts potentiels – pas besoin de s’étendre sur le fameux adage “plus un défaut est identifié tard dans le projet, plus il coûtera cher pour son élimination, pour le même projet ou un autre !”. Aussi, associer le livrable à un glossaire est un bon complément aux revues.

Les approches BDD et ATDD

Promouvoir et implémenter les approches BDD et/ou ATDD, pour fournir au développement et au test des entrants uniques pour leurs activités respectives.

Référentiels d’exigences

Développer des référentiels d’exigences partagés entre parties prenantes pour spécifier en une source unique les aspects métiers, fonctionnelles, non fonctionnelles et de solution; le standard ISO 25010 – THE modèle de qualité du système et du logiciel – est un support reconnu pour ce type de démarche.

Analyse d’impacts

Formaliser les analyses d’impacts des changements et y impliquer systématiquement toutes les acteurs concernés – cf. la gestion des changements soutenue par les référentiels de l’ingénierie des exigences IREB et REQB.

En conclusion

S’attacher à traiter le livrable comme composante essentielle au projet est une nécessité et passe par l’application de pratiques qui contribueront à un déroulement optimisé du projet et à faciliter les relations entre ses acteurs.

Considérons le livrable comme partie prenante à part entière du projet séquentiel ou agile et dans les démarches continue ou DevOps. Choyons-le !

Cet article vous a intéressé ? Continuez la lecture sur l’article « Réhabilitons la Stratégie de Test de nos projets IT »