Gel du Code : Sont-Ils toujours pertinents pour les Chefs de Produits Agiles ?

Cela ressemble à un cas ouvert et fermé.

Les gels de code sont une relique. Un vestige de l’époque où les méthodologies rigides en cascade offraient la seule option pour le développement et la sortie de produits. L’ensemble du concept consistant à arrêter la production et à retarder la sortie — uniquement pour tester les bogues et autres problèmes fonctionnels — n’a pas sa place dans la gestion de produits moderne et agile.

Du moins, cela semble être le point de vue consensuel de nombreux gourous Agiles.

Mais tient-il le coup? Une fois que vous aurez gratté la surface des arguments les plus courants contre l’intégration de gels de code dans la gestion agile des produits, sembleront-ils encore archaïques?

Dans cet article, nous explorerons les trois principaux arguments contre l’incorporation de gels de code dans votre gestion de produit Agile, et nous décomposerons là où ces arguments s’effondrent, le tout pour vous aider à prendre une meilleure décision quant à savoir si vous devez ou non incorporer des gels de code dans votre gestion de produit Agile.

Argument 1: Les gels de code ne sont pas pertinents et inutiles

Cet argument est assez simple et concret — les méthodologies et outils Agiles modernes ont éliminé la nécessité d’une fenêtre d’assurance qualité et de test dédiée.

Les méthodologies agiles telles que les revues de code par les pairs, la programmation par paires et la surveillance constante de l’état du système vous donnent une visibilité beaucoup plus grande sur les performances d’une application ou d’une fonctionnalité pendant son développement. Les bogues et les problèmes sont plus faciles et plus susceptibles d’être détectés pendant le développement lui-même, et résolus avant toute activité de test et d’assurance qualité dédiée.

De nouveaux outils ont également automatisé de nombreux tests. Ils évaluent constamment le code pour s’assurer qu’il est propre et prêt à être produit à tout moment. Les problèmes sont identifiés en temps réel et des alertes sont immédiatement envoyées pour les résoudre dès que possible. Le nombre de tests automatisés est déjà vaste et continue de croître, réduisant considérablement le volume de tests manuels à effectuer.

Le résultat de ces nouvelles méthodologies et outils Agiles est facile à voir. La plupart des activités de test et d’assurance qualité de base effectuées lors d’un gel de code sont soit effectuées pendant le développement, soit effectuées par un logiciel. En Agile, les logiciels et les fonctionnalités quittent désormais le développement à un niveau de confiance beaucoup plus élevé qu’auparavant, rendant un gel de code dédié de plus en plus difficile à justifier.

Argument 2: Les gels de code Brisent un principe Agile de base

Ce deuxième argument est un peu plus élevé. Fondamentalement, il soutient que les gels de code n’ont pas leur place dans la méthodologie Agile car ils enfreignent l’un des principes fondamentaux de la méthodologie Agile: réduire le temps entre le développement et la publication.

Plus votre approche de l’Agilité est raffinée, plus vous tenterez de réduire cette fenêtre de temps. Les approches actuelles les plus raffinées d’Agile sont l’Intégration continue et le Développement continu (CICD), et elles visent à diviser le développement en petits changements incrémentiels afin de « libérer » les modifications du code le plus rapidement possible. Dans l’application la plus pure de CICD, le développement et la publication existent à peine en tant que phases distinctes — le nouveau code est intégré dans l’application presque dès qu’il est terminé.

En revanche, vous devez maintenir des phases de développement et de publication distinctes si vous souhaitez déployer des gels de code. Après tout, c’est là que réside le gel du code — entre ces deux phases distinctes. Au lieu d’essayer de minimiser ou d’éliminer cette fenêtre de temps entre le développement et la publication comme la plupart des méthodes Agiles, les blocages de code vous obligent à formaliser cette fenêtre au point que vous devez construire vos plannings de développement et de publication autour d’elle.

Si les gels de code ne correspondent pas aux principes Agiles de base, il est difficile de faire valoir qu’ils appartiennent toujours à la méthodologie.

Argument 3: Les gels de code Entraînent des Versions Plus lentes et de qualité inférieure

Cet argument final est important et comprend quelques angles différents.

Pour commencer, il soutient que les gels de code ajoutent beaucoup de complexité et de pièces mobiles supplémentaires à votre feuille de route, et augmentent naturellement les chances que quelque chose ne tourne pas rond et rejettent votre chronologie. Même si rien ne va mal, le travail impliqué dans les gels de code est long et imprévisible (car vous ne savez pas quels bugs vous trouverez ou combien de temps il faudra pour les corriger), qu’en ajoutant simplement des gels de code à votre feuille de route, vous créerez des cycles de développement et de publication plus lents.

Ensuite, il soutient que le gel du code réduira la productivité de votre équipe de développement. Alors que l’agilité en général, et le CICD en particulier, permettent à vos développeurs de travailler constamment dans une chaîne de productivité ininterrompue, les blocages de code obligent vos développeurs à arrêter le travail à des intervalles prédéfinis. En faisant cela, vous briserez leur rythme et les forcerez à essayer de contourner vos stratégies de gel de code, au lieu de trouver et de maintenir le flux qui les rend les plus productifs.

Enfin, il soutient que la création de fenêtres dédiées où vous cesserez de recevoir des exigences métier limitera les fonctionnalités et fonctionnalités de vos versions à tout ce qui peut être complété avant le gel, ce qui conduira à des logiciels et des applications moins complets et de qualité inférieure.

Plaider pour le gel du code : Une bataille perdue ?

À ce stade, cela semble assez sombre pour quiconque souhaite toujours inclure des gels de code dans la méthodologie Agile. Les détracteurs de cette pratique avancent des arguments très convaincants et un argument global solide selon lequel, depuis le développement de la méthodologie Agile moderne, les gels de code sont devenus:

