Évaluer l’efficacité de la cartographie des chaînes de valeur
Lorsque vous créez une cartographie de flux de valeur ou VSM, cela vous aide à analyser votre processus actuel de cycle de mise en production. L’objectif de la cartographie des chaînes de valeur est de montrer, par le biais d’une représentation visuelle, à quels moments l’équipe crée de la valeur, et à quels moments elle perd son temps. L’objectif est d’arriver à un processus qui délivre une valeur maximale au client avec une perte de temps minimale. La cartographie de flux de valeur peut vous aider à identifier les éléments qui n’apportent aucune valeur au produit, voire qui lui font perdre de la valeur.
Nous allons voir où en est Tailspin.
Mara, qui est nouvelle dans l’équipe, va créer une carte des chaînes de valeur pour mieux comprendre le processus existant. Grâce à cela, elle saura où se situe l’équipe par rapport au modèle de maturité DevOps. Il s’avère que les équipes les plus matures sont celles qui sont généralement les plus rapides à publier, qui ont confiance en elles et qui rencontrent moins de bogues que les équipes moins matures.
Mara sait qu’elle ne comprend pas encore tout. Elle va donc créer un VSM rapide sur le tableau blanc dans la salle de réunion. Il y aura des questions sans réponse, mais ce n’est pas grave. Ce n’est qu’un début. Quand elle aura terminé, elle montrera son travail à l’équipe. La cartographie de flux de valeur offre à chacun un point de départ pour identifier les étapes que doit entreprendre Tailspin pour améliorer le développement et la publication de ses sites web.
Regardons sa carte.
Comprendre le processus actuel
Mara réunit l’équipe pour lui présenter sa cartographie des chaînes de valeur.
Mara : La cartographie de flux de valeur permet de mesurer quelle partie d’un processus apporte de la valeur au client et quelle partie implique une perte de temps sans générer de valeur. Notre carte commence en haut gauche, avec la spécification fonctionnelle du logiciel. Suivons uniquement une fonctionnalité pour voir son parcours dans le cycle actuel de mise en production.
Certaines personnes prennent un air perplexe, mais Mara ne se démonte pas et commence sa démonstration.
Processus de développement
La création d’une fonctionnalité commence par la création d’une étiquette dans le contrôle de code source 
. Nous avons une personne qui peut créer des étiquettes, et c’est Andy. Nous lui envoyons notre demande de création d’étiquette par e-mail. Nous utilisons un système de gestion de versions centralisé. Andy doit donc attendre que tout le code existant soit enregistré et stable avant de créer l’étiquette. Une fois l’étiquette créée, nous recevons un e-mail indiquant que nous pouvons commencer le travail. Ce processus peut prendre jusqu’à trois jours et n’apporte aucune valeur au client. Les processus qui n’apportent rien au client doivent être aussi courts que possible.
Après avoir obtenu l’accès à tous les fichiers dont nous avons besoin, il nous faut environ quatre jours pour coder une fonctionnalité 
. Pour accéder au contrôle de code source, nous devons nous trouver sur le réseau de l’entreprise. Cette fonctionnalité a de la valeur pour le client, car celui-ci en a besoin.
Processus de test
Une fois que notre build est considérée comme stable, nous mettons à jour une feuille de calcul pour informer Amita qu’une build est prête à être testée, et lui indiquons où la trouver 
. Elle en est informée au bout de deux jours.
Amita teste la build manuellement 
. Ce processus devient de plus en plus long à mesure que la base de code grandit. Pour l’instant, partons sur trois jours. Ensuite, elle envoie à Andy les rapports de bogues par e-mail. Les tests n’apportent pas de valeur, mais ils sont nécessaires.
Andy doit alors trier les bogues et attribuer le travail . Andy peut avoir besoin d’un certain temps (jusqu’à trois jours supplémentaires) pour comprendre les problèmes et les affecter aux bons développeurs.
Processus opérationnels
Lorsqu’Amita approuve une build, elle la livre à Tim. Tim doit déployer cette version sur les serveurs de préproduction, en vue de tests supplémentaires. Il est fréquent que les correctifs et les mises à jour nécessaires à l’exécution des sites web n’aient pas encore été installés sur les serveurs de préproduction. Environ deux jours sont nécessaires à Tim pour effectuer le déploiement et les tests sur les serveurs de préproduction. Là encore, même si le déploiement en préproduction n’ajoute aucune valeur, il est nécessaire 
.
Quand une build est prête pour la production, les responsables doivent l’approuver avant qu’elle ne soit déployée. L’approbation est donnée au cours d’une réunion. Quatre jours sont nécessaires pour que les responsables arrivent à se réunir en vue d’examiner la build.
Enfin, Tim déploie la fonctionnalité, qui devient disponible pour le client, ici en haut à droite de la carte. Si la configuration du serveur de production a changé et qu’il n’est plus synchronisé au serveur de préproduction, Tim doit au préalable le mettre à jour, ce qui prend un jour 
.
Calculer les métriques de valeur client
Nous pouvons à présent nous intéresser aux métriques de performances clés pour voir où nous en sommes.
Le délai total correspond au temps qui est nécessaire pour qu’une fonctionnalité soit présentée au client. Dans le cas présent, il est de 22 jours. Le temps de traitement est le temps consacré à une fonctionnalité et qui a de la valeur pour le client. Dans le cas présent, nous comptons quatre jours de programmation et une journée pour le déploiement de la fonctionnalité, soit un temps de traitement total de cinq jours.
Le taux d’activité correspond au temps de traitement divisé par le délai total :
$${Taux\ d’activité\ =\ }{\dfrac{Temps de\ traitement}{Délai\ total}}$$
Cela correspond à notre taux d’efficacité. Pour obtenir un pourcentage, multipliez ce taux d’efficacité par 100. Le résultat est supérieur à 0 et généralement inférieur à 100 %. Un pourcentage élevé indique une plus grande efficacité.
Si nous utilisons nos chiffres, cela donne ce qui suit :
$${Taux\ d’activité\ =\ }{\dfrac{5\ jours}{22\ jours}}{ = 0,23}$$
Multipliez le résultat par 100 et vous obtenez 23 %.
Comme vous pouvez le voir, il y a encore des progrès à faire. De plus, 22 jours pour développer une fonctionnalité est un délai beaucoup trop long.
Tim : Comment cela va-t-il nous aider ?
Dans quelle direction aller ?
Mara : Cela nous permet de voir où nous en sommes et d’identifier les parties du processus où il y a perte de temps. Notre objectif est de réduire au maximum le temps que nous consacrons aux tâches qui n’ont aucune valeur pour le client. Je pense que nous pouvons réellement améliorer notre efficacité en adoptant l’approche DevOps. Tout d’abord, nous pouvons automatiser plusieurs de ces étapes, ce qui fait gagner beaucoup de temps.
Je ne dis pas qu’il faut abandonner nos processus, mais je pense que nous pouvons progressivement les rendre plus efficaces, sans perturber ce qui est déjà en place.
Nous allons regarder deux ou trois choses qui peuvent être améliorées.
Andy : Commençons par le début. Il faut savoir que la création de l’étiquette est un processus assez long. Je dois parler avec tous les développeurs pour leur demander d’archiver leur code, avant de pouvoir créer et tester la build. Si vous savez comment accélérer ce processus, je vous tire mon chapeau.
En plus, j’ai remarqué que votre dessin n’inclut pas la durée de création de la build. Or, pour le moment, cela prend une demi-journée. Il serait intéressant de voir comment cela peut être accéléré.
Amita : En plus, les développeurs ne mettent pas toujours à jour la feuille de calcul pour m’informer qu’une nouvelle build doit être testée. Si on pouvait garantir que l’information passe immédiatement, cela nous ferait gagner bien du temps.
Mara : Très bien ! Je pense que DevOps peut nous aider à résoudre tous ces problèmes.
Andy : Nous n’avons pas le temps de changer de processus pour le moment. Vous avez entendu Irwin. Nous sommes en mode crise !
Mara : Je comprends. Pour l’instant, nous allons faire comme d’habitude. Mais chacun de nous peut penser aux tâches qui lui reviennent et voir comment les améliorer. Nous pouvons déjà apporter quelques petites modifications tout en poursuivant le processus habituel. Ensuite, nous pouvons voir si DevOps peut nous aider sans perturber ce qu’on a. Je vais garder cette carte et les métriques de performances. Si nous décidons d’adopter les pratiques Azure DevOps, nous pourrons réétudier ces chiffres. Nous aurons peut-être besoin de modifier la carte