Amélioration du flux de travail

L’équipe de développement de produits d’Olympus Mobility est une équipe pluridisciplinaire composée de développeurs back-end, d’un développeur web, d’un développeur d’applications mobiles, d’un concepteur de produits ainsi que du directeur technique et du directeur général qui se partagent le rôle de gestion des produits.

Nous construisons la plateforme Olympus Mobility et travaillons également avec le groupe KBC pour intégrer nos services dans l’appli KBC Mobile Banking.

Au début de l’année 2022, l’équipe de développement de produits a décidé qu’elle voulait accélérer le rythme, car elle éprouvait plus de difficultés à respecter les dates de sortie.

Nous voulions prendre du recul pour analyser la situation et trouver des moyens de nous améliorer. Cet article de blog décrit les démarches que nous avons entreprises pour identifier les problèmes et la manière dont nous les avons abordés afin de pouvoir créer une valeur plus rapidement tout en offrant une meilleure qualité.

1. Visualiser le travail

Niveau de l’élément de travail

Tout d’abord, nous avons déterminé comment obtenir des données utiles sur le travail accompli, puis nous avons trouvé des façons de visualiser le travail du mois précédent dans l’espoir d’en tirer des enseignements.

Nous nous sommes penchés d’abord sur le niveau des éléments de travail et avons exporté des données de JIRA. Un élément de travail peut être une story ou un bug.

Nous avons exporté le temps de cycle des éléments de travail pour notre processus de livraison pour la période allant du 1er octobre 2021 au 15 avril 2022. Le temps de cycle est le temps qu’un élément de travail passe en tant que travail en cours dans une série prédéfinie de limites du processus. Comme limites du processus, nous avons pris le moment où un développeur prend en charge un élément de travail pour son implémentation jusqu’à ce qu’il soit terminé et prêt à sa mise en production. Ce délai comprend le temps nécessaire à l’implémentation de l’élément de travail, à une évaluation par les pairs et à une phase d’assurance qualité. Nous nous sommes concentrés sur cette partie du processus parce que les membres de l’équipe se sentaient stressés par la charge de travail, les changements de contexte et le manque de prioritisation et que nous disposions de données fiables.

Le temps de cycle que nous avons calculé ne comprenait pas la mise en production elle-même, car elle avait lieu toutes les deux semaines et n’était pas suivie dans JIRA avec un état séparé de flux de travail.

Le temps de cycle pour tout notre travail des fonctionnalités est visualisé ici dans un diagramme de dispersion du temps de cycle [1] :

Dans un diagramme de dispersion du temps de cycle, chaque point représente un élément de travail. L’axe horizontal du diagramme indique quand l’élément de travail a été achevé. L’axe vertical indique combien de temps l’élément de travail est resté en cours d’exécution dans les limites du processus que nous avons choisies. Dans ce diagramme, nous avons choisi des jours comme unité de temps.

Ce graphique nous montre que 50 % des éléments de travail qui ont été achevés entre le 1er octobre 2021 et le 15 avril 2022 l’ont été dans un délai de 3 jours. 85 % de tous les éléments de travail ont été réalisés dans un délai de 11 jours et 95 % dans un délai de 32 jours.

Moins il y a de variabilité dans le temps de cycle, plus vous êtes prévisible en tant qu’équipe et, dans notre cas, nous pensons qu’un pourcentage de 85 % des éléments de travail achevés en 11 jours n’est pas du tout un mauvais résultat.

Les enseignements que nous avons tirés de cet exercice :

• Nous devrions nous concentrer sur les éléments de travail « en cours » qui passent le cap des 8 à 10 jours, car il semble qu’une fois ce seuil franchi, ils restent souvent en cours d’exécution pendant une période prolongée. Nous devons accorder plus d’attention à l’âge des éléments de travail et agir pour éviter les temps de cycle prolongés.
• Nous pouvons aussi analyser les valeurs aberrantes pour comprendre pourquoi ces éléments de travail ont pris autant de temps et déterminer s’ils ont un point commun auquel nous devons prêter attention.
• D’une manière générale, nous sommes très satisfaits du temps de cycle des différents éléments de travail pour cette partie de notre processus de développement de produits et nous ne pensons pas qu’il soit nécessaire d’aller plus loin pour le moment.

