Où va DevOps ? Est-il ‘mort’ comme certains le sont suggérer, à remplacer par d’autres disciplines telles que l’ingénierie des plateformes ? Je dirais que même si cela n’a jamais été aussi simple que cela, c’est maintenant le meilleur moment pour réfléchir à des approches telles que celles discutées dans les cercles DevOps. Examinons donc leur cœur et voyons comment ils peuvent être appliqués à la fourniture d’innovations logicielles à grande échelle.
Un peu de contexte. Mon premier travail, il y a trois décennies, était celui de programmeur ; Plus tard, j’ai dirigé des outils logiciels et une infrastructure pour des groupes de développement d’applications ; J’ai ensuite conseillé de très grandes organisations sur la manière de développer des logiciels et de gérer les centres de données, les serveurs, le stockage, la mise en réseau, la sécurité, etc. Au cours de cette période, j’ai vu beaucoup de logiciels livrés avec succès, et une quantité non négligeable a été mise en échec, remplacée ou ne correspondait pas à la facture.
Fait intéressant, même si j’ai vu beaucoup d’aspirations en termes de meilleures façons de faire les choses, je ne peux m’empêcher de penser que nous travaillons encore sur certaines des bases. DevOps lui-même a vu le jour au milieu des années 2000, comme un moyen de sortir des modèles plus anciens et plus lents. Dix ans auparavant, cependant, je travaillais déjà à l’avant-garde du «boom agile», en tant que consultant en méthodologie de développement de systèmes dynamiques (DSDM).
Au milieu des années 90, des approches plus anciennes et lourdes de la production de logiciels, avec des délais de deux ans et aucune garantie de succès, ont été reconsidérées à la lumière de la croissance rapide d’Internet. Et avant cela, les méthodes en spirale de Barry Boehm, le développement rapide d’applications et autres offraient des alternatives aux méthodologies en cascade, dans lesquelles la livraison serait embourbée dans des exigences surspécifiées (ce que l’on appelle la paralysie d’analyse) et des régimes de test épuisants.
Pas étonnant que des gourous du développement logiciel tels que Barry B, Kent Beck et Martin Fowler aient cherché à revenir à la source (sic) et à adopter l’approche JFDI qui se poursuit aujourd’hui. L’idée était, et reste simple : prendre trop de temps pour livrer quelque chose, et le monde aura évolué. Cela reste plus vrai que jamais – l’objectif était, est et continue d’être de créer des logiciels plus rapidement, avec tous les avantages d’un retour d’information amélioré, d’une valeur plus immédiate, etc.
Nous voyons certainement des exemples de réussite, alors pourquoi cela ressemble-t-il davantage à la livraison d’un disque à succès ou d’un roman qui tue, qu’au statu quo ? Les organisations à tous les niveaux se tournent vers les équipes à deux pizzas, les principes SAFe Agile et les métriques DORA, mais ont encore du mal à faire évoluer les approches agiles dans leurs équipes et leurs entreprises. Les outils devraient pouvoir aider, mais (comme je le dis ici) peut également faire partie du problème plutôt que de la solution.
Alors, quelle est la réponse ? À l’époque où j’étais consultant DSDM, mon travail consistait à aider les enfants cool à faire les choses rapidement, mais à faire les choses correctement. Au fil du temps, j’ai appris un facteur qui se démarquait de tous les autres, qui pouvait faire ou défaire une pratique de développement agile : la complexité. La vérité ultime avec le logiciel est qu’il est infiniment malléable. Dans les limites de ce que le logiciel peut permettre, vous pouvez vraiment écrire tout ce que vous voulez, potentiellement très rapidement.
Nous pouvons remercier Alan Turing d’avoir reconnu cela lorsqu’il a conçu sa machine éponyme à base de bande de papier, sur laquelle il a fondé sa théorie du calcul. En termes simples, la machine de Turing peut (en principe) exécuter n’importe quel programme mathématiquement possible ; non seulement cela, mais cela inclut le programme qui représente le fonctionnement de tout autre type d’ordinateur.
Vous pouvez donc écrire un programme représentant un ordinateur Cray, par exemple, le faire tourner sur un Apple Mac, et dessus, en exécuter un autre qui émule un ordinateur central IBM. La raison pour laquelle vous voudriez n’est pas claire, mais pour un exemple amusant, vous pouvez descendre dans un terrier de lapin pour découvrir les différentes plates-formes sur lesquelles le jeu de tir à la première personne Doom a été porté, y compris lui-même.
Bon temps. Mais l’immédiateté d’une possibilité infinie doit être manipulée avec précaution. À l’époque où j’étais DSDM, j’ai appris la puissance du principe de Pareto, ou en termes simples, “séparons les choses dont nous avons absolument besoin, des choses intéressantes à avoir, elles peuvent venir plus tard”. Ce principe quatre-vingt-vingt est plus vrai et plus nécessaire que jamais, car le premier danger de pouvoir tout faire maintenant est d’essayer de tout faire, tout à la fois.
Le deuxième danger est de ne pas enregistrer les choses au fur et à mesure. Imaginez que vous êtes Thésée, descendant pour trouver le minotaure dans le labyrinthe de cavernes en dessous. Sans reprendre votre souffle, vous parcourez de nombreux passages avant de vous rendre compte qu’ils se ressemblent tous, et vous ne savez plus lesquels prioriser pour votre prochaine version de votre application de cartographie native du cloud.
D’accord, j’étends l’analogie, mais vous obtenez le point. Dans un récent panel en ligne, j’ai comparé les développeurs à l’apprenti sorcier – c’est une chose de pouvoir fabriquer un balai à volonté, mais comment allez-vous les gérer tous ? C’est une aussi bonne analogie que n’importe quelle autre, pour refléter à quel point il est simple de créer un artefact basé sur un logiciel et pour illustrer les problèmes créés si chacun ne reçoit pas au moins une étiquette.
Mais voici l’ironie : la complexité résultant du fait de faire les choses rapidement sans contrôles, ralentit les choses dans la mesure où elle tue l’innovation même qu’elle visait à créer. Au cours d’une discussion privée, j’ai appris que même les enfants emblématiques des méga-entreprises natives du cloud sont désormais aux prises avec la complexité de ce qu’ils ont créé – c’est bien pour eux de l’ignorer pendant qu’ils ont établi leur marque, mais vous ne pouvez mettre que du bon vieux -façonné la gestion de la configuration depuis si longtemps.
J’ai commencé à écrire sur « l’écart de gouvernance » entre le monde de l’action et le reste. Cela fonctionne de deux manières, d’abord que les choses ne se font plus ; et deuxièmement, même lorsqu’ils le sont, ils ne correspondent pas nécessairement aux besoins réels de l’entreprise ou de ses clients – appelez cela le troisième danger de faire les choses à la hâte.
Lorsque le terme Value Stream Management a commencé à devenir à la mode il y a trois ans, je ne l’ai pas adopté parce que je voulais sauter dans un autre train en marche. Au contraire, j’avais eu du mal à expliquer la nécessité de combler ce fossé de gouvernance, au moins en partie (DevSecOps et le mouvement de gauche sont également sur la liste des invités à cette fête). VSM est arrivé au bon moment, non seulement pour moi, mais pour les organisations qui avaient déjà réalisé qu’elles ne pouvaient pas faire évoluer leurs efforts logiciels.
VSM n’est pas né sur un coup de tête. Il a émergé de la communauté DevOps elle-même, en réponse aux défis causés par son absence. C’est vraiment intéressant et offre un crochet à tout décideur senior qui se sent dépassé lorsqu’il s’agit de remédier au manque de productivité de ses équipes logicielles les plus avancées.
Mettez de côté le syndrome de l’imposteur d’entreprise : il est temps d’appliquer certaines de ces sagesses plus anciennes, telles que la gestion de la configuration, la gestion des exigences et la gestion des risques. Ce n’est pas que les approches agiles étaient mauvaises, mais elles ont besoin de telles pratiques d’entreprise dès le départ, sinon tout avantage se répercutera rapidement. Alors que les entreprises ne peuvent pas soudainement devenir des startups insouciantes ; ils peuvent intégrer la gouvernance traditionnelle dans de nouvelles méthodes de livraison de logiciels.
Ce ne sera pas facile, mais c’est nécessaire, et cela sera soutenu par les fournisseurs d’outils au fur et à mesure qu’eux aussi mûriront. Nous avons vu VSM passer de l’un des nombreux acronymes à trois lettres traitant de la visibilité de la direction sur le pipeline de développement, à devenir celui autour duquel l’industrie se rallie. Alors même qu’un débat se développe entre sa relation avec la gestion de portefeuille de projets (PPM) de haut en bas (comme illustré par l’acquisition de Tasktop par Planview), nous constatons un intérêt accru pour les outils d’analyse de développement logiciel venant de bas en haut.
Au cours de l’année à venir, je m’attends à voir davantage de simplification et de consolidation dans l’ensemble des outils et de la plate-forme, permettant des approches plus axées sur les politiques, de meilleures barrières de sécurité et une automatisation améliorée. L’objectif est que les développeurs puissent continuer et faire la chose avec un minimum d’encombrement, même si les managers et l’entreprise dans son ensemble ressentent l’avantage de la coordination.
Mais cela exigera également des organisations d’entreprise – ou plus précisément de leurs groupes de développement – qu’elles acceptent qu’il n’y a rien de tel qu’un repas gratuit, pas quand il s’agit de logiciels de toute façon. Toute approche du développement logiciel (agile ou autre) exige des développeurs et de leur direction qu’ils tiennent fermement les rênes des entités vivantes qu’ils créent, en les regroupant pour créer de la valeur.
Est-ce que je pense que les logiciels devraient être livrés plus lentement ou est-ce que je suis favorable à un retour aux méthodologies à l’ancienne ? Absolument pas. Mais certains des principes qu’ils adoptent étaient là pour une raison. De toutes les vérités du logiciel, reconnaissez que la complexité existera toujours, qu’il faut ensuite gérer. Ignorez cela à vos risques et périls, vous n’êtes pas un vieil ennuyeux en remettant la gouvernance de la livraison de logiciels sur la table.
