Le nirvana du DevOps est encore un loin pour certains

Le nirvana du DevOps est encore un loin pour certains

Le DevOps – la collaboration entre les développeurs et les équipes d’exploitation pour produire des logiciels à un rythme soutenu à l’aide de l’automatisation et d’outils communs – est une proposition convaincante. Cependant, les équipes informatiques sont encore loin du nirvana DevOps. La plupart d’entre elles affirment dans une enquête récente que leurs efforts ne sont pas matures, ce qui freine leur progression.

C’est la principale conclusion d’une enquête menée auprès de 172 professionnels et responsables informatiques par LeanIX, qui révèle un écart important entre la vision DevOps et la réalité.

Malgré tout ce qui a été dit au cours des deux dernières décennies sur l’alignement des choses, de nombreux professionnels de l’informatique ont encore des difficultés à franchir ce gouffre.

publicité

Une collaboration pas toujours fructueuse

Si 59 % des répondants estiment que leur entreprise apprécie leurs efforts, cela signifie tout de même qu’au moins 40 % d’entre eux ne parviennent pas à une collaboration fructueuse. « De plus, seuls 42 % sont entièrement d’accord lorsqu’on leur demande si l’informatique et l’entreprise parlent le même langage », soulignent les auteurs de l’enquête. « Le processus de développement de logiciels peut sembler abstrait et presque incompréhensible pour certaines personnes extérieures aux services informatiques ou d’ingénierie. Cela conduit à une incompréhension mutuelle et à une frustration des deux côtés. »

Le manque d’information ou de compréhension s’étend également aux relations entre les développeurs et les clients. L’enquête montre que les équipes de développeurs ont peu de visibilité sur la façon dont les clients utilisent les logiciels qu’ils créent. La majorité des répondants (70 %) se tournent vers les tickets de support comme principale métrique. « Bien que cette mesure soit facilement accessible, elle ne fournit pas toujours des informations très utiles », indiquent les auteurs de l’enquête.

En outre, deux tiers d’entre eux suivent également le nombre mensuel d’utilisateurs actifs, « un chiffre sans rapport réel avec le logiciel livré et sa valeur pour les clients ». Moins de la moitié d’entre elles utilise d’autres mesures telles que l’adoption des fonctionnalités, le taux de désabonnement, le retour sur investissement ou le taux de recommandation net pour évaluer la satisfaction des clients. 5 % des répondants ne mesurent pas la clientèle.

Un manque de maturité DevOps

« Les équipes de développement, en général, n’ont pratiquement aucune idée de la façon dont les clients bénéficient de leur travail, et peu d’entre elles sont capables de discuter de ces avantages avec l’entreprise », rapportent les auteurs. « Le fait d’avoir ces informations à portée de main améliorerait la collaboration entre l’informatique et l’entreprise. Plus une équipe de développement suit de mesures de la valeur pour le client, plus elle considère sa relation de travail avec l’entreprise comme positive. Sans savoir si la valeur prévue pour le client est atteinte ou non, les équipes de développement volent effectivement à l’aveuglette. »

Les auteurs de LeanIX calculent que 53 % travaillent dans une équipe ayant un « faible niveau » de DevOps sur la base des facteurs de maturité. Pourtant, près de 60 % disent faire preuve de souplesse pour s’adapter à l’évolution des besoins des clients et avoir mis en place des pipelines CI/CD. Dans le même temps, moins de la moitié des ingénieurs construisent, expédient ou possèdent leur code ou travaillent dans des équipes en fonction des topologies d’équipe, ce qui indique un manque de maturité DevOps.

Moins de 20 % des personnes interrogées ont déclaré que leur équipe de développement était en mesure de choisir sa propre pile technologique ; 44 % qu’elles en étaient partiellement capables, et 38 % qu’elles ne l’étaient pas du tout. « La flexibilité autour du choix des outils est un élément central de la culture DevOps, car elle permet aux organisations de réagir plus rapidement à l’évolution des besoins des clients et des entreprises. »

Culture d’entreprise

Il est intéressant de noter qu’il existe une corrélation claire entre la maturité DevOps et la taille de l’organisation : plus l’organisation est grande, plus le niveau de maturité de l’équipe de développement est faible. « En d’autres termes, les équipes travaillant dans de grandes organisations ont adopté moins de méthodes de travail DevOps », selon les auteurs. « Le fait que les organisations comptant plus de 10 000 employés aient plus de mal à mettre en œuvre le DevOps s’explique par le fait que le concept de DevOps lui-même exige un changement culturel fondamental », supposent-ils. « Les grandes organisations complexes ont besoin de plus de temps que les petites organisations agiles pour opérer ce changement et gérer les changements qu’il implique. De plus, les grandes organisations dépendent souvent de nombreux systèmes hérités dont le rôle dans l’avenir de l’organisation n’est pas toujours clair. »

L’enquête montre également que la réduction des efforts manuels par l’automatisation figure en tête de liste des obstacles aux initiatives de DevOps. « Une majorité d’entre eux trouve également que la suppression des silos (qui signale l’absence d’une base de connaissances commune) et la concentration sur les tâches (en raison du changement de contexte) sont quelque peu difficiles. »

« Un peu de DevOps ne suffit pas », concluent les auteurs de l’enquête. « Les méthodes de travail agiles et les initiatives DevOps ont changé de manière décisive le développement de logiciels. Cela ne signifie pas pour autant que la culture DevOps est déjà une réalité vivante dans la plupart des organisations. Il est loin d’être vrai que les entreprises ont pleinement mis en œuvre les méthodes de travail associées au DevOps. Pour cette raison, il n’est pas surprenant que les équipes rencontrent régulièrement des défis dans leur travail quotidien qui font obstacle à un développement logiciel efficace. »

Source : ZDNet.com

Leave a Reply

Your email address will not be published. Required fields are marked *