Optimisation de la livraison logicielle : Surmontez les défis de la phase de déploiement
La rapidité est un élément clé de la réussite. Dans le domaine du développement logiciel, cela se traduit par la nécessité de livrer nos produits plus rapidement que jamais… 🚀🚀🚀
Introduction :
La gestion efficace de la livraison de produits logiciels constitue un défi crucial pour de nombreuses entreprises technologiques.
Le passage aux Component Team et à l’Architecture microservices sont deux approches couramment utilisées pour améliorer la livraison de logiciels dans les entreprises technologiques.
Les Component Teams favorisent la collaboration étroite entre les membres de l’équipe, en encourageant la communication continue, le partage des connaissances et la prise de décisions collective.
Une équipe typique dans une entreprise tech comprend un Product Owner (PO), un Ingénieur en Assurance Qualité (QA) et plusieurs Développeurs (pizza team). Traditionnellement, le PO organise les sprints et le backlog, tandis que les Développeurs se concentrent sur le développement des fonctionnalités. Le QA est chargé de tester toutes les User Stories avant leur déploiement.
Cependant, cette approche peut entraîner plusieurs problématiques. Dans nos équipes, nous avons récemment été confrontés à des difficultés similaires. Nous avons constaté que le QA était submergé de travail lorsqu’il s’agissait de tester le travail de plusieurs Développeurs. Les Développeurs se concentraient principalement sur la phase de développement, laissant la phase de déploiement et de test en suspens. En conséquence, de nombreuses User Stories se sont retrouvées bloquées dans la colonne “review PR” ou “To test”, retardant ainsi leur intégration dans le produit final. La pression exercée par l’équipe business pour livrer les fonctionnalités à temps a exacerbé la situation.
Dans cet article, nous explorerons différentes approches et stratégies pour surmonter les problèmes lors de la phase de déploiement et optimiser le processus de livraison. En adoptant des pratiques axées sur la collaboration et l’autonomie, nous chercherons à renforcer notre capacité à livrer rapidement des fonctionnalités tout en garantissant des standards élevés en matière de qualité logicielle.
Un peu de contexte :
Lorsque nos équipes ont envisagé différentes méthodologies de gestion de projet, nous avons pris la décision de nous orienter vers le Kanban plutôt que le Scrum. Parmi les raisons qui ont motivé ce choix, les changements de priorités et les imprévus ont joué un rôle crucial. Voici quelques-unes des autres raisons qui ont influencé notre décision :
- Flexibilité face aux changements : Nous travaillons dans un environnement où les changements de priorités et les imprévus sont fréquents. Avec le Kanban, nous sommes en mesure de gérer ces situations de manière plus fluide et réactive. Plutôt que d’être liés à des itérations fixes, nous pouvons ajouter, supprimer ou reprioriser des tâches en fonction des besoins changeants du projet.
- Gestion du flux de travail : Le Kanban met l’accent sur la gestion du flux de travail de manière visuelle et transparente. En utilisant un tableau Kanban, nous pouvons facilement suivre l’état de chaque tâche, identifier les goulots d’étranglement et prendre des mesures pour les résoudre rapidement. Cette approche nous permet de maintenir un flux de travail régulier et d’optimiser notre productivité.
L’adoption du Kanban par nos équipes a présenté des défis liés à la façon dont les Développeurs, l’ingénieur QA et le PO collaboraient. Ces problèmes comprenaient des Développeurs qui passaient rapidement aux tickets suivants, mettant l’accent sur le développement au détriment des tests et du déploiement. De plus, la responsabilité des tests reposait entièrement sur le QA, ce qui entraînait des goulots d’étranglement et une boucle de rétroaction prolongée. En outre, l’isolement du PO dans la rédaction des User Stories a entraîné des critères d’acceptance incomplets et des lacunes dans la compréhension mutuelle.
Pour résoudre ces problèmes, il était nécessaire de revoir notre approche et d’apporter des changements au sein de nos équipes, en repensant notre flux de travail et en adoptant des pratiques plus collaboratives.
Identification des « pain points » :
Nous avons pris l’initiative de mener des workshops dédiés. Ces workshops avaient pour objectif d’identifier les points douloureux rencontrés par chaque membre de l’équipe et de trouver des solutions pour les résoudre. Voici comment nous avons procédé :
- Organisation de plusieurs réunions : Nous avons planifié et organisé plusieurs réunions dédiées où tous les membres de l’équipe pouvaient participer. Ces réunions étaient structurées et permettaient à chacun de s’exprimer librement sur les problèmes qu’il rencontrait dans le processus de déploiement. Ces problèmes comprenaient les retards, les lacunes de communication, les processus inefficaces, les problèmes de test, etc. Nous avons documenté ces problèmes sur Miro pour une visualisation claire et une référence ultérieure.
- Utilisation de Miro comme outil de travail : Pour faciliter la collaboration et la visualisation des informations, nous avons utilisé l’outil en ligne Miro. Cela nous a permis de créer des tableaux, des post-its virtuels et de travailler simultanément sur les mêmes documents. Miro a été particulièrement utile pour capturer les idées et les problèmes identifiés lors des sessions de brainstorming.
Lors de nos workshops, nous avons identifié plusieurs points qui affectaient notre processus de delivery. Voici un résumé des problèmes que nous avons identifiés :
- “Non-importance” de déployer rapidement une fonctionnalité : Nous avons constaté que l’équipe ne mettait pas suffisamment l’accent sur l’importance de tirer une fonctionnalité vers la production rapidement. Cela entraînait des retards dans la mise à disposition des nouvelles fonctionnalités aux utilisateurs finaux, ce qui pouvait avoir un impact négatif sur notre réactivité envers les besoins du marché et sur la satisfaction des utilisateurs.
- Concentration excessive des Développeurs sur le développement : Les Développeurs se concentraient principalement sur le fait de passer rapidement au développement du prochain sujet une fois qu’un sujet était terminé. Cette approche “développer plus, c’est mieux” négligeait l’importance d’un déploiement et d’une validation précise et efficace de chaque fonctionnalité développée (en intégrant des tests automatisés aux fonctionnalités développées).
- Goulots d’étranglement dans la phase de test : En raison de la charge de travail disproportionnée entre le QA et les Développeurs et en l’absence des tests automatisés, la phase de test présentait un véritable goulot d’étranglement. Un seul QA était chargé de tester les fonctionnalités développées par plusieurs Développeurs, ce qui entraînait des retards importants dans la validation et la résolution des problèmes de qualité.
4. Boucles de feedback prolongées : En raison des problèmes identifiés lors de la phase de test qui auraient pu être évités si une discussion approfondie des tickets avait eu lieu entre tous les membres de l’équipe. Les boucles de feedback étaient souvent longues, ce qui prolongeait le temps nécessaire pour finaliser une fonctionnalité et la rendre prête pour la production.
En identifiant les problèmes rencontrés par chaque partie prenante, nous avons pu avoir une vue d’ensemble des obstacles qui affectaient notre processus de déploiement. Cela a permis de créer une base solide pour développer des solutions.
Mise en place des améliorations :
1) Sensibilisation à l’importance du déploiement rapide
a) Mettre en avant les avantages du déploiement rapide :
Expliquez à l’équipe les avantages concrets d’un déploiement rapide, tels que la satisfaction des utilisateurs, la possibilité d’itérer rapidement sur les fonctionnalités, la réduction des risques de conflits de fusion de code et la capacité à fournir des correctifs ou des améliorations plus rapidement. Mettez en évidence les bénéfices pour l’entreprise et pour l’équipe elle-même.
b) Impliquer l’équipe dans la planification et la prise de décision :
Impliquez les membres de l’équipe dans la planification du processus de déploiement et dans la prise de décision concernant les priorités. En leur donnant une voix et en les faisant participer activement, ils se sentiront investis et comprendront mieux l’importance du déploiement rapide pour le succès du projet.
c) Promouvoir une culture de qualité et de responsabilité :
Insistez sur l’importance de la qualité du code et des tests dans le processus de déploiement rapide. Encouragez l’équipe à adopter des pratiques de développement telles que la revue de code, les tests automatisés et les tests de non-régression. Faites comprendre à l’équipe que la qualité du code et des tests est essentielle pour garantir un déploiement rapide et sans accroc.
2) Équilibrer le déploiement versus le développement
a) Définir des limites de travail en cours (WIP — Work in Progress) :
Nous avons établi des limites claires sur le nombre de tâches en cours dans chaque colonne de notre board Kanban. Cela permet d’éviter la surcharge de travail et de maintenir un flux de travail régulier. En limitant le nombre de tâches en cours, nous nous assurons que les Développeurs ne se concentrent pas uniquement sur le développement, mais aussi sur les autres étapes du processus, y compris les tests et le déploiement.
b) Priorité accordée au passage des tickets vers la colonne de droite :
Nous avons adopté une approche proactive en accordant la priorité à la progression des tickets vers la colonne de droite de notre board Kanban. Cette colonne représente généralement la phase finale avant le déploiement. En nous assurant que les tickets se déplacent rapidement vers cette colonne, nous favorisons un équilibre entre le développement et le déploiement, en nous assurant que les fonctionnalités développées sont prêtes à être livrées aux utilisateurs finaux.
c) Accélérer les reviews de PR :
- Utiliser des outils de suivi : Utilisez des outils de suivi pour garder une trace des PR en attente de revue. Ces outils permettent de visualiser facilement les PR en cours et d’envoyer des rappels automatiques aux examinateurs (Slack par exemple). Certains outils offrent également des fonctionnalités telles que des tableaux de bord personnalisés ou des notifications pour faciliter le suivi et la gestion des PR (Slack par exemple).
- Encourager la revue continue : Plutôt que d’attendre que le développement soit terminé avant de lancer une revue de PR, encouragez une approche de revue continue. Les Développeurs peuvent partager des PR en cours de développement pour obtenir des retours plus tôt dans le processus. Cela permet d’identifier les problèmes potentiels plus tôt et de réduire le temps nécessaire pour apporter des corrections.
3) Rééquilibrer les charges de travail
a) Automatisation des tests :
Nous avons investi dans des outils et des frameworks d’automatisation des tests pour réduire la charge de travail manuelle du QA (et des dev aussi ;) ). En automatisant les tests fonctionnels, les tests de régression et d’autres aspects du processus de test, nous avons pu libérer du temps pour le QA, lui permettant de se concentrer sur des tâches plus complexes et stratégiques.
b) Montée en compétence des Développeurs sur la partie test :
Nous avons organisé des sessions de formation et des ateliers pour permettre aux Développeurs d’acquérir des compétences en matière de test. Cela inclut l’apprentissage des bonnes pratiques de test, l’utilisation d’outils de test appropriés et la compréhension des principes de la qualité logicielle. En renforçant les compétences des Développeurs dans le domaine du test, nous avons réduit la dépendance excessive envers le QA et favorisé une répartition équilibrée des responsabilités.
4) Réduire la boucle de feedback
a) Réunion des 3 amigos :
Organisez une réunion avant de démarrer chaque workItem, réunissant le PO, le développeur et le QA. Cette réunion permettra de clarifier les attentes, de discuter des détails du workItem et de s’assurer que tous les membres de l’équipe ont une compréhension commune des objectifs et des critères de réussite.
Nous avons récemment intégré l’utilisation de Notion pour décrire de manière approfondie les demandes business. En ajoutant le lien Notion dans chaque WorkItem, nous offrons à l’équipe une vue complète de la fonctionnalité en cours de développement. Cette pratique nous permet d’effectuer des revues préliminaires et d’identifier d’éventuelles contradictions entre les spécifications et le workItem.
b) Définir des critères d’acceptance :
Impliquez le PO, le développeur et le QA dans la définition des critères d’acceptance pour chaque workItem. Ces critères devraient être spécifiques, mesurables et convenus par tous. En définissant les critères ensemble, vous vous assurez que les attentes sont claires et qu’il y a moins de place pour les malentendus ou les interprétations différentes.
c) Lancement des tests d’intégration en « localhost » et/ou sur les environnements de test :
Encouragez les Développeurs à effectuer des tests d’intégration locaux avant de soumettre leur travail sur l’environnement de test. Cela permettra d’identifier rapidement les problèmes potentiels et de réduire le nombre de retours en arrière.
En mettant en œuvre ces mesures, vous favorisez une collaboration plus étroite entre le PO, le développeur et le QA, ce qui permet de réduire la boucle de feedback et d’accélérer le processus de delivery. Les discussions préliminaires et la définition commune des critères d’acceptance aident à éviter les erreurs de communication et les interprétations divergentes, tandis que les tests d’intégration locaux et sur les environnements de test assurent une détection précoce des problèmes. En réduisant les allers-retours, vous gagnez en efficacité et en rapidité, tout en améliorant la qualité globale des livrables.
Suivi d’impact des améliorations :
Une fois les améliorations mises en place, il est effectivement important de suivre leur impact sur le delivery à l’aide de KPI (Key Performance Indicators). Voici quelques exemples de KPI nous avons utilisé pour évaluer l’efficacité des améliorations.
Nous avons centralisé les différentes métriques en utilisant un tableau de bord Power BI. Cela nous permet d’avoir une vue consolidée et facilement accessible de nos indicateurs importants en un seul endroit :
1- Temps de déploiement :
Mesurez le temps nécessaire pour déployer une fonctionnalité depuis son développement jusqu’à sa mise en production. Un temps de déploiement réduit indique une amélioration de l’efficacité du processus de delivery.
2- Taux d’US avec critères d’acceptance remplis :
Suivez le pourcentage d’User Stories (US) qui remplissent les critères d’acceptance définis en amont. Un taux élevé indique une meilleure collaboration entre le PO, le développeur et le QA, ainsi qu’une compréhension plus claire des exigences.
3- Nombre de bugs en production :
Suivez le nombre de bugs signalés après la mise en production d’une fonctionnalité. Une réduction de ce nombre indique une amélioration de la qualité du logiciel et de la fiabilité des déploiements.
Conclusion :
Après 6 mois d’amélioration et de suivi des KPI, nous sommes ravis de constater les résultats positifs des efforts d’amélioration continue :
- Tout d’abord, nous avons réussi à réduire le temps de déploiement de façon significative, avec une baisse de 50% dans certaines équipes. Cela signifie que nous sommes capables de mettre nos fonctionnalités en production plus rapidement, ce qui améliore notre réactivité et notre capacité à livrer de la valeur aux utilisateurs.
- Ensuite, le taux d’US avec critères d’acceptance remplis a considérablement augmenté, atteignant désormais un impressionnant taux de 80%. Cela démontre que nous accordons une plus grande attention à la qualité et à l’adéquation de nos fonctionnalités par rapport aux attentes des utilisateurs.
- Enfin, nous avons réussi à maintenir et à maîtriser le nombre de bugs créés en production. Cela témoigne de notre engagement envers la qualité et de l’efficacité de nos processus de développement et de test.
Félicitations à l’ensemble des équipes pour ces réalisations remarquables. Nous tenons à saluer l’énorme travail accompli et la collaboration exceptionnelle entre les Product Owners, les Développeurs et les Quality Assurance Engineers pour identifier les problèmes, proposer des améliorations et les mettre en place. Votre dévouement, votre engagement et votre esprit d’équipe ont été essentiels pour obtenir ces résultats positifs. Continuons à travailler ensemble avec cette même énergie et cette même passion pour maintenir cette dynamique et continuer à améliorer notre delivery.
Bravo à tous !
Sources :
https://medium.com/@Remi91394/component-team-vs-feature-team-que-choisir-93638f420de5
https://www.codexa.fr/conduite-de-reunion/pizza-team-le-nouveau-concept-de-reunions/
