DevOoops : l’incapacité à surmonter les obstacles organisationnels

L’approche DevOps a pour objectif de rendre le processus de distribution des logiciels plus efficace. Malheureusement, les initiatives DevOps entraînent parfois des erreurs, des "DevOoops", que l’on peut regrouper en 5 catégories distinctes.

Les pratiques DevOps apportent des bénéfices certains à l’entreprise en alignant les besoins métiers et les activités de développement logiciel. La mise en œuvre du DevOps en entreprise n’est pas toujours couronnée de succès.

Une culture d’entreprise inadéquate peut s’avérer être un véritable obstacle aux pratiques DevOps. Elle résulte le plus souvent du cloisonnement des services.

Lorsqu’un problème est identifié, il convient d’observer le système dans son ensemble et d’identifier les points à améliorer. Le plus souvent, les différents services se rejettent la responsabilité du dysfonctionnement, et il s’avère que le principal problème à régler est un problème de communication inter-services. L’élimination des silos est l’objectif premier du DevOps. Cependant, la plupart des entreprises le dénaturent en créant un autre silo, le "service DevOps". Dans ce contexte, la pratique DevOps va totalement à l’encontre de ses propres théories.

Il y a plus de 50 ans, alors qu’il travaillait sur les compilateurs, Melvin Conway a identifié l’origine du problème actuel que les entreprises cherchent à résoudre à l’aide du développement de logiciels modernes et des pratiques DevOps : les entreprises qui créent des systèmes se retrouvent contraintes à produire des modèles qui ne sont autres que des copies de leurs structures de communication.

Ce concept, appelé loi de Conway, montre comment l’incapacité à supprimer les silos et à former des équipes interfonctionnelles et collaboratives reste, aujourd’hui encore, un véritable obstacle à la mise en place du DevOps. En dépit de toute la meilleure volonté du monde, elle entraîne un dysfonctionnement du logiciel.

La plupart des entreprises sont organisées par fonction : les services commerciaux, la gestion de projet, les propriétaires de projet, les développeurs, les équipes qualité, celles de déploiement des applications, l’infrastructure et les groupes de sécurité se concentrent tous sur leur domaine respectif de compétence.

Les initiatives DevOps tentent de décloisonner ces services. Cela est malheureusement plus facile à dire qu’à faire, car la plupart des entreprises qui se lancent dans l’aventure DevOps doivent d’abord venir à bout de la mentalité "nous contre eux".

Les différends internes créent des tensions donnant lieu à d’importants désaccords lors des échanges entre les équipes. Les problèmes surviennent généralement pendant le processus de distribution des logiciels et dans le logiciel lui-même, sous forme d’écarts de qualité, d’incohérences dans l’expérience utilisateur etc.

Lorsque plusieurs services qui ne communiquent pas travaillent sur une même application, chacune ayant sa propre approche de l’expérience utilisateur, il est peu probable que le résultat final soit homogène et l’ergonomie du logiciel idéalement pensée. Si le commercial et le développeur interprètent un besoin client différemment, le produit final ne répondra pas aux attentes de ce dernier. Si une équipe est chargée des pages de connexion et d’authentification, tandis qu’une autre s’occupe de celle d’accueil, le rendu final risque d’être disparate.

Les entreprises doivent prendre conscience que le DevOps repose sur une véritable culture du décloisonnement et s’engager à régler ce problème. Ce ne sera pas chose facile, ça n’arrivera pas du jour au lendemain, mais avec quelques efforts, c’est possible.

  Trois stratégies pour supprimer ces obstacles organisationnels

·         Alignement : il est important de réfléchir à la meilleure façon d’aligner les équipes physiques et virtuelles, et de les regrouper autour des produits, des fonctionnalités ou du fonctionnement des produits au lieu des compétences ou des fonctions. Par exemple, il est possible de créer une petite équipe flexible autour du middleware, incluant des développeurs, ainsi que des membres des services des ventes, de la qualité et des opérations.

·         Communication : il est question ici d’encourager en permanence la communication, la confiance et la transparence. Pour ce faire, les outils de communication en temps réel tels que Slack peuvent être utilisés ou encore il est possible de rassembler et partager à l’aide d’outils tels que Jira. Les équipes doivent lutter contre le sentiment de méfiance. Il est recommandé aux entreprises de mettre en place des mécanismes de suivi qui prennent en compte à la fois les réussites et les échecs dans le but de créer un meilleur produit.

·         Engagement : faire participer les parties prenantes clés dès le début et tout au long du processus est primordial. Lorsqu’une entreprise se lance dans l’aventure DevOps, elle peut ainsi former des équipes et s’assurer que toutes les parties prenantes ont la possibilité de s’exprimer. Il faut ici faire en sorte que chaque besoin soit aligné sur ceux de l’équipe afin de préparer un terrain propice à la collaboration et à la communication.

Pour que la démarche DevOps soit un succès, les entreprises doivent concentrer les efforts des équipes sur des caractéristiques produit et sur les fonctionnalités du produit. Toutes les parties prenantes au processus de développement logiciels doivent être intégrées au sein des équipes.

Dans l’approche DevOps, la culture est tout aussi importante que le processus, les pratiques, les outils et la technologie. C’est un aspect primordial à prendre en compte, d’autant qu’il demande une prise en compte des aspects humains, une conduite du changement, des indicateurs de réussite, mais aussi de la patience…