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.
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.
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.
Dans cette situation, il y a quelques options à considérer :
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.
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 %).
« Ç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 :
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.
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.
Il est temps de se concentrer sur les tests «shift left ». Il y a quelques points sur lesquels vous pouvez travailler :
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 ?
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.
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é.
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 ?
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.
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.
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.
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.