Qu'est-ce qu'un flux de valeur?
A value stream is like a roadmap showing all the steps needed to create a unit of value (i.e. a feature) from the idea to the customer's hands. It show the time spent on each step, the delay between steps and is pretty useful to identify wasteful activities and fin ways to make the process smoother and faster.
Value Stream management focuses on two thing: how quickly a customer receives its requested feature and whether the customer realizes the value from those changes.
The concept of Value Stream is central to Lean Thinking. Value Stream already exist in companies, even if they aren't labeled as such.
Un flux de valeur est comme une feuille de route montrant toutes les étapes nécessaires pour créer une unité de valeur (c'est-à-dire une fonctionnalité) de l'idée jusqu'aux mains du client. Il montre le temps passé sur chaque étape, le délai entre les étapes et est assez utile pour identifier les activités à non-valeur ajoutée et trouver des moyens de rendre le processus plus fluide et plus rapide.
La gestion du flux de valeur se concentre sur deux choses : la rapidité avec laquelle un client reçoit la fonctionnalité demandée et si le client réalise la valeur de ces changements.
Le concept de flux de valeur est au cœur de la pensée Lean. Le flux de valeur existe déjà dans les entreprises, même si elles ne sont pas étiquetées comme telles.
Important: tous les temps de cycle sont mesurés en jour calendriers (incluant les fins de semaine), et pas seulement le temps travaillé sur la tâche. Lorsqu'on pense à un temps de cycle, on pense dans la peau du client. Nous voulons répondre à des questions comme quand est-ce qu'on va livrer X? En apprendre plus sur la mesure du temps du cycle.
Comment Axify construit le flux de valeur?
Axify connecte vos outils de développement (c'est-à-dire Jira, Azure DevOps, Jenkins, etc.) pour mesurer votre temps de cycle. Nous mesurons différents temps de cycle en fonction de trois niveaux : le temps de cycle des livrables (c'est-à-dire le temps nécessaire pour terminer une fonctionnalité), le temps de cycle des items (c'est-à-dire le temps nécessaire pour terminer une user story) et le délai de changement (c'est-à-dire le temps nécessaire pour mettre des modifications en production).
Nous pensons que ces 3 niveaux s'influencent mutuellement et nous vous permettons d'inspecter votre temps de cycle à ces trois niveaux. Par exemple, faire des Pull Requests plus petites aura tendance à réduire le temps nécessaire pour terminer une user story, et des user stories plus petites auront tendance à réduire le temps nécessaire pour terminer une fonctionnalité.
Qu'est-ce qu'un livrable?
Chez Axify, nous utilisons le terme « livrable » pour représenter une unité de valeur pertinente pour l'entreprise et les parties prenantes. En général, il s'agit d'une épique ou d'une fonctionnalité. Il s'agit de quelque chose de plus grand qu'une simple histoire utilisateur (« user story »).
Nous utilisons le terme « livrable », car il n'existe pas de norme dans l'industrie. Il n'existe pas deux entreprises qui travaillent de la même manière, certaines utilisent des épiques tandis que d'autres utilisent des fonctionnalités, certaines utilisent les deux. Pour certaines, une épique est plus grande qu'une fonctionnalité, mais pour d'autres, c'est l'inverse. Nous voulions un terme qui soit indépendant de la communauté agile ou d'un cadre (« framework »).
Comment le délai des livrables fonctionne?
Quand vous inspectez l'onglet Délai des livrables, vous allez voir quatre phases. Ces quatre phases sont normalisés, c'est-à-dire qu'elles ne sont pas dynamique en fonction de votre tableau de développement. Le modèle est unique et peut être utilisée pour voir l'ensemble de l'organisation. Il est calculé comme ci-dessous.
Un livrable est configurable dans les Paramètres de projet. Dans Jira c'est une épique. Dans Azure DevOps, vous pouvez choisir de suivre les épiques ou les fonctionnalités.
Le premier jalon est Livrable créé. Axify capture le moment où le livrable a été créé dans votre outil de gestionnaire de projet, et le chronomètre démarre.
Le deuxième jalon est Premier item entré dans le tableau de développement. Le moment qu'Axify détecte qu'un item enfant (ex: user story) entre dans le tableau de développement sélectionné pour le projet dans un status reconnu (ex: To Do), le livrable entre dans cette phase. L'idée est de représenter le moment où le livrable a été délégué à l'équipe de développement, et à ce moment l'équipe peut raffiner le livrable et commencer à travailler dessus.
Le troisième jalon est En Développement. Le livrable entre dans cette phase dès qu'un item enfant tombe En Cours pour la première fois.
Le quatrième jalon est Post-développement, Le livrable entre dans cette phase quand le dernier item enfant a été mis à Done.
Finalement, Axify considère le livrable terminé lorsqu'il a été marqué à Done.
Conseil de pro: vous pouvez toujours vérifier comment nous calculons le délai des livrables. Nous fournissons un tableau dans la page avec les données brutes pour chaque livrable. Il est très utile de voir quel était le délai pour un livrable spécifique et pourquoi cela s'est produit.
Qu'est-ce que le délai des items?
Le temps de cycle d'un item représente le temps nécessaire pour terminer un item. Un item est un élément de premier niveau de votre tableau de développement, il s'agit généralement d'un récit utilisateur, d'un bug, d'une tâche, etc. Nous utilisons le terme item pour rester indépendant de votre fournisseur d'intégration. Par exemple Jira et Azure DevOps ne partagent pas les mêmes termes.
Dans Axify, vous pouvez voir le temps de cycle des items en cliquant sur l'onglet Temps de cycle des items dans la page Flux de valeur (illustré ci-dessous).
Les colonnes en bleu représentent les phases qui signifient En développement pour l'équipe. Les colonnes en gris représentent les phases qui se produisent avant le développement. Vous pouvez modéliser votre flux de travail dans les paramètres du projet, nous nous adaptons à de nombreuses façons de travailler.
L'idée derrière le pré-développement est de refléter le travail qui n'a pas encore commencé son développement, qui est encore en cours de raffinement. Communément appelé travail en amont. Parfois, une équipe aura une colonne « Prêt pour le sprint », en attente d'être développé, puis l'élément est en cours de traitement. Le temps de cycle des items ne prend en compte que les éléments En développement dans son calcul pour mieux refléter le contexte de l'équipe.
Les phases de l'onglet Cycle des items sont dynamiques, ce qui signifie que vous voyez les mêmes colonnes dans votre tableau chez votre fournisseur d'intégration et dans Axify. Nous ne normalisons pas ces phases, cela vous permet de comprendre quelles phases sont les plus encombrées et où le temps est passé.
Conseil de pro : vous pouvez toujours vérifier comment nous calculons le temps de cycle des items. Nous fournissons un tableau dans la page avec les données brutes pour chaque item, il est très utile de voir quel était le temps de cycle pour un item spécifique et pourquoi il s'est produit.
Qu'est-ce que le délai de changement?
Le délai de changement correspond au temps écoulé entre le premier commit et son déploiement en production. Il s'agit de l'une des quatre métriques clés de l'étude DORA. Pour être prise en compte dans le délai de changement, une revue de code (pull request) doit être déployée en production.
Axify décortique le délai de changement en quatre sous-phases: programmation, prise en charge, revue et déploiement.
La phase de programmation reflète le temps passé entre le premier commit et l'ouverture de la revue de code.
La phase de prise en charge représente le temps passé entre l'ouverture de la revue de code et la première interaction reçue (ex: commentaire, réaction, approbation). Cette phase permet d'identifier les goulots d'étranglement dans le flux de travail tels que des revues de code inactives ou bloquées.
La phase de revue illustre le temps passé entre la première interaction reçue (ex: commentaire, réaction, approbation) et l'intégration d'une revue de code. Cette phase reflète le temps passé à faire l'évaluation d'une revue de code ainsi que les interactions entre les membres de l'équipe avant l'intégration de celle-ci.
La phase de déploiement représente le temps de l'intégration d'une revue de code jusqu'à son déploiement.
Astuce de pro : lorsque votre déploiement n'est pas encore configuré, le flux de valeur se replie sur le temps de cycle de vos pull requests. Le temps de cycle des pull requests est un sous-ensemble du délai de changement, il manque simplement la composante déploiement. Cela permet d'avoir toujours une vue partielle de votre efficacité technique.
Où dois-je me concentrer en premier?
Nous avons tendance à examiner les livrables en premier. Combien de temps faut-il pour terminer un livrable ? En règle générale, nous suggérons moins d'un mois pour livrer un livrable. Décomposez les épiques/fonctionnalités, livrez plus tôt mais plus fréquemment.
Nous examinons ensuite le temps de cycle des items. Combien de phases avez-vous ? Identifiez les phases où vous avez un transfert ou une attente d'approbation. Ces phases prennent généralement plus de temps. Recherchez des moyens de les supprimer ou de réduire leur nécessité. Par exemple, si vous avez une phase d'attente d'assurance qualité, nous vous recommandons probablement une initiative de "shift-left on testing" et une approche de "fix-forward" (inspirée de la livraison continue).
Nous examinons également le délai de changement. Les demandes de revue de code sont-elles trop grosses ou le temps de programmation est-il élevé? Les demandes de revue de code sont-elles inactives (temps de prise en charge ou de revue élevé)? Le déploiement en production est-il élevé parce que vous devez déployer dans plusieurs environnements? Recherchez des moyens d'améliorer l'automatisation.
En général, le gain le plus rapide réside dans le délai de changement. L'optimisation de l'efficacité technique aura un impact sur le temps nécessaire pour compléter un item (c'est-à-dire une histoire utilisateur), suivi également des épiques.