Automatisation des observables

Description

Les observables sont des rétroactions tangibles à partir desquelles des mesures peuvent être générées.

La mesure et l'automatisation sont essentielles dans DevOps. Du point de vue de DevOps, le retour d'information et la mesure sont une nécessité, et ils sont ancrés dans les valeurs fondamentales de la pratique :

• C'est le "M" de "CALMR" de SAFe [SAFe 2021-43] ou le "CALMS" bien connu de Jez Humble [Buchanan 2021].
• Gene Kim, Jez Humble et Patrick Debois (le "père" de DevOps [DevOps Cafe 2010]) ont également écrit quelques principes DevOps sur le retour d'information.
• Le point de vue de Google sur le DevOps nommé "Site Reliability Engineering" (SRE) a également une forte préoccupation pour le retour d'information et les alertes [Beyer 2016].

Ces indicateurs donnent des valeurs qui nous permettent d'avoir un point de vue, tant sur une situation que sur sa projection vers Focus sur la solution globale.

Lorsque les mesures sont effectuées manuellement, les indicateurs peuvent prendre beaucoup de temps et être douteux. Étant donné que DevOps s'appuie aussi fortement sur l'automatisation, c'est la partie "A" dans CALMR/CALMS, les mesures sont en fait automatisées pour faciliter le calcul de ces KPI qui peuvent se trouver à différents niveaux [CFTL 2021] :

• La bonne qualité du produit et des services associés
• La bonne qualité de la livraison et le délai de mise sur le marché (TTM) associé.
• La situation concernant l'automatisation des actions manuelles, y compris les tests scriptés.

Chaque niveau influence la satisfaction du client et renforce l'idée que les tests vont bien au-delà de la simple exécution de scripts automatisés [Bach 2014][Bach 2016]. Les observables permettent en fait de découvrir des problèmes qui ne pourraient pas être couverts par les tests. Les observables font donc partie de l'approche Shift Right.

Familles possibles d'observables : 

1. Les indicateurs clés de performance des produits

• rapport de tests des indicateurs pour avoir une vue sur la conformité aux exigences
• KPIs sur les hypothèses à tester selon l'approche Lean Startup pour viser les besoins du marché au lieu de livrer aveuglément un produit conforme à certaines exigences non pertinentes.
• Des indicateurs de satisfaction des clients/utilisateurs pour s'assurer que le marché appréciera votre hypothèse sur leurs besoins.

1. KPI sur l'efficacité de la livraison 

• Mesure de la qualité du code pour avoir une vue sur la dette technique et les changements à venir.
• Sur le pipeline de lancement pour garantir la capacité de l'équipe à livrer de nouvelles versions aussi rapidement que possible
• Des indicateurs de productivité et de TTM pour savoir à quelle vitesse les besoins du marché peuvent être mis à disposition pour commencer à produire des revenus à partir du temps investi dans l'idéation de fonctionnalités.
• Des indicateurs de satisfaction des employés pour s'assurer que vos moyens de production humains seront en mesure de tenir leurs promesses sur le long terme [Moustier 2019-2].

1. KPI sur l'automatisation

• La bonne qualité de ce qui est automatisé pour s'assurer que votre automatisation des tests est suffisamment bonne pour fournir des produits de qualité constante qui ne seront pas vidés par des faux positifs déduits par des scripts de test automatisés. 
• L'efficacité du service fourni par l'automatisation pour voir si l'automatisation est bonne pour le produit.
• Le bon déroulement de l'activité d'automatisation et sa rapidité pour contrôler la capacité de l'automatisation à traiter les services le plus rapidement possible.

Ces indicateurs de performance clés basés sur l'observation doivent être sélectionnés en fonction du contexte de votre projet ; toutefois, ils doivent être équilibrés comme dans le système des cartes de pointage équilibrées.

Impact sur la maturité des tests

Dans le contexte SAFe, les épopées sont formalisées par une partie "Leading Indicators" (LI). Ces LI décrivent un ensemble de métriques permettant de mesurer la proximité d'une valeur de flux par rapport aux attentes. À un moment donné, ces mesures doivent être mises en œuvre par le biais d'une User Story (US) qui code la génération d'observables et la métrique qui va avec [SAFe 2021-34].

En fait, n'importe quel site US peut virtuellement contribuer à l'élaboration de telles mesures, à condition que la définition de l'état prêt (DoR) comprenne une analyse des possibilités de générer des observables à partir de LI. Cette analyse des opportunités peut être facilitée par une gestion des dépendances, notamment par une technique de cartographie d'impact [Adzic 2013] :

• à partir d'un objectif, les acteurs (par exemple, les humains ou les machines) sont identifiés
• pour chaque acteur, les impacts sont définis
• pour chaque impact, des "livrables" sont définis, tels que les objectifs des tests et, bien sûr, les observables éventuels.

‍

Outre le retour d'information sur la qualité de votre produit, les observables doivent également être utilisés pour faciliter la tâche des équipes opérationnelles, comme le service d'assistance qui surveille la santé du produit, mais aussi des équipes d'idéation qui peuvent utiliser les résultats de ces observables pour aider à la prise de décision concernant l'amélioration, la correction, la prévention ou éventuellement la mise au rebut [SAFe 2021-34].

Il semble donc que les observables mènent à l'alerte. Les observables et l'alerte appropriée garantissent l'innovation grâce au retour d'information, à condition que

• l'alerte(Andon) est efficace pour une action corrective immédiate
• le processus de livraison est rapide (moins de 10' - voir SMED)
• les incidents sont limités à un petit nombre d'utilisateurs afin d'éviter d'avoir un impact sur l'ensemble des utilisateurs (voir Canary Releasing).

Dans ces conditions, certaines équipes réduisent la quantité de tests d'intégration pour permettre aux utilisateurs de déclencher des "cas de coin" qui auraient demandé beaucoup de temps pour concevoir ces tests.

Les observables sont un pilier de DevOps. Ce pilier permet en fait une approche des tests qui mise sur une automatisation poussée. C'est la conséquence nécessaire pour accélérer les livraisons et prendre soin des clients.

Le point de vue d'Agilitest sur cette pratique

Cliquez ici pour demander le point de vue d'Agilitest.

‍