DevOps pourrait transformer la façon dont votre organisation réalise des projets logiciels, mais vous devrez surmonter certains obstacles en cours de route.
La mise en œuvre de DevOps peut signifier éviter certains obstacles rencontrés par les cadres intermédiaires
DevOps promet de faire fonctionner ensemble le développement et les opérations de manière transparente pour fournir plus rapidement de meilleurs logiciels. Mais comment prendre un bon départ?
Nathan Wilson est directeur de recherche chez Gartner et son objectif principal est l'adoption et la gouvernance de l'informatique agile, y compris le développement lean et agile et Scrum.
ZDNet lui a parlé des différentes définitions du DevOps et de la façon dont il est susceptible d'évoluer.
ZDNet: Je pense que les gens ont du mal à définir DevOps. Vous trouvez ça ?
Wilson: Oui, DevOps n'a pas de définition cohérente au sein du secteur et la définition change en raison de différents impacts. Mais au départ, nous avons défini DevOps comme l'application de techniques agiles aux opérations et la collaboration effective du développement et des opérations.
La prochaine étape consiste donc à abattre le mur entre l'assurance qualité et le développement, puis à passer à l'agilité - et bientôt à briser ce mur en opérations.
C'était classiquement ainsi que nous en parlions, puis il y a quelques années, un fournisseur majeur a développé un outil de déploiement continu et a redéfini DevOps. Ils y voyaient un déploiement instantané: un développeur enregistrait quelque chose et le déployait en moins d'une heure. Cela a donc été étiqueté DevOps.
Puis un de mes amis, un autre analyste de Gartner qui couvre le côté opérationnel du DevOps, George Spafford, avec Gene Kim et Kevin Behr, a produit Le projet Phénix. Cela est devenu connu sous le nom de livre DevOps, même si leur intention n'était pas d'écrire un livre sur DevOps, mais plutôt d'écrire un livre sur la façon dont vous appliquer le Lean Management à l’informatique.
Désormais, l’application du Lean à l’ensemble du processus informatique est également considérée comme du DevOps. Vous avez donc raison, il existe une certaine confusion sur ce qu'est DevOps. En fait, il existe tout un tas de définitions farfelues.
Q: Il doit donc y avoir un énorme écart entre les entreprises qui le font, même si elles ne l'appellent peut-être pas DevOps, et celles qui ne le font pas ?
Oui, nous examinons ce que nous appelons des « fournisseurs à l'échelle du Web », ou nous pourrions les appeler des « fournisseurs à grande échelle » comme Amazon, Netflix, etc., qui sont à la pointe du domaine. Ils font des choses que personne d’autre ne peut faire et ils sont une grande source d’inspiration.
Nous disons donc: « Regardez ce que font ces grands fournisseurs et vous n'êtes peut-être pas Facebook, mais vous pouvez apprendre de Facebook ».
Ensuite, il y a quelques entreprises qui ont un peu de recul par rapport à cela, mais qui font des choses comme une livraison quasi continue - ils effectuent des livraisons plus d'une fois par jour sur certains de leurs projets.
Ce sont des entreprises qui, comme avec Le projet Phénix, travaillent à réduire la taille de leurs lots [réduction de la quantité de code requise lors d'un changement] pour essayer de parvenir à cette taille de lot magique d'un seul. Cela signifie qu’un très petit changement est apporté à la fois. Mais pour être honnête, la plupart des autres personnes à qui je parle viennent tout juste d’apprendre à faire preuve d’agilité.
À moins que vous puissiez faire quelque chose comme « Scrum and Deploy » chaque semaine ou toutes les deux semaines, vous n'êtes pas prêt à aller plus vite. [L'idée de Scrum est de créer un environnement sûr et sans changement afin que votre équipe puisse se concentrer sur la tâche de développement prévue. L'équipe planifie un sprint de deux semaines pour développer et déployer une idée.]
Parmi les quelque 1 000 entreprises avec lesquelles j’ai parlé de l’agilité, très peu d’entre elles en sont arrivées à ce point.
Q: Quels sont les problèmes ?
C'est en grande partie une question de culture. Cela concerne en partie les pratiques. J'ai écrit un article l'année dernière intitulé Licencier les deux tiers de votre organisation informatique et cela a imputé une grande partie de la faute aux cadres intermédiaires.
Il y avait un monsieur d'Intel qui l'a décrit comme "le pergélisol des cadres intermédiaires". Ce n'est pas inhabituel dans tout changement organisationnel. Les développeurs le comprennent et les cadres supérieurs le comprennent - en grande partie parce qu'ils ont lu Le projet Phénix - mais les cadres intermédiaires le voient et pensent: "Je ne sais pas comment je vais y ajouter de la valeur donc je vais me battre parce que si je ne le fais pas, je pense que je vais me retrouver à la rue". .
Q: Existe-t-il donc un obstacle difficile à contourner pour les cadres intermédiaires ?
Oui, c'est assez difficile de s'y déplacer. Une façon d’y parvenir est de comprendre que l’agilité est un sport d’équipe. La plupart des services informatiques ne sont pas une équipe, ce sont des ensembles d'individus.
Il y a quelques années, il y avait un livre intitulé Leadership tribal et cela indiquait qu'une culture axée sur l'équipe ne représentait qu'environ 25 pour cent de toute organisation. Alors, que faites-vous des trois quarts restants? Trouvez-vous un moyen de leur permettre de travailler, même s'ils ne peuvent pas former d'équipes parce que leur culture n'est pas conviviale ?
Q: Mais n'est-ce pas une vieille idée qui remonte au culte du « programmeur solitaire de génie » ?
C'est toujours répandu. Vous verrez toujours des articles sur je cherche ce "programmeur 10x" c'est ainsi que vous appelez cette personne maintenant. Mais je rappellerai constamment à nos clients que peu importe que vous ayez ou non un programmeur 10x. Maintenant, tout tourne autour de l’équipe 10x. Maintenant, cette équipe 10x peut inclure l'un de ces programmeurs 10x, mais vous feriez mieux de mettre autour de lui des personnes ayant des compétences sociales, sinon vous allez avoir un problème.
Q: Selon vous, combien de vos clients adoptent DevOps ou du moins en parlent ?
Il fait suite à l’agile. Je reçois très rarement désormais un appel disant: « Nous réfléchissons simplement à adopter l'agilité ». Il y a trois ans, c'était la plupart de mes appels.
On disait donc: « Nous avons de l'agilité dans ces groupes, comment pouvons-nous l'étendre? » Ou bien, "Notre nouveau CIO dit que nous devons être agiles, comment diable puis-je y parvenir ?" Maintenant, c'est: "Nous devons faire du DevOps, comment diable puis-je y parvenir? désactivé?"
C’est donc là que je vois DevOps intégrer l’agilité aux opérations, alors qu’il y a quelques années, c’était exactement le contraire.
Q: Lorsque cela se produit, est-il vrai qu'une personne est la plus importante et que vous avez besoin d'un champion pour que cela se produise ?
Il est important d'avoir des champions. Ce que nous constatons aujourd’hui, c’est que dans une organisation informatique typique, environ un tiers des personnes comprennent cela et en sont frustrées. Ce troisième sort, ils assistent à des conférences, ils lisent tout sur ces trucs sympas qu'ils peuvent faire mais ils ne peuvent pas parce que leur organisation ne veut pas ou ne peut pas le faire. Nous constatons que les gens qui font cela maintenant comprennent qu'il s'agit avant tout d'intégrer ce tiers dans ce qui est presque une organisation parallèle.
Cette organisation se contentera de réaliser des projets agiles et c'est là que Gartner parle de « bimodal ». Cela signifie que certaines des choses sur lesquelles vous travaillerez, vous saurez quel est le problème et tout ce que vous aurez à faire est de l'exécuter.
Dans d’autres, vous ne saurez pas quel est le problème mais vous saurez à quoi ressemble la solution. Dans cette deuxième série de projets, vous devez faire preuve d'agilité, vous formez donc des équipes de personnes qui souhaitent faire preuve d'agilité pour résoudre ces problèmes. C'est notre conseil typique et nous trouvons qu'il est très efficace. À partir de là, vous le laissez pousser de manière organique. DevOps, c’est pareil.
Q: Selon vous, quelle est la première chose qu'un responsable informatique devrait prendre en compte lors de la mise en œuvre d'un système DevOps/agile ?
La première chose à laquelle il faut penser est que vous ne pourrez pas tout faire DevOps demain. Identifiez les projets les plus non linéaires. C'est là que nous commençons à parler de choses comme 'la start-up lean" où vous faites des expériences pour déterminer quel est le problème.
Toutes les entreprises ont ces domaines, alors prenez les plus extrêmes et essayez d'y faire ces choses.
L'autre chose à laquelle nous voulons qu'ils réfléchissent est l'aspect commercial, car il faut le faire en partenariat avec l'entreprise. Il s’agit d’un autre grand défi culturel pour de nombreuses organisations. Tout comme vous choisissez les développeurs avec le bon état d'esprit - peut-être en fonction de leurs compétences - parce que c'est plus il est important qu'ils soient orientés agile plutôt que d'avoir travaillé avec ce logiciel avant. Du côté des entreprises, c'est la même chose. Vous devez sélectionner les projets pour lesquels l'entreprise comprend qu'elle doit travailler différemment avec l'informatique pour obtenir ce dont elle a besoin.
L'autre chose que j'encourage les gens est la suivante: ne proposez pas une feuille de route dans laquelle vous allez être agile de huit % d'ici cette date et 10 pour cent à une autre date et 25 pour cent d'ici la fin de l'année prochaine et alors nous serons 75 pour cent agile. Ne pensez pas cela parce que cela ne se passera pas de cette façon.
Il faut être bio. Cela va être utilisé dans les poches et tout à coup, la mentalité de l'entreprise va changer. Les gens diront: « Hé, ça marche mieux » – et tout à coup, tout le monde veut que son projet soit agile.
Q: Que prédit Gartner pour l’Agile et le DevOps ?
Ma première prédiction est que l’agilité deviendra la méthode majoritaire de développement logiciel d’ici 2018. L'autre est directement lié à Le projet Phénix, et il dit que d'ici 2020, nous allons regarder en arrière et dire que ce que traverse l'informatique est exactement ce que l'industrie manufacturière a vécu dans les années 80. L’adoption du Lean et ce que Toyota a vécu C'est exactement ce que DevOps signifie pour l'informatique. Ce sera tout autant une transformation pour lui.
En savoir plus:
Qu’est-ce que DevOps et pourquoi est-ce important ?
Puppet Labs et Dell travaillent ensemble sur un logiciel de gestion
Chef vise à créer la recette secrète du succès DevOps