Nous avons récemment interviewé Fabio Mora, expert DevOps et auteur du livre “DevOps. Guida per integrare Development e Operations e produrre software di qualità”. Dans cette interview, Fabio nous explique quelles sont les difficultés principales rencontrées par les organisations souhaitant utiliser DevOps et quels sont les défis que DevOps peut aider à relever.
Quelles sont selon vous, les principales difficultés rencontrées par les organisations souhaitant utiliser le DevOps ?
Chaque organisation à sa propre histoire et il est difficile de les comparer, mais il y a certaines choses que je vois fréquemment, notamment en Italie.
- Subir le fort héritage culturel
J’ai pu constater que l’héritage culturel était encore très présent, notamment dans les entreprises existantes où il y a beaucoup de bureaucratie. Mais il y a aussi des cas où une entreprise naît et la direction tente d’appliquer des modèles en vigueur dans le monde économique précédent. Les entreprises, en particulier les grandes, qui ont déjà connu des périodes de gloire dans le passé, sont nées avec des divisions claires, hiérarchiques, bureaucratiques Les entreprises existantes, notamment les plus grandes, qui ont connu des périodes de splendeur dans leur histoire, sont nées avec des divisions claires, hiérarchiques, bureaucratiques et des fluctuations de marché moins complexes et moins frénétiques. Dans ces cas, l’organisation peut avoir beaucoup à « désapprendre » de ce qu’elle faisait auparavant. Ce qui nous met assez souvent en difficulté est le fait d’arrêter de faire quelque chose qui fonctionnait jusqu’à hier pour commencer quelque chose de nouveau, dont on se méfie, que l’on ne connaît pas bien, ce qui est très fatiguant et stressant. Au final, on se rend compte que cela n’a que très peu à voir avec le logiciel et beaucoup à voir avec la reconnaissance du fait que les gens sont au cœur de tout discours où il y a un travail immatériel à faire (les soi-disant travailleurs du savoir).
- Commencer une transformation sans aller au bout des choses
Il s’agit de » bien commencer » et … puis de s’arrêter là, souvent en copiant les expériences des autres (comme SCRUM, comme le modèle Spotify ou des frameworks comme SAFe etc.). Il n’y a rien de mal à imiter au début, c’est effectivement un bon début, mais ensuite il faut aller plus loin et apprendre à marcher seul et persévérer continuellement, en faisant de petites expériences. Le guide SCRUM, par exemple, fait une vingtaine de pages, il peut se lire rapidement 20 pages, non ? Ensuite, il faut continuer à faire des expériences, commencer sa transformation. Cependant, il n’y a pas de magie dans les méthodes agiles ni dans Devops. Après avoir gratté la surface des valeurs, des rythmes et des principes, il faut étudier plus en profondeur et s’engager : aucune méthodologie ne remplace des années d’étude personnelle et individuelle.
- Outsourcer le développement de logiciel
Les méthodes agiles sont nées pour faire des logiciels et on l’oublie souvent car dans la marmite, il y a un élément qui peut être transporté un peu partout : l’amélioration des processus. Ce qui est bien avec les méthodes Agiles, c’est qu’elles sont une manière sensée de travailler en général, que vous fassiez ou non des logiciels. L’agilité contamine avec un brin de vertus tous les secteurs d’activité et la rumeur se répand que travailler avec certaines pratiques et valeurs est plus efficace… donc tout le monde veut l’apprendre. Mais lorsque le processus est adopté, des problèmes techniques apparaissent. À ce stade, vous avez besoin d’excellents professionnels qui savent bien programmer et qui » sortent des sentiers battus » pour faire du DevOps. En effet, il n’est pas rare de voir des méthodes agiles utilisées dans des groupes à forte composante managériale, stratégique ou encore marketing, mais avec un petit nombre de techniciens (programmateurs, ingénieurs systèmes…)En Italie de nombreuses entreprises qui ont connu des périodes de prospérité ont toujours marginalisé les programmeurs, les ingénieurs système et les analystes et elles se sont appuyé sur des sociétés de conseil qui gèrent à distance leurs logiciels pour des « projets » . Cette situation est la résultante d’une culture où la valeur productive des logiciels n’a jamais été considérée comme une ressource stratégique du point de vue économique (capital productif), mais uniquement comme un simple élément de coût. En revanche, elle constitue un investissement correct, de surcroît très complexe, à la santé fragile, qu’il est difficile de remplacer lorsqu’elle est intégrée aux processus de production de l’entreprise.
Dans l’ADN de nombreuses dot-coms (qui dominent encore le marché aujourd’hui), les techniciens sont très largement représentés, tandis que les consultants y occupent une position très marginale. En Italie, ces dernières années la tendance s’est inversée et nous avons été confrontés à de nombreux dysfonctionnements, les enseignements des années Olivetti ont déjà été oubliés. Heureusement, on est en train d’assister à une inversion de tendance: la « vieille économie » et les grandes entreprises commencent timidement à recruter des techniciens et des programmateurs. Cette démarche est pertinente, mais il est indispensable de la concrétiser le plus rapidement possible.
Quels sont les défis que DevOps peut aider à relever ?
Les processus traditionnels de production de logiciels prévoient (généralement) que pour une certaine date, peut-être des mois, nous nous engageons à définir le nombre de fonctionnalités (exigences) à mettre en œuvre, en estimant les temps et les ressources nécessaires pour y parvenir. Mais souvent, les prévisions sont inexactes, alors pour tenir nos engagements, nous commençons à réduire la qualité, à modifier le code source ou à manquer de temps ou de ressources. Les méthodes agiles dont DevOps est une évolution naturelle renversent la question et affirment : faisons un maximum de choses avec peu de ressources et de temps disponibles. Nous ne promettons pas de tout réaliser en une seule fois; nous priorisons les fonctionnalités à implémenter par importance, en réduisant la longueur des sprint à effectuer et en réalisant une chose à la fois. De cette façon, le client peut voir le logiciel fonctionner immédiatement et non pas au bout de plusieurs mois. Si l’on ne parle que d’infrastructures et de systèmes, en revanche, l’objectif fondamental de DevOps est de réduire le temps entre la conception du produit et la livraison de celui-ci au client. Combien de fois fournissez-vous par semaine ? Quel pourcentage de versions sont réussies ? Si ces deux indicateurs sont optimisés cela signifie que vous êtes en train d’appliquer la méthode DevOps.
