5 pièges courants qui réduisent l’efficacité de votre ingénierie logicielle

Il y a quelques années, la croissance consistait à embaucher davantage de personnes. Aujourd’hui, la croissance est une question d’efficacité : faire plus avec moins. En tant que responsable de l’ingénierie, vous devez aligner vos équipes sur les objectifs de l’entreprise tout en améliorant l’efficacité. Toutes les organisations n’ont pas le luxe d’embaucher davantage de personnel, alors que faire ? On identifie toutes les sources d’inefficacité et l’on s’efforce de les éliminer.

Après avoir travaillé avec plusieurs organisations au fil des ans, nous avons remarqué cinq pièges communs qui ralentissent les équipes. Plus important encore, nous avons préparé une liste de recommandations pour les éviter.

1. Les demandes de revues de code sont bloquées ou prennent trop de temps

Plusieurs ingénieurs pensent qu’être occupé est synonyme de productivité. Au lieu d’attendre, vous envoyez vos demandes à votre collègue pour les examiner et vous commencez un nouvel élément de travail. Votre collègue examine la demande une fois sa tâche terminée, de sorte que la demande est inactive, ce qui retarde l’obtention de la valeur. Quels sont les résultats ? Les demandes s’accumulent, le temps de révision augmente et la valeur prend plus de temps à être saisie.

Comment repérer la tendance ?

Vous pouvez mesurer le cycle de vie du temps nécessaire pour passer d’une validation à son déploiement. Cette mesure s’appelle le délai nécessaire aux changements et constitue l’une des quatre mesures clés de DORA pour DevOps. Vous pouvez diviser le cycle de vie en étapes et repérer les tendances. Par exemple, voici une image où vous pouvez voir le temps de codage (d’un commit à l’ouverture de sa pull request), le temps de prise en charge (de l’ouverture d’une PR à sa première interaction), le temps de révision (de la première interaction jusqu’à la fusion) et enfin le temps de déploiement (de la fusion jusqu’au déploiement en production). 

En divisant le cycle de vie en phases, il est plus facile de trouver le goulot d’étranglement. Un comportement typique que nous observons est l’augmentation du temps de révision. C’est le signe que les ingénieurs ouvrent davantage de demandes de revue de code sans les classer par ordre de priorité ou que les PR sont trop volumineuses, de sorte que les ingénieurs évitent de les passer en revue.

Solution

Dans cette situation, il y a quelques options à considérer :

• Donnez la priorité à la révision des demandes de revues de code. Après votre daily, tout le monde devrait d’abord fusionner les pull requests avant de s’attaquer à un nouvel élément de travail.
• Réduisez le travail en cours (WIP) au sein de l’équipe. Les équipes subissent des retards parce qu’elles attendent ou dépendent de quelqu’un. Il n’est pas nécessaire d’attendre les autres si l’on travaille ensemble. La réduction du travail en cours tend à améliorer le temps de cycle.
• Encouragez les petites demandes. Lorsqu’une demande est trop importante, les ingénieurs ont besoin de plus de temps pour l’examiner et ont tendance à l’éviter. Privilégiez plutôt une seule modification par demande de revue de code.

2. Les éléments de travail sont trop gros

Apporter une modification à un produit prend du temps. Plus c’est long, plus le coût de ce changement est élevé. Plus le coût est élevé, moins on veut d’échecs, et l’on passe alors plus de temps à planifier pour éviter les échecs. En réalité, chaque fonctionnalité et chaque récit utilisateur est considéré comme un pari ; personne ne peut savoir à l’avance si cela fonctionnera comme prévu, même si vous en êtes convaincu. La planification d’éléments plus importants a pour effet d’ajouter d’autres exigences au fur et à mesure.

Comment repérer la tendance ?

La mesure du temps de cycle sur une période donnée est généralement un excellent moyen d’observer cette tendance. Une durée de cycle plus longue indique qu’un élément prend plus de temps à réaliser en raison de sa taille. Regardez si l’équipe est stable ou si elle présente des variations dans la durée du cycle de ses livrables (par exemple, des fonctionnalités), de ses items (par exemple, des récits utilisateur) ou de ses demandes de revue de code. En règle générale, il convient d’examiner une période suffisamment longue (par exemple, 90 jours) et des variations plus importantes (par exemple, ±15 %).

Solution

« Ça peut toujours être plus petit ». C’est une devise que nous répétons sans cesse. Les éléments plus petits ont tendance à circuler plus rapidement dans le système. Vous pouvez l’appliquer aux livrables, aux items et aux demandes de revue de code ! Voici quelques conseils supplémentaires :

• Lorsqu’une partie prenante vous demande comment livrer plus rapidement, traduisez cette question en expliquant comment vous pouvez livrer plus tôt et plus souvent. Cette traduction rend la question plus facile à mettre en œuvre.
• Encouragez les techniques de découpage des récits utilisateur telles que S.P.I.D.R. Cet outil pratique aide les équipes à réduire le nombre de récits utilisateur.
• Divisez les récits utilisateur de manière à ce qu’ils soient suffisamment petits. L’idéal est de terminer un récit utilisateur en quelques jours, plus précisément au cours d’une semaine de travail.
• Posez-vous la question suivante : est-ce qu’on facilite la vie de nos utilisateurs ? Si c’est le cas, c’est assez petit. Il se peut que ce ne soit pas complet, mais il peut s’agir simplement d’un récit d’utilisateur. Par exemple, lorsque vous créez une facture, un récit utilisateur pourrait être aussi simple que de voir le nom et l’adresse du client sur la facture. On leur facilite la vie parce que la comptabilité devrait autrement les chercher. La fonctionnalité n’est pas complète, mais c’est ce que nous entendons par « livrer plus tôt et plus fréquemment ».

3. Le contrôle de la qualité est long en raison d’un manque d’automatisation

L’assurance et le contrôle de la qualité sont deux choses différentes. L’assurance qualité insère la qualité dans votre processus, tandis que le contrôle qualité vérifie le produit. L’absence de tests automatisés établit une contrainte plus importante de contrôle de la qualité après le développement, ce qui augmente le temps nécessaire à la mise sur le marché d’un changement. L’absence de simulation des systèmes externes crée le besoin de tester dans un environnement intégré, ce qui entraîne des dépendances entre les équipes, une augmentation des erreurs et un allongement du délai de mise sur le marché. Sans oublier que lorsqu’une autre équipe corrompt l’environnement, personne ne peut plus tester et déployer en production.

Comment repérer la tendance ?

Lorsque votre temps de déploiement est long, c’est-à-dire le temps qui s’écoule entre le moment où une demande de revue de code est fusionnée et le moment où elle est déployée en production, c’est un signe que vous avez beaucoup de portes de contrôle ou d’environnements à traverser. Les équipes élites ont un délai nécessaire aux changements inférieur à 24 heures, donc si vous avez un délai de déploiement de plusieurs jours, cela peut indiquer que vous manquez d’automatisation.

Solution

Il est temps de se concentrer sur les tests «shift left ». Il y a quelques points sur lesquels vous pouvez travailler :

• Intégrer les responsables de l’assurance qualité au début du cycle de développement. Demandez-leur de travailler avec les responsables produit et l’équipe de développement pour réfléchir à la manière de tester le système. Découvrez les trois amigos.
• Essayez le développement guidé par le comportement (Behaviour-Driven Development ou BDD) pour créer des scénarios de test et les automatiser par la suite. Cela réduira la nécessité de tout tester manuellement.
• Améliorez les tests de simulation (mocking) et les contrats de tests entre les systèmes afin de réduire la nécessité de tests de bout en bout dans un environnement intégré ; il ne s’agit pas forcément de les éliminer, mais d’en réduire le besoin. Encouragez la notion de pyramide de test.

4. Mauvaise répartition du temps investi

Aligner les efforts pour atteindre les objectifs de l’entreprise tout en opérant de manière efficace est une mission difficile pour un ou une responsable de l’ingénierie. Vous devez donner la priorité à la création d’une nouvelle valeur, au maintien des activités et à l’amélioration des processus. Passez-vous trop de temps sur les bogues ou les travaux d’infrastructure ? Y a-t-il du travail caché qui augmente le temps passé à maintenir le service et qui, par conséquent, n’est pas consacré aux priorités ?

Comment repérer la tendance ?

Vous pouvez inspecter la façon dont votre équipe passe son temps. Des variations significatives du temps consacré aux bogues ou à la nouvelle valeur peuvent être le symptôme d’un lot important de changements ou d’un sprint axé uniquement sur les bogues. Le fait de trop se concentrer sur la nouvelle valeur peut également indiquer que l’équipe accumule de la dette technique et ne la traite jamais, ce qui entraîne un gros remaniement plus tard.

Solution

• Obtenez une visibilité sur le travail effectué. Vérifiez combien de temps est investi dans la création de valeur par rapport au maintien en activité ou à l’amélioration du produit, par exemple.
• Définissez un point de référence. Les grandes équipes consacrent moins de 10 % de leur temps à maintenir leurs activités. Passer plus de 50 % de son temps à maintenir les activités est un symptôme de manque de priorité ou de qualité.
• Évitez le travail fantôme en mettant en place une bonne hygiène de processus, c’est-à-dire en attribuant les revues de code aux items et les items aux épiques lorsque c’est possible. Cela permettra de mieux refléter la réalité.

5. Travailler sur trop d’éléments à la fois

Lorsque tout le monde est occupé, on pense que l’on va plus vite alors qu’en fait, on va moins vite. Tout progresse lentement et le client reçoit la valeur plus tard. Cela augmente également le coût des retards. Lorsque le travail en cours est plus élevé, les items sont en attente, ce qui multiplie les possibilités de transfert et entraîne une augmentation des délais de mise sur le marché.

Comment repérer la tendance ?

Suivez le travail en cours de l’équipe et comparez-le au nombre de contributeurs de l’équipe. La tendance est-elle stable ? Avons-nous tendance à commencer plus de choses ou à en commencer moins ?

Vous pouvez également suivre la stabilité de votre flux de travail ou un diagramme de flux cumulatif. Le mantra est le suivant : « Arrêtez de commencer, commencez à finir ». Vérifiez si vous commencez beaucoup plus d’éléments que vous n’en terminez. Terminez-vous tous les éléments à la fin du sprint en une seule fois, ou avez-vous l’impression d’un flux continu ?

Solution

• Réduisez le travail en cours de l’équipe. Cela semble contre-intuitif, mais permet de réduire le temps de cycle et d’augmenter le rendement.
  • Si vous ne savez pas comment fixer une limite de travail, bien qu’il existe de multiples articles sur ce sujet, vous pouvez simplement commencer par une limite du nombre de contributeurs dans l’équipe moins 1. Cela imposera une première forme de collaboration.
• Concentrez-vous sur les items et non sur les individus.
  • N’attribuez pas d’items à des personnes.
  • Concentrez-vous sur l’élément le plus proche de l’achèvement et chargez un duo ou un trio de personnes de l’achever avant de commencer une nouvelle tâche. Cela réduira naturellement le travail en cours et vous permettra de capturer la valeur plus rapidement.
  • Les choses attendent parce que vous attendez que les gens soient disponibles. Vous n’avez pas besoin d’attendre les autres si vous travaillez ensemble. Cela augmentera considérablement l’efficacité de votre flux et conduira à une meilleure performance.

Pour commencer

La première étape est de commencer à se mesurer. La première série de données que je suggère de rassembler sont les métriques DORA. Elles vous permettront de vous faire une première idée des performances de l’équipe en matière de livraison et de savoir quelles sont les équipes qui ont besoin d’une plus grande attention. 

Mise en place du tableau de bord DORA

Des outils tels qu’Axify s’intègrent parfaitement à votre environnement technologique pour collecter des données précises à toutes les phases du développement. Notre tableau de bord DORA permet de suivre la fréquence de déploiement, le délai nécessaire aux changements, le taux d’échec des changements et le temps de récupération d’un échec de déploiement. Il permet aux équipes de comparer leurs performances avec les références de l’industrie, les performances passées et les autres équipes de la même organisation afin d’identifier les domaines à améliorer et de célébrer les réussites.

Comparer les performances de vos équipes

Nos analyses d’équipes vous permettent de visualiser les métriques DORA pour chaque équipe. Ces données offrent l’avantage de comparer des pommes avec des pommes sur deux facteurs d’efficacité technique importants : la vitesse et la stabilité. Vous pouvez rapidement voir quelle équipe pourrait bénéficier d’une plus grande attention et laquelle pourrait partager ses meilleures pratiques pour une meilleure performance.

Travailler à l’amélioration continue

Transformez la manière dont votre équipe établit et atteint ses objectifs grâce à notre outil de suivi des objectifs et des résultats clés. Voyez en un coup d’œil l’évolution de vos indicateurs de performance et mettez en œuvre des initiatives qui soutiennent l’amélioration continue de votre équipe de développement.

Contactez-nous pour en savoir plus sur la façon dont nous aidons les équipes de développement à améliorer l’efficacité de leurs processus d’ingénierie logicielle en mesurant les indicateurs clés de performance DORA.