Niveau des fonctionnalités

Ensuite, nous sommes passés au niveau supérieur, à savoir le niveau des fonctionnalités. Par fonctionnalité, nous entendons un livrable plus grand qui nécessite d’achever de nombreux éléments de travail avant de produire une valeur. Quelques exemples de fonctionnalités sont : étendre notre application mobile pour permettre aux utilisateurs de recourir à un service de covoiturage ou de commander un ticket de train.

L’équipe avait l’impression de travailler sur plusieurs choses à la fois et, lorsque nous avons examiné les données, voilà ce que nous avons constaté :

• en octobre 2021, nous avons travaillé sur 5 fonctionnalités en parallèle
• en novembre 2021, nous avons travaillé sur 4 fonctionnalités en parallèle, mais deux d’entre elles étaient nouvelles. Nous avons suspendu le travail pour 3 des fonctionnalités sur lesquelles nous avons travaillé en octobre.
• en décembre 2021, nous avons travaillé sur 6 fonctionnalités en parallèle ; heureusement aucune d’entre elles ne venait d’être lancée.
• en janvier 2022, nous avons également travaillé sur 5 fonctionnalités, aucune d’elles n’étant nouvelle.
• en février 2022, nous avons travaillé sur 8 fonctionnalités en parallèle, dont 3 nouvelles.
• en mars 2022, nous avons travaillé sur 8 fonctionnalités en parallèle.
• en avril 2022, nous avons également travaillé sur 8 fonctionnalités en parallèle.

Nous avons travaillé sur plus de fonctionnalités en parallèle que nous n’avions de personnes dans l’équipe pendant cette période (l’équipe de développement de produits était composée de 7 personnes).

Ainsi, bien que l’équipe ait fait un excellent travail pour terminer les éléments de travail individuels, nous avons travaillé sur de nombreuses fonctionnalités en parallèle, ce qui a entraîné un long temps de cycle pour chacune d’entre elles.

Je m’attendais à une faible efficacité du flux pour les fonctionnalités individuelles en raison des nombreux changements de contexte. L’efficacité du flux pour une fonctionnalité est le rapport entre le temps actif total de travail sur une fonctionnalité et le temps de cycle nécessaire pour achever la fonctionnalité.

Par exemple, s’il a fallu 10 jours pour achever une fonctionnalité mais seulement 2 jours de travail actif, l’efficacité du flux est de 20 %. Cela signifie que l’élément de travail a passé 8 jours dans un état inactif quelconque.

L’efficacité du flux est souvent difficile à mesurer, car il faut pouvoir distinguer le temps actif du temps inactif. Si votre flux de travail comporte des états d’attente entre chaque état, par exemple « développement en cours » → « en attente de révision » → « révision », et que les changements d’état sont raisonnablement tenus à jour, vous pouvez calculer l’efficacité du flux. Notre flux de travail ne comporte pas d’états d’attente, mais nous sommes tenus d’effectuer un suivi du temps à des fins comptables. Cela signifie que nous suivons quotidiennement le temps que nous consacrons à chaque fonctionnalité, ce qui nous permet de mesurer l’efficacité du flux de manière assez précise.

Ainsi, sur la base de ces journaux de travail / relevés de temps, nous avons pu calculer l’efficacité du flux pour chaque fonctionnalité et visualiser comment nous avons passé notre temps en tant qu’équipe [2] :

L’image ci-dessus montre un diagramme de Gantt qui est souvent utilisé à tort pour représenter un plan de projet. Utilisé à tort, car les diagrammes de Gantt sont généralement créés avant que le travail ne commence. Cependant, au cours du processus de développement de produits, nous tirons encore de nouveaux enseignements qui influencent le travail à effectuer, de sorte que l’élaboration d’un plan détaillé et l’estimation du temps nécessaire, si elles sont effectuées au préalable, ne sont presque jamais exactes. En outre, le plan du projet suppose généralement une efficacité du flux de 100 %, ce qui n’est presque jamais le cas.

Le diagramme de Gantt que je montre ici représente comment nous avons effectivement passé notre temps en tant qu’équipe, sur la base des journaux de travail. Ce n’est pas du tout ce à quoi ressemble habituellement un plan de projet préalablement défini.

