5 erreurs agiles que j’ai faites et comment les résoudre

Agile avait l’habitude d’être stigmatisé comme étant “uniquement adapté aux petites équipes et à la gestion de petits projets”. C’est maintenant une discipline célèbre utilisée par les équipes de développement de logiciels du monde entier avec un grand succès. Mais Agile apporte-t-il vraiment de la valeur ? Eh bien, cela dépend de la façon dont vous l’utilisez.

Mes équipes et moi utilisons Agile depuis mes débuts dans la tech. Cela n’a pas toujours été facile et il y a eu beaucoup d’apprentissages en cours de route. La meilleure façon d’apprendre est de faire des erreurs, alors pour vous aider dans votre propre parcours agile, voici cinq erreurs agiles que j’ai commises.

1. Erreur: Agile ne se produit que dans les équipes de développement

Voici ce qui se passe lorsque vous limitez Agile à votre équipe de développement uniquement. Votre équipe commerciale rédige les exigences d’un projet, et celles-ci sont transmises à l’équipe de développement, avec un délai. Dans ce cas, l’équipe de développement n’est pas directement responsable des objectifs commerciaux.

Il y a très peu de communication entre les équipes, encore moins de négociation. Personne ne remet en question les demandes formulées par l’équipe commerciale ou s’il existe une meilleure façon d’atteindre le même objectif commercial.

Cela peut également être décourageant pour les équipes de développement. Lorsque les développeurs sont uniquement chargés de remplir le code pour faire fonctionner la machine, ils sont déconnectés du business.

Le produit final devient un monstre, dépourvu d’abstraction et de conception raisonnables.

Solution: Diffusez Agile dans votre organisation. Laissez tout le monde en profiter de la manière qui convient à son service, mais surtout, laissez-le unifier les objectifs de chacun.

2. Erreur: Les tests automatisés demandent trop de travail à configurer

Le rôle des tests automatisés, en particulier du développement piloté par les tests (TDD), est souvent sous-estimé par l’industrie informatique. À mon avis, les tests automatisés sont la pierre angulaire d’un logiciel maintenable et de haute qualité, et sont encore plus importants que le code de production.

Cependant, la plupart des équipes aujourd’hui n’ont pas la capacité d’automatiser les tests, ou en ont la possibilité mais la refusent en raison de contraintes de temps. Les programmeurs n’ont pas la capacité de refactoriser en continu le mauvais code sans la protection des tests automatisés.

En effet, personne ne peut prédire si la modification de quelques lignes de code entraînera de nouveaux bogues. Sans refactoring continu, vous augmentez votre dette technique, ce qui réduit votre réactivité aux demandes de vos business units.

Les tests manuels sont lents et vous obligent à sacrifier la qualité, en testant uniquement la partie modifiée (ce qui peut être difficile) ou en allongeant la durée des tests de régression. Si le temps de test est trop long, vous devez tester par lots pour réduire le nombre de tests effectués.

Soudain, vous n’êtes plus agile. Vous êtes converti en Cascade.

Solution: La clé des tests automatisés est que les développeurs exécutent des tests, au lieu d’embaucher plus de testeurs pour écrire des scripts. C’est pourquoi les tests (écrits par des testeurs) s’exécutent lentement et ne produisent que lentement des commentaires aux programmeurs.

Ce qu’il faut pour améliorer la qualité du code, c’est un retour rapide sur le programme. Plus un test automatisé est écrit tôt et plus il est exécuté rapidement, plus il est propice pour les programmeurs d’obtenir des commentaires en temps opportun.

Le moyen le plus rapide d’écrire des tests automatisés est TDD. Écrivez des tests avant d’écrire le code de production. Le moyen le plus rapide d’exécuter des tests automatisés est le test unitaire.

3. Erreur: Tant que cela fonctionne, vous pouvez ignorer la qualité du code

Les gens disent souvent : « Nous manquons de temps, finissons-en.

Ils ne se soucient pas de la qualité. Beaucoup de gens pensent que la qualité peut être sacrifiée au profit de l’efficacité. Vous finissez donc par écrire du code de mauvaise qualité parce que vous n’avez pas le temps pour autre chose. De plus, un code de mauvaise qualité ne se traduit pas par des performances élevées.

À moins que votre programme ne soit aussi simple que quelques lignes de code, un code de mauvaise qualité vous freinera à mesure que la complexité du code augmentera. Le logiciel est appelé “soft” car nous nous attendons à ce qu’il soit facile à modifier. Le code de mauvaise qualité devient de plus en plus difficile à modifier car un petit changement peut entraîner des milliers de nouveaux bogues.

Solution: La seule façon d’améliorer la qualité du code est d’améliorer vos compétences. La plupart des gens ne peuvent pas écrire de code de haute qualité en une seule séance. C’est pourquoi vous avez besoin d’un refactoring constant ! (Et vous devez implémenter des tests automatisés pour prendre en charge une refactorisation constante).

4. Erreur: Les employés doivent se spécialiser dans une seule chose

Il semble naturel de diviser le personnel en équipes spécialisées. Un employé peut appartenir au groupe Android, un autre au groupe iOS, un autre au groupe d’arrière-plan, etc. Le danger est que les équipes avec des changements fréquents signifient que la spécialisation est difficile à maintenir.

Solution: De nombreuses pratiques agiles sont basées sur des équipes telles que la vitesse d’équipe, l’amélioration rétrospective et le roulement du personnel. Les pratiques agiles tournent autour des équipes et des personnes. Aidez les membres de votre équipe à se diversifier, à acquérir de nouvelles compétences et à partager leurs connaissances.

5. Erreur: Les exigences de rédaction prennent trop de temps

Comme le dit le dicton “Garbage in Garbage out”, et une exigence logicielle formelle est “l’entrée” du développement logiciel. Un bon logiciel ne peut être produit sans des exigences claires.

Dans l’industrie technologique, j’ai constaté que les bons propriétaires de produits sont plus rares que les bons programmeurs. Après tout, peu importe à quel point un programmeur écrit du code, il fonctionne généralement au moins (ou bien il n’est pas livré).

Pour la plupart des chefs de produit, il n’existe pas de norme pour mesurer l’efficacité des définitions et des exigences de leurs produits. Voici quelques-uns des problèmes que j’ai constatés au fil des ans :

• Certains propriétaires de produits se consacrent à la conception de solutions tout en ignorant la valeur utilisateur.

Cela se traduit par un tas de fonctions coûteuses, mais inutiles.

• Certains chefs de produit ne peuvent raconter que de grandes histoires et ne peuvent pas diviser les exigences en petits éléments gérables, ce qui entraîne des lots de livraison importants et une agilité réduite.

• Certains propriétaires de produits ont une analyse incomplète des exigences, ce qui entraîne bogue après bogue.

• Parfois, les propriétaires de produits ne hiérarchisent pas les exigences, ce qui conduit les équipes à perdre beaucoup de temps sur des éléments de faible valeur.

Solution: Créez des exigences claires, concises et gérables pour guider le développement.

Faire des erreurs

Je vous ai donné cinq conseils sur certaines erreurs à éviter. Mais ne vous inquiétez pas, il y a encore beaucoup d’erreurs à faire ! Adoptez l’agilité dans votre organisation, n’ayez pas peur d’endurer quelques erreurs au profit de l’amélioration de vos équipes.

Une fois que vous aurez franchi les inévitables faux pas, vous saurez quoi faire différemment la prochaine fois. L’agilité est conçue pour survivre aux erreurs. C’est une de ses forces : il sait s’adapter. Alors lancez-vous avec Agile, soyez prêt à vous adapter et à créer de meilleurs logiciels !