Le monde de la technologie évolue rapidement, plus vite que jamais. Il y a quelques années, nous pensions que seuls les Amazones ou les Facebooks de ce monde seraient capables de faire de la livraison continue. Aujourd'hui, le phénomène prend de l'ampleur, commence à devenir courant et, avant que nous le sachions, il sera banalisé. Tout le monde le fera.
Pourquoi ? Parce que la capacité de libérer souvent donne aux organisations un grand avantage concurrentiel sur leurs concurrents dont les délais d'exécution sont plus lents. Afin de pratiquer la livraison continue, les équipes doivent intégrer la qualité dans tout ce qu'elles font. Cela signifie que le produit réel n'atteint pas seulement les clients plus rapidement - c'est aussi un meilleur produit. Apprendre à intégrer la qualité avec Kanban a aidé mon équipe de développement à réduire le gaspillage, à livrer plus rapidement et à mieux communiquer avec l'organisation qui nous entoure.
Keep reading to learn how my development team changed our infrastructure, development practices, and culture to enable continuous delivery.
Le lien entre la qualité et la livraison continue
J'ai eu la chance de faire partie d'une équipe travaillant à l'amélioration de la capacité de notre organisation à livrer rapidement, et j'ai donc connu les remous qui accompagnent le passage d'une version par mois à plusieurs versions par jour.
L'application des approches de test traditionnelles pourrait faire paraître le défi impossible, et en fait, sans changer complètement la façon dont nous construisons et testons les logiciels, nous ne pouvons pas espérer atteindre la livraison continue durable.
Notre adoption de Kanban et de la méthode Kanban était fondamentale pour la direction que nous prenions. En adoptant cette méthode, nous avons pu identifier nos goulots d'étranglement, rendre le temps d'attente visible et maximiser les avantages des petits lots et du flux continu.
Nous avons vite compris que si nous voulions avoir une chance de pouvoir sortir en continu, nous devions réduire les reprises. Dans l'ancien monde, les testeurs et les utilisateurs professionnels prenaient deux semaines de l'itération pour leurs activités de contrôle de la qualité. Une grande partie du temps n'était pas consacrée aux tests, mais à l'identification et à la consignation d'un grand nombre de défauts et à la gestion d'environnements instables.
Nous avons attaqué ce problème sur trois fronts : L'infrastructure, les pratiques de développement et la culture.
Infrastructure : Réduire les erreurs humaines
Pour réduire le remaniement de notre infrastructure, nous avons développé un tout nouveau pipeline de livraison qui transportait à la fois le code et le contexte. Nous avons également créé des environnements de test à la demande, afin de réduire le temps perdu à les mettre en place manuellement et à retravailler les configurations incorrectes.
Cela signifiait une réduction drastique des étapes manuelles dans la construction et le déploiement. Bien qu'au départ, cette mesure n'ait été mise en œuvre que sur nos environnements de test, elle nous a procuré des avantages immédiats. La possibilité de tester sur des environnements fiables, créés à l'aide d'un processus reproductible, a réduit considérablement notre temps de test.
Pratiques de développement : Meilleure communication, User Stories plus petites
Développement guidé par le comportement (BDD)
Nous avons adopté le développement guidé par le comportement (BDD) afin de réduire les malentendus entre les parties prenantes de l'entreprise et l'équipe de développement et, par conséquent, de réduire les remaniements causés par les mauvaises communications.
BDD a donné d'excellents résultats très tôt. Nous nous sommes vite rendu compte de la part que nous avions laissée à l'interprétation individuelle - et de la mesure dans laquelle cela avait causé la plupart des défauts que nous avons constatés dans les activités de contrôle de la qualité. Grâce à BDD, les taux de défectuosité ont diminué de façon spectaculaire. Plus nous avons amélioré la collaboration au sein des équipes, plus les connaissances commerciales ont augmenté au sein de ses membres. Cela a permis de faciliter la prise de décision ; les décisions qui avaient auparavant nécessité de longues réunions frustrantes sont devenues des conversations rapides.
Histoires d'utilisateur plus petites
Une autre approche que nous avons trouvée extrêmement bénéfique pour réduire le remaniement était le découpage vertical de nos user stories, réduisant ainsi leur complexité. Cela signifie souvent que la logique du nouveau code comprend un seul chemin de code. Une complexité moindre signifiait moins de défauts et moins de reprises.
Stratégie équilibrée d'automatisation des tests
Dans le même temps, nous avons défini une stratégie impliquant une forte utilisation des tests d'automatisation au niveau unitaire, une couche cohérente de tests automatisés au niveau de l'API et une couche très fine de tests pilotés par l'interface utilisateur, conformément à la pyramide de tests automatisés de Mike Cohn . Cela a permis à notre suite de régression de rester rapide et stable, ce qui est absolument fondamental si vous voulez être en mesure de fournir une valeur client chaque fois que votre équipe de développement pousse un nouveau code.
L'utilisation de BDD et la mise en œuvre de l'automatisation des tests n'ont pas signifié que nous avons cessé d'effectuer des tests exploratoires, mais que l'activité est devenue de moins en moins chronophage en raison de la réduction des défauts et de la taille réduite des histoires.
Construire la qualité dans
J'ai travaillé, pendant quelques mois, sur un produit qui impliquait la transformation d'un flux de données en une structure de données différente pour être consommée par un client, je me souviens que je n'ai jamais fait de tests exploratoires pendant plus de 10 minutes, et je n'ai jamais eu l'impression de laisser quelque chose derrière moi. C'était libérateur pour moi, de sentir que je pouvais produire un travail de qualité à un rythme rapide sans rien sacrifier.
Nos clients n'ont pas non plus rencontré de problèmes. Nous inspections l'application un ordre de grandeur de moins qu'auparavant, mais la qualité de nos résultats était supérieure. Nous construisions de la qualité.
La culture : Encourager la collaboration
Ce type de transformation n'est pas trop difficile d'un point de vue technique. C'est beaucoup plus compliqué d'un point de vue culturel. Lorsque j'ai rejoint la société à laquelle je fais référence, j'ai trouvé des développeurs extrêmement compétents qui n'étaient pas habitués aux tests. Ils avaient été gâtés par les testeurs qui couraient après leur code désordonné et n'ont jamais développé d'intérêt pour la discipline.
La culture est difficile à changer. Notre stratégie consistait à encourager les comportements sains plutôt que de punir les mauvais. Par exemple, nous avons encouragé et félicité les développeurs qui étaient prêts à tester, et nous avons également félicité les personnes qui travaillaient en binôme. Nous avons encouragé et reconnu toutes les formes de collaboration. Nous savions que l'équipe devait devenir une unité de personnes qui se faisaient confiance et pas seulement un groupe de personnes possédant toutes les compétences nécessaires pour fournir une solution complexe.
Le partage des connaissances et la création d'une tribu de test
Nous devions atteindre une cohésion de travail qui apporte la capacité de collaborer et élimine les goulots d'étranglement tout en maintenant le flux de travail. L'une des clés du succès a été l'accent que nous avons mis sur le développement de compétences en forme de t, en apprenant les uns des autres et en offrant de l'aide à tout moment.
Une initiative réussie a été la création de la Tribu de test. La Tribu était un groupe volontaire et entièrement autonome de personnes qui se souciaient de la qualité des logiciels. Au bout d'un certain temps, ce groupe de personnes, qui se réunissait chaque semaine pour avoir des conversations de type Lean Coffee, est devenu important, la majorité de ses membres étant des développeurs. Je n'ai pas assez d'espace pour mentionner un certain nombre d'expériences et d'améliorations qui ont débuté à ce niveau.
Un succès notable a été la conception d'un outil qui a considérablement amélioré la testabilité de notre application principale, ce qui a réduit le temps d'exploration de plusieurs heures à quelques minutes. La tribu a également contribué à modifier notre processus, en supprimant les étapes inutiles et, dans un cas précis, en identifiant un changement qui a permis de réduire le délai d'exécution de 30% avec peu d'efforts.
La tribu était florissante et ses succès se sont rapidement répercutés dans les différentes équipes où se trouvaient des membres de la tribu. Les équipes ont commencé à expérimenter de plus en plus et à améliorer leurs systèmes en allant au-delà des seules améliorations de qualité, c'était formidable à observer.
Qualité de construction dans : Réflexions finales
Toute organisation peut pratiquer la livraison continue - et elle le devrait, si elle espère être compétitive sur le marché moderne. La livraison continue aide les organisations à livrer non seulement plus rapidement que leurs concurrents, mais aussi avec une meilleure qualité.
J'ai vu cela fonctionner au sein de ma propre équipe de développement, par le biais d'une série de changements incrémentiels qui ont entraîné un changement majeur dans notre mode de fonctionnement - nous aidant à passer d'une version par mois à plusieurs versions par jour :
Infrastructure : Nous avons modifié notre infrastructure pour réduire le nombre d'étapes manuelles dans la construction et le déploiement. Cela nous a permis de disposer d'environnements de test plus fiables avec des temps de test nettement plus courts, ce qui signifie que nous avons pu livrer plus rapidement avec moins de bogues.
Pratiques de développement : Nous avons modifié nos pratiques de développement afin d'améliorer la communication en amont et en aval de l'organisation. Cela nous a permis de réduire les reprises de travail dues à des erreurs de communication. Nous avons également rendu les histoires d'utilisateurs plus petites et plus simples, ce qui a permis de réduire la complexité et donc de faciliter les livraisons fréquentes. Nous avons mis en place une stratégie d'automatisation des tests équilibrée, qui a permis à notre suite de régression de rester rapide et stable.
La culture : Enfin, nous avons changé notre culture, de la même manière que nous avons changé tout le reste - rapidement, mais de manière progressive, afin que les changements soient durables. Nous avons encouragé les comportements sains, ceux qui favorisent les essais et la collaboration entre les équipes. Nous avons créé une Test Tribe, un groupe de passionnés de tests, dont l'influence s'est répandue dans toute l'organisation et a contribué à solidifier notre nouvelle culture : une culture axée sur la collaboration, la communication et la qualité.
Tous ces efforts ont abouti à un système conçu pour livrer rapidement, avec une qualité intégrée à chaque étape du processus.
![Un plan de gestion du travail collaboratif mondial [Vidéo] (en anglais)](https://blog.planview.com/wp-content/uploads/2019/07/A-Global-Collaborative-Work-management-blueprint.png)