Chaque ligne du diagramme représente une fonctionnalité différente sur laquelle nous avons travaillé. Pour les besoins de cet article de blog, les descriptions des fonctionnalités ont été renommées en valeurs génériques « Fonctionnalité 1 », « Fonctionnalité 2 »… Si un jour est coloré pour une fonctionnalité, cela indique qu’au moins une personne de l’équipe a encodé du temps sur cette fonctionnalité. Cela montre très bien à quel point le temps passé est dispersé, augmentant ainsi le temps de cycle pour chacune des fonctionnalités. Vous pouvez le constater aux nombreuses lacunes et aux nombreux changements de contexte.

L’efficacité du flux pour ces fonctionnalités dans ce laps de temps est triée par ordre croissant : 7%, 9%, 12%, 14%, 16%, 22%, 36%, 53%. Cela s’explique parce qu’en moyenne, les éléments de travail attendent quelque part 4 fois plus qu’ils ne font l’objet d’un travail actif !

De surcroît, le support opérationnel est un flux de travail qui n’apparaît pas dans le diagramme. L’équipe a consacré 25 % de son temps à un travail non planifié pour soutenir l’équipe des opérations ou aider à répondre aux questions des clients ou corriger des bugs.

Comme vous pouvez l’imaginer, l’équipe a été très occupée et, malgré une utilisation très élevée des ressources, nous avons enregistré une faible efficacité du flux. En conséquence, la création d’une valeur pour nos clients a pris plus de temps qu’il ne fallait, engendrant un sentiment très répandu d’être débordé en raison du changement constant de contexte et la sensation d’être occupé en permanence sans avoir le temps de récupérer.

Quelques raisons pour lesquelles nous avons travaillé sur autant de fonctionnalités en même temps :

• Les fonctionnalités ont été imposées à l’équipe au lieu que celle-ci les sollicite lorsqu’elle était prête pour un nouveau travail. Cette façon de procéder s’explique car les dates de sortie avaient été convenues avec les partenaires alors que le travail n’était pas encore clairement défini et sans laisser suffisamment de battement pour le travail non planifié. Lorsqu’il était convenu de fournir une fonctionnalité dans les 6 mois et qu’au bout de 3 mois, un nouveau client voulait signer un contrat mais avait réellement besoin d’une extension de notre plateforme, cette dernière devenait prioritaire au même titre que la fonctionnalité prévue et était imposée à l’équipe. C’est tout à fait compréhensible (nous aimons les nouveaux clients !), mais, pour rendre la situation moins stressante pour notre petite équipe, nous aurions dû laisser un peu de battement dans le planning pour pouvoir faire face aux demandes imprévues à long terme et ne pas remplir le calendrier des mois à l’avance.
• Les fonctionnalités ont été suspendues parce que certains partenaires ont des cycles de sortie assortis de dates prédéfinies. Si une fonctionnalité était pratiquement, mais pas tout à fait prête à être lancée à la date préalablement définie, il fallait attendre la sortie suivante, trois mois plus tard. Autrement dit, même s’il ne restait plus qu’une semaine pour achever la fonctionnalité, celle-ci restait en suspens pendant près de trois mois, jusqu’à ce que le calendrier des lancements du partenaire permette de la reprendre pour effectuer les derniers tests d’intégration et la diffuser. Ces calendriers de lancement fixes nous imposent de retarder inutilement la création de valeur pour nos utilisateurs et augmentent le travail en cours et les besoins secondaires (changement de contexte, les personnes affectées au produit après 3 mois ne sont plus les mêmes ; dès lors, elles manquent de contexte et ont besoin d’être guidées davantage…).

La collecte de métriques et la visualisation du travail nous ont permis d’introduire des changements. Une grande opportunité de créer une valeur plus tôt et avec moins de stress pour l’équipe est apparue clairement.

2. Stabiliser

La première chose que nous avons décidée en tant qu’équipe, c’est que nous devions d’abord terminer les tâches entamées avant d’en commencer une nouvelle, sauf si nous devions respecter une date de sortie préalablement convenue.

Dans les semaines et mois suivants, nous avons effectivement pu finaliser la plupart des travaux « en cours d’exécution » et les mettre à la disposition de nos utilisateurs, ce qui a été très apprécié.

