Monitoring de la solution

Définition du suivi des solutions

La surveillance de la solution est généralement une technique d'exploitation permettant d'anticiper les problèmes avant que les clients ne s'en aperçoivent. Ce stratagème est proche des objectifs de niveau de service (SLO) qui sont un peu plus stimulants que l'accord de niveau de service (SLA) qui génère généralement des pénalités. La vision de Google sur DevOps surnommée "Site Reliability Engineering" (SRE) utilise largement cette approche [Beyer 2018]. Le SRE introduit un concept nommé Error Budget qui permet de prendre du recul sur les problématiques de SLA. Cette marge peut être consommée lorsque la situation devient difficile et remboursée lorsque le Product Owner (PO) en a besoin.

Ce type de "gestion budgétaire" peut être piloté par Andon, qui se déclenche à partir d'un seuil plus élevé. Cependant, le fait de ne fixer que l'élément qui conduit au déclenchement de l'alerte peut conduire l'équipe à être constamment sous pression. Habituellement, l'équipe tente de réduire la quantité d'effets négatifs (par exemple, le nombre de sites actifs bugs) jusqu'à ce qu'un seuil inférieur soit atteint. Cette technique génère un phénomène de type hystérésis, notamment utilisé dans les systèmes en temps réel pour éviter la surutilisation du système de compensation.

‍

Impact sur la maturité des tests

Le suivi de la solution une fois qu'elle a été déployée est une technique de Shift Right qui conduit l'équipe à en apprendre davantage sur ce qu'elle a livré. Ce retour d'information du client, combiné à des tests internes dans une approche Shift Left, génère une structure d'apprentissage en double boucle [Argyris 1977] [Moustier 2020].

Cette structure en boucles imbriquées peut être assimilée au "Lean Startup" de Ries [Ries 2012], qui part d'hypothèses construites à partir de retours internes et revient aux retours du marché pour valider ces hypothèses. Le retour du marché renforce alors le choix ou conduit à pivoter et à abandonner ce qui semble erroné d'un point de vue client et donc économique.

‍

Cette approche Lean Startup a été adoptée par SAFe avec des "Leading Indicators" (LI's) à fournir dans chaque description d'Epics [SAFe 2021-34]. Ces LI sont des observables qui doivent être pensés et implémentés en même temps que le produit, ce qui est facilité par une testabilité précoce.

Lors de la construction d'un MVP, ces LI peuvent être collectées manuellement afin d'éviter d'investir trop sur une solution qui n'apporte toujours aucun revenu, mais après quelques versions minimales commercialisables(MMR), un "paradigme d'automatisation complète" devrait conduire à une automatisation des observables qui inclurait le retour d'information des ressources, du domaine et de l'entreprise.

Le point de vue d'Agilitest sur cette pratique

Agilitest permet généralement de contrôler la qualité du produit avant sa livraison grâce à l'automatisation des tests. Cependant, certaines organisations autour des solutions SaaS exécutent des tests de fumée quotidiens le matin en arrivant au travail. Ce type d'opération peut fournir une certaine surveillance de base de la solution déployée, au moins du point de vue du domaine. Ajuster l'utilisation initiale d'Agilitest pour alimenter un certain tableau de bord de santé peut être un bon début lorsque la surveillance du produit devient pertinente.

‍

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

‍