1. Obsolète et non pertinent
2. Mal aligné avec les pratiques de développement modernes
3. Un obstacle aux versions rapides et de haute qualité

Mais bien que ces arguments soient convaincants et contiennent beaucoup d’informations précises, ils ne sont pas à l’épreuve des balles. Et il y a des défauts fondamentaux dans chacun qui doivent être discutés avant de fermer le livre sur les gels de code en tant qu’élément utile de la gestion agile des produits.

Le Problème Avec l’Argument 1: Les Tests Automatisés Ne Sont Pas complets

Les pratiques d’assurance qualité automatisée et de développement Agile ont augmenté la qualité du code au fur et à mesure de sa production, c’est un fait. Mais ce n’est pas parce qu’un morceau de code a passé les tests unitaires qu’il est réellement prêt pour la production. Même les approches CICD les plus raffinées n’incluent pas toujours des étapes critiques — comme les tests de régression — qui garantissent qu’un morceau de code est exempt de défauts. Quand il s’agit de cela, il y a juste des choses que vous ne pouvez pas tester et résoudre pendant qu’un morceau de code est en production.

Si vous choisissez d’utiliser des gels de code, vous n’abandonnerez pas les avantages de l’assurance qualité automatisée et des meilleures pratiques Agiles. Vous et votre équipe détecterez simplement les problèmes plus petits et plus triviaux de votre code pendant la production, en effaçant les platines pour vous concentrer sur la capture de problèmes plus importants et plus impactants pendant votre gel, tels que la stabilité et la fiabilité globales de votre nouveau logiciel ou fonctionnalité.

Le Problème Avec l’argument 2: « Réduire », Pas « Éliminer »

Agile est conçu pour réduire le temps entre le développement et la sortie, c’est aussi un fait. Mais il y a une grande différence entre essayer de réduire cette fenêtre et essayer de l’éliminer complètement. Cela serait presque impossible, en particulier pour les projets de plus grande envergure.

Le gel du code peut être très court dans CICD — ou ne peut s’appliquer qu’à une branche spécifique pendant que le développement se poursuit sur d’autres branches — mais il existe toujours. Peu importe à quel point Agile est devenu raffiné, il y aura presque toujours un point dans toutes les feuilles de route de développement et de publication où un nouveau logiciel ou une nouvelle fonctionnalité sera évalué dans un état fixe avant qu’il ne soit diffusé aux utilisateurs du monde réel.

Le Problème Avec L’Argument 3: Repenser la vitesse et la qualité

Si vous utilisez des gels de code, vous ajouterez une nouvelle étape à votre cycle de développement et de publication. Cela ne fait aucun doute. Et chaque fois que vous ajoutez une nouvelle étape à un processus, vous ralentissez ce processus et vous créez un nouveau point d’échec potentiel. Les gels de code ne font pas exception.

Mais il est important de prendre du recul et d’avoir une vision plus large du ralentissement et de la perte de productivité.

Si votre fonctionnalité contient des bogues, vous devrez les corriger, que vous ayez détecté ces bogues lors d’un gel du code ou qu’ils se soient fait connaître après la sortie. Du point de vue du développement pur, le temps nécessaire pour les corriger sera à peu près le même dans les deux scénarios.

Mais si vous avez affaire à des bogues dans un environnement en direct, vous avez une foule d’autres problèmes que vous devez prendre le temps de traiter, notamment:

• Décider de restaurer la fonction buggy ou de la laisser en direct.
• Enlevez vos développeurs de leurs nouveaux projets, une fois qu’ils ont commencé à travailler.
• Pour vos utilisateurs du monde réel qui ont été touchés par les bogues.
• Répondre et gérer vos parties prenantes internes qui ne sont pas trop satisfaites de votre publication problématique.

La liste est longue. Il n’y a rien de plus compliqué, de plus long et de plus destructeur pour la productivité – pour vous et votre équipe — que de publier une fonctionnalité ou un produit défectueux. Les gels de code minimisent les chances que cela se produise.

Et quant à l’argument selon lequel le gel du code entraîne des fonctionnalités et des produits de qualité inférieure, car ils réduisent le nombre d’exigences commerciales que vous pouvez collecter? Les exigences de votre entreprise seront toujours un peu plus qu’une « meilleure supposition » quant à ce que votre produit ou fonctionnalité devrait fonctionner. Les exigences les plus précieuses proviendront toujours des utilisateurs du monde réel, déployant votre produit ou fonctionnalité dans des scénarios réels. Et vous ne pouvez collecter ces exigences qu’en fournissant à vos utilisateurs des versions fonctionnelles qu’ils peuvent déployer aussi facilement et sans bogues que possible.

Devriez-Vous Utiliser des Gels de Code dans Votre Gestion de Produit Agile?

En fin de compte, les gels de code jouent toujours un rôle important pour de nombreux chefs de produits Agiles.

Maintenant, il y a des cas où ils jouent un rôle moins critique. Les très petits projets peuvent ne pas avoir besoin de périodes de gel de code dédiées. Les nouvelles fonctionnalités qui ont des conséquences relativement mineures si elles sont expédiées de manière imparfaite pourraient ne pas valoir le gel. Il en va de même pour les plans de versions échelonnées — comme les versions Canari — lorsque vous souhaitez simplement tester de nouvelles fonctionnalités auprès d’un public chaleureux et que vous êtes prêt à vous attendre à une expérience boguée et imparfaite.

Mais dans la plupart des cas, il vaut la peine de prendre le temps — même très court — de s’assurer que vos nouvelles fonctionnalités sont aussi parfaites que vous le pensez avant de les mettre entre les mains des personnes qui comptent le plus : vos utilisateurs du monde réel.

Cet article a été initialement publié le flagship.io