Les jalons sont évalués objectivement

Description

En agile, les jalons sont, entre autres, les moments où le produit est livré au client. Il existe d'autres types de jalons tels que la livraison de chaque User Story (US). SAFe propose d'autres jalons comme le Program Increment (PI) qui encadre classiquement quatre sprints consécutifs de deux semaines [SAFe 2021-14].

L'intérêt de cette pratique est que chacun de ces jalons doit être encadré par des critères vérifiables qui permettent de dire si le jalon a été atteint.

En agilité, cette pratique doit absolument être combinée avec l'approche incrémentale, sinon on retombe dans l'effet cascade et tunnel [SAFe 2021-5].

Application à la maturité des tests

Sur les US, cette pratique se retrouve dans Scrum avec la notion de "Definition of Done" [Schwaber 2020]. Elle correspond à une liste de critères communs à toutes les unités, auxquels s'ajoutent des critères d'acceptation spécifiques à chaque unité. L'objectif de ces critères est :

• fournir à l'avance le travail à effectuer afin de savoir quand un US est terminé et de faciliter son évaluation dans le sprint
• de connaître l'étendue exacte de ce qui est livré, notamment à travers les exemples décrits, testés et réussis
• d'informer les clients de chaque US de ce qui a été contrôlé afin de connaître clairement les limites de la fiabilité.

‍

A l'image de ce que l'on voit sur un US doit donc se retrouver sur les différents objets d'idéation tels que :

• les épopées
• Les capacités et caractéristiques de SAFe [SAFe 2021-15].
• le contenu des sprints et des IP

mais aussi :

• le code, d'où la cohérence de l'utilisation du TDD qui répond aux mêmes types de critères
• les différents composants validés et leurs interactions
• le système livré et ses conditions d'acceptation par le client (ce que l'on appelle la réception) ou plus généralement d'opérabilité par les équipes de gestion des opérations, les "Ops".

‍

Ce besoin de critères est d'autant plus vrai qu'avec la quantité d'objets accumulés, si ces critères ne sont pas clairs, on finit rapidement par ne plus savoir ce qui fonctionne et ce qui ne fonctionne pas et la dette technique [Cunningham 1992] [Moustier 2019-1] s'accumule avec pour conséquence un enchevêtrement complexe de problèmes difficiles à résoudre.

La position d'Agilitest sur cette pratique

Agilitest facilite l'automatisation des tests fonctionnels au niveau du système et des composants.

Cette automatisation permet de démontrer efficacement le bon fonctionnement des pièces livrées à tout moment, à condition que les critères d'acceptation fonctionnelle aient été identifiés, scénarisés et inclus dans la plateforme de test.

Cependant, ce fonctionnement correct ne permet d'obtenir qu'un produit conforme aux attentes fonctionnelles et ne dispense en aucun cas des vérifications liées aux exigences non fonctionnelles souvent liées aux conditions d'opérabilité telles que [IS0 25010 2011] :

• performance du logiciel
• compatibilité
• facilité d'utilisation
• fiabilité
• sécurité
• maintenabilité
• portabilité

‍

Pour découvrir l'ensemble des pratiques, cliquez ici.

‍