Voici la seconde partie de la série d'articles traitant de l'approche Three Ways du DevOps. Cette idée de trois voies proviennent d'un article du blog de Gene Kim ("The Three Ways, The Principles Underpinning DevOps"). Nous passons à la deuxième voie ("The Second Way").


La deuxième voie ("The Second Way") - celle des boucles de feedback ("Feedback Loops") - est illustrée par le schéma suivant :

Le but de la "Second Way" est de raccourcir et d'amplifier les boucles de feedback. L'intérêt du feedback est de nous indiquer comme nous améliorer.

Cela consiste à récupérer les signaux provenant du système et de les renvoyer au début du système pour l'améliorer. C'est ce qui permet de manière plus générale à une organisation de s'améliorer.

L'idée est donc de mesurer le débit du travail réalisé à travers le système. Si la durée des cycles est mesurée, alors le feedback va permettre de les réduire. Par exemple, en mesurant le temps de chargement des pages Web, cela vous permet d'agir pour rendre les utilisateurs du site Web plus heureux car les pages se chargent plus rapidement (de multiples études mettent en évidence cette relation). Il ne vous reste plus qu'à engager des actions pour réduire ce temps de chargement.

Un autre but de la "Second Way" est de comprendre et de répondre aux besoins du client. Un moyen de parvenir à cela est le A/B Testing. Il s'agit d'effectuer une série de tests donnant deux fonctionnalités possibles au client : A ou B. Il s'agit alors d'obtenir un feedback de ces choix faits par le client puis de répondre en déterminant si on va déployer la fonctionnalité A ou B.

Le troisième objectif du "Second Way" est de s'assurer que les personnes concernées aient les informations dont elles ont besoin.

Prenez également le temps d'identifier où vous pouvez obtenir des métriques :

  • sur les serveurs (espace disque disponible, ...),
  • dans les tests unitaires (nombre de tests qui réussissent ou qui échouent),
  • dans les KPI (de chiffre d'affaires, de marge brute, ...),
  • dans les Learning Reviews (parfois appelés Post-mortems),
  • dans les délais de mise en place d'un système de remplacement en cas d'échec (MTTR - Mean Time To Recovery), ...

Puis exploitez ces informations pour optimiser le système. S'il est utile d'étudier de ce qui s'est mal passé, il est également utile de voir ce qui s'est bien passé. Par exemple, s'il y a un taux d'échec important dans l'exécution des tests unitaires, cela signifie qu'il y a un problème au niveau du développement. Même s'il est plutôt correct, il y a matière à l'améliorer.

Mais une fois ces améliorations mises en place, il faut encore les voir, les constater. Si les mesures ne permettent pas de voir d'amélioration, cela signifie deux choses possibles :

  • soit l'idée était mauvaise,
  • soit vous ne regardez pas les bonnes mesures.

Il est donc crucial de mesurer les bonnes choses.


La Deuxième Voie consiste essentiellement à parvenir à trois objectifs : raccourcir et d'amplifier les boucles de feedback, comprendre et de répondre aux besoins du client et s'assurer que les personnes concernées aient les informations dont elles ont besoin.

Lisez l'article traitant de la Première Voie (First Way).


Pensées pour mieux produire

Soyez prévenu dès que mon livre "Pensées pour mieux produire" sera disponible à la vente !

DevOps, Agile, Scrum, Kanban, XP, SAFe, LeSS, Lean Startup, Lean UX, Design Thinking, Craftmanship, Management 3.0, ...

 

Bruno Delb

Agile Coach and DevOps, with an experience in the Medical Device software domain, Management 3.0, Agile games and development (especially on mobile) are my passion.

Search

Ads