Formation DevOps écrite

Comment favoriser votre flux DevOps ?

En DevOps, le flux désigne toute la chaîne de production d’un logiciel, de l’idée jusqu’au code exécuté dans vos systèmes de production. Vos équipes DevOps et vous-même devez mettre en place et maintenir un flux fiable, régulier et rapide pour atteindre et dépasser les objectifs de votre organisation et devancer les autres produits et services sur votre marché.

Définissez une mission pour votre transformation DevOps

Une fois l’équipe DevOps constituée, définissez sa mission. Une mission commune lui donne les moyens de bien fonctionner. Sans elle, l’équipe ne peut ni hiérarchiser les tâches essentielles ni distinguer les véritables blocages des petites tâches. La mission doit être ambitieuse et marquante, tout en restant réalisable dans un délai donné.

Adaptez la mission à votre propre équipe DevOps. Elle découle des caractéristiques, des défis et des objectifs de votre organisation et doit servir les clients internes et externes qui travaillent avec l’équipe.

Voici quelques exemples de missions pour lancer votre transformation DevOps :

• Réduire de 75 %, en trois mois, le délai moyen entre l’intégration du code et sa mise en production effective.
• Réduire de 33 %, en six mois, le délai moyen entre la demande et la mise en production effective.
• Réduire de 50 % le nombre d’incidents en production en douze mois.

Qu’est-ce qu’un flux de valeur et qui y participe ?

Pour améliorer votre travail, vous devez connaître votre flux de valeur. Dans les systèmes informatiques, un flux de valeur est la suite des activités nécessaires pour concevoir, construire et exploiter un produit et un service logiciels donnés. Il définit aussi les personnes, le savoir-faire, les moyens et le matériel nécessaires à son fonctionnement.

Dans une structure organisationnelle complexe, personne ne peut identifier seul le flux de valeur de bout en bout. Tous les membres de votre équipe DevOps, les parties prenantes, les fournisseurs, les représentants des clients et, si possible, les clients eux-mêmes devraient participer à son identification.

Cartographiez votre flux de valeur pour repérer les améliorations possibles

Une cartographie du flux de valeur permet à votre équipe DevOps et à vous-même de visualiser la manière dont une tâche typique est réalisée dans votre organisation de développement et de livraison de logiciels. Le but est de comprendre suffisamment votre flux de travail habituel pour repérer les principaux problèmes, contraintes, inefficacités et gaspillages de temps et de ressources, sans documenter chaque étape de façon exhaustive.

Lorsque des ingénieurs de développement et d’exploitation se réunissent pour la première fois afin de cartographier un flux de valeur, c’est souvent la première occasion pour un ingénieur d’exploitation de comprendre les effets négatifs de serveurs de bases de données mal configurés, dépourvus d’espaces de tables, sur les équipes de développement. De même, un ingénieur en développement voit souvent pour la première fois les conséquences d’une livraison logicielle qui n’intègre ni supervision, ni disponibilité, ni testabilité, ni mécanismes de configuration.

Éliminez autant que possible les transferts de responsabilité, les contraintes et les gaspillages

Les transferts de responsabilité, les gaspillages et les contraintes font partie des facteurs d’efficacité les plus importants et les plus négligés. Lorsqu’une activité passe d’une équipe à une autre, il faut signaler le besoin, formuler une demande, planifier le travail, revoir les priorités à la hausse ou à la baisse et résoudre les conflits.

Chaque transfert d’une équipe à une autre entraîne une perte d’information et allonge le délai global du flux de valeur.

Pour résoudre ces problèmes :