Dans un monde idéal, nous travaillerions avec l’équipe sur un minimum de fonctionnalités ou de thèmes et nous nous concentrerions sur la création de valeur pour nos utilisateurs dès que possible, en garantissant une bonne qualité et en tirant des leçons du feed-back. Une fois que l’équipe serait prête pour un nouveau travail, nous déciderions du thème suivant le plus important ou le plus percutant et nous recommencerions. Décider le plus tard possible de la priorité suivante nous donne un maximum de contexte pour déterminer le thème le plus important au moment où nous sommes prêts à entreprendre un nouveau travail.

Malheureusement, nous ne pouvons pas toujours nous en tenir à cette méthode de travail idéale, car nous travaillons avec des partenaires qui veulent fixer des dates de sortie et des échéances intermédiaires (par exemple, la phase de test d’intégration) longtemps à l’avance, de sorte que nous n’avons pas toujours la liberté de décider le plus tard possible du travail le plus important à entreprendre ensuite. Nous devons nous accommoder de ces contraintes et, dans ce cas, nous essaierons :

• de prendre en considération les temps de cycle antérieurs pour certaines fonctionnalités afin d’essayer de déterminer une date de sortie réaliste ;
• de définir des priorités pour les éléments de travail avec des dates de sortie préalablement définies afin d’avoir de bonnes chances de répondre aux contraintes externes sans trop de stress ;
• de se garder d’imposer de nouveaux éléments de travail à l’équipe. Passer à la demande d’un travail après avoir terminé le travail précédent comme mode opératoire par défaut.

Cela devrait conduire à des résultats positifs tant pour notre équipe (qualité des livrables sans trop de stress) que pour nos partenaires (Olympus Mobility est fiable et respecte les dates de sortie).

3. Étude de cas : Intervention ponctuelle de dépannage du VAB

Peu après les conclusions et les actions décrites dans les deux sections précédentes, à la fin d’avril 2022, une nouvelle date de sortie, déjà convenue à la fin de l’année 2021, s’est profilée à l’horizon. Nous nous sommes engagés à intégrer le produit d’intervention ponctuelle de dépannage par le VAB dans l’application KBC Mobile Banking.

L’intervention ponctuelle de dépannage est un produit qui permet aux conducteurs d’obtenir de l’aide en cas de panne de leur voiture.

Fin avril 2022, la phase d’entonnoir de sélection d’activités (ou phase Fuzzy Front End) pour l’intervention ponctuelle de dépannage était terminée et le développement était censé se terminer pour le 16 juillet 2022. Cela a marqué le début de la phase de test d’intégration de bout en bout. La phase de test d’intégration a été suivie par des tests de pénétration le 15 août, une version pilote le 31 août et enfin une sortie publique le 12 septembre 2022.

Nous avons décidé de laisser une petite équipe pluridisciplinaire se concentrer sur la construction du produit. Nous avons pensé que c’était l’option qui offrait le plus de chances pour que la fourniture de l’intervention ponctuelle de dépannage soit prête pour le 16 juillet.

L’équipe a commencé son premier élément de travail le 12 mai et a également introduit certaines pratiques qui nous ont aidés à respecter les dates de sortie et que je décrirai dans les paragraphes suivants.

Nous nous sommes assurés d’obtenir un feed-back plus rapide en introduisant un développement concomitant. Les développeurs du back-end et du front-end ont commencé à collaborer pour préparer une slice de bout en bout fonctionnelle dès que possible. À cet effet, ils ont commencé par des API qui renvoyaient à un contenu fictif remplacé par l’implémentation réelle à mesure que le développement du back-end progressait.

L’implémentation de la fonctionnalité de bout en bout comprenait également l’intégration avec des parties externes (VAB et KBC) dès que nous en avions la possibilité. Nous n’avons pas attendu la phase de test d’intégration qui était programmée des mois plus tard. Tout cela dans le but de repérer plus rapidement les éventuels problèmes d’intégration, de pouvoir finir les éléments de travail et de ne pas reporter le feed-back.

Dès que certains éléments de travail étaient prêts à une démonstration, nous les avons montrés lors de notre réunion intermédiaire hebdomadaire avec toutes les parties prenantes. Cela a été très apprécié et nous a donné un précieux feed-back que nous avons souvent pu intégrer pour la réunion suivante.

Lors de notre réunion intermédiaire quotidienne avec l’équipe d’Olympus Mobility, nous nous sommes concentrés sur la levée des obstacles afin d’empêcher le travail de traîner en longueur. Nous nous sommes concentrés sur l’achèvement du travail en cours avant d’entamer tout nouvel élément de travail.

La capacité à rester concentrés et l’introduction des pratiques décrites précédemment ont permis de réduire le temps de cycle de 7 jours pour 85 % des éléments de travail et de 10 jours pour 95 % d’entre eux. Par rapport à ce que nous avons montré pour la période du 1er octobre 2021 au 15 avril 2022, le temps de cycle s’est amélioré et nous avons enregistré moins de variations, si bien que nous sommes plus prévisibles. L’efficacité du flux pour l’intervention ponctuelle de dépannage s’est soldée à 60 %.

À la mi-mai 2022, nous sommes également passés de nos sorties bihebdomadaires à une Continuous Delivery (ou livraison continue) (CD) pour nos développements web et back-end. Chaque développeur est devenu responsable de la mise en production de ses modifications. Le temps de cycle pour l’intervention ponctuelle de dépannage ci-dessus comprend la mise en production des modifications pour les éléments de travail. Le passage à la CD nous permet de gagner environ une demi-journée toutes les deux semaines dont nous avions besoin pour mettre en production tous les changements d’un coup. En introduisant la CD, nous créons plus vite une valeur pour les utilisateurs, sans impact négatif sur notre disponibilité.

Nous avons organisé notre équipe pour un flux rapide, mais nous dépendions aussi énormément du soutien des partenaires avec lesquels nous étions associés, VAB et KBC. Ce n’est que grâce à leur rapidité de réaction et à leur feed-back lors de la correction des problèmes d’intégration que nous avons pu respecter ces dates de sortie rigoureuses.

Nous avons respecté les dates de sortie et le produit d’intervention ponctuelle de dépannage est disponible depuis le 12 septembre 2022 dans l’application KBC Mobile Banking. La fourniture de l’intervention ponctuelle de dépannage a été considérée définitivement comme un succès tant pour l’équipe de développement de produits que pour les parties prenantes. Nous tenons compte des enseignements tirés des données JIRA et des changements de processus lors de la planification et de la fourniture des futures initiatives en matière de produits et nous poursuivrons notre examen et nos adaptations pour continuer à améliorer la rapidité et la qualité des services de mobilité que nous fournissons à nos utilisateurs.

Copier ces pratiques pourrait ne pas donner les mêmes résultats dans le contexte de développement de vos produits, mais être quand même pour vous une source d’inspiration sur la façon d’évaluer et, si nécessaire, d’améliorer le flux. Nous vous remercions d’avoir lu cet article.

[1] : Le diagramme de dispersion du temps de cycle a été créé à l’aide du jira-agile-metrics github project. Il fournit des données plus précieuses que les résultats de JIRA sans extensions ni applications supplémentaires. Vous obtenez par exemple des données de percentile sur les temps de cycle, ce qui est important car les données sur les temps de cycle n’ont pas une distribution normale et les moyennes fournies par Jira ne sont donc pas utiles. La production de données est aisée, mais leur nettoyage a pris assez bien de temps. Nous avions par exemple des éléments de travail qui ont été utilisés pour le suivi du temps en dehors du processus de production du logiciel et sont passés de « To do » à « Done » sans parcourir le flux de travail proprement dit. Ces éléments et d’autres tickets ont dû être filtrés pour obtenir des résultats plus précis. Gardez cela à l’esprit lorsque vous essayez de trouver des métriques utiles.

[2] : Les calculs d’efficacité du flux et le diagramme de Gantt sont générés à l’aide du work-exposure github project (projet github en matière d’exposition professionnelle).

Auteur: Kristof Adriaenssens

Un grand merci à Tom Stuart et à Will Ellis pour avoir relu l’article de blog et nous avoir fourni un précieux feed-back.

Si vous avez envie de façonner l’avenir de la mobilité, consultez notre page Emplois.