• Vous devez remettre en question le temps nécessaire à chaque transfert de responsabilité. Dans l’exemple de cartographie ci-dessus, il faut 80 heures avant que l’équipe de déploiement récupère le code qui a réussi les tests. Pourquoi ? Ne pouvons-nous pas automatiser ce processus ? Bien sûr que si.
• Vous devez éliminer les gaspillages dus aux transferts de responsabilité répétitifs. Selon l’exemple ci-dessus, l’équipe de test renvoie 65 % des fonctionnalités au développement. Certains correctifs doivent être livrés jusqu’à trois fois avant d’être approuvés par les testeurs. Pourrions-nous accélérer ces itérations en rapprochant les équipes de développement et de test ? Le grand nombre de défauts montre aussi que l’équipe de développement rencontre un problème. Il faut repérer et traiter les causes de ces problèmes de qualité.
• Vous devez remettre en question et supprimer autant de transferts de responsabilité que possible. Dans l’exemple ci-dessus, une fois une demande affinée, il faut attendre 320 heures avant qu’elle soit traitée par la personne chargée de l’approuver. Pourquoi votre organisation a-t-elle besoin de cette approbation ? Quelle valeur apporte-t-elle au flux ? La personne chargée de décider dispose-t-elle de suffisamment d’informations et de recul ? Pourquoi ne pas l’intégrer à l’équipe qui affine les demandes ? Elle comprendrait bien mieux ce qu’elle approuve et vous élimineriez un transfert de 320 heures. Tant que vous ne supprimez pas les contraintes et obstacles qui ralentissent votre flux, vous ne pouvez pas attendre grand-chose du DevOps.

Le DevOps vous invite à poser ces questions pour remettre en cause les habitudes. Tout le monde dans votre organisation ne sera pas ravi de les entendre. Vous y êtes déjà préparé.

Rendez votre flux visible pour tous

Pour que le travail progresse de gauche à droite et que votre organisation DevOps atteigne ses objectifs, vous devez mettre en place des outils et des mécanismes qui rendent le flux visible. En informatique, un clic suffit pour attribuer une tâche à une autre équipe dans le flux de valeur. En raison du travail incomplet, des dépendances incohérentes et des malentendus, les tâches rebondissent pourtant chaque jour d’une équipe à l’autre, selon le principe « un pas en avant, deux pas en arrière ». Elles avancent trop lentement, quand elles avancent.

Il est donc important de rendre le flux visible à toute l’organisation. Le DevOps s’appuie sur le backlog produit, le backlog de planification du sprint et les tableaux Kanban. Ces tableaux doivent montrer les tâches de votre propre équipe DevOps et le flux tout entier, depuis l’idée de vos produits et services jusqu’à leur maintenance et leur fin de vie. Ainsi, une tâche bloquée devient rapidement visible pour tous. Il incombe alors à chacun de supprimer les obstacles pour que le travail puisse avancer en continu.

Limitez la taille des lots et la quantité de travail en cours

Des recherches menées à l’université Stanford ont montré que faire plusieurs choses à la fois est moins productif que les faire une à une. Les chercheurs ont également constaté que les personnes régulièrement exposées à plusieurs flux d’informations électroniques étaient moins aptes à se concentrer, à retenir des informations ou à passer d’une tâche à l’autre que celles qui effectuaient une seule tâche à la fois.

Pour votre équipe DevOps, cela implique de réduire le travail en cours et de limiter la taille des lots de code livrés. Par exemple, votre équipe peut se limiter à six tâches de développement en cours pour éviter de changer constamment de contexte et rester concentrée sur le travail immédiat. Vous pouvez aussi estimer chaque tâche en points en utilisant la suite de Fibonacci (0, 1, 2, 3, 5, 8, 13, 21, 34, etc.). Votre équipe DevOps traite alors jusqu’à un certain nombre de points (sa vélocité) sur une période donnée (le sprint).

Limiter la taille des lots améliore la qualité et la productivité et vous permet d’identifier les causes profondes des problèmes et de les résoudre plus vite. Une fois une tâche terminée, vous intégrez le code dans le dépôt commun, le validez avec votre plateforme d’intégration continue, puis le déployez en production. Avec de petits lots, les problèmes de production dus aux livraisons sont plus faciles à détecter et les éventuels retours en arrière moins laborieux. En livrant continuellement en production, votre équipe éprouve aussi la fierté de contribuer à la mission de votre organisation. Comparez cette façon de travailler au moral, à la motivation et aux difficultés techniques d’équipes qui développent leur code pendant huit mois sans livrer une seule ligne en production.

Consacrez 20 % de votre temps à réduire la dette technique

Si votre organisation n’accorde pas de temps à la réduction de la dette technique et continue d’empiler les solutions de contournement, tous les ingénieurs finiront par passer tout leur temps à résoudre des problèmes. Pour reprendre l’analogie financière, votre organisation ne paiera alors que les intérêts de sa dette.

CONCLUSION

Dans ce chapitre, nous avons expliqué ce que sont le flux et le flux de valeur en DevOps, pourquoi ils comptent et comment faire avancer le travail dans votre flux de valeur.