fra

Le nouveau monde : Que signifient Agile et DevOps pour ITSM et ITIL® ?

Par Charles T. Betz et Christoph Goldenstern

Il faudrait vivre sous une roche pour ne pas avoir remarqué l'impact d'Agile et de DevOps sur tout ce qui touche à l'informatique ces derniers temps. Des startups aux plus grandes entreprises de la planète, Agile et les techniques connexes transforment la façon dont l'informatique est planifiée, construite, fournie et exploitée.

Qu'est-ce que cette transformation signifie pour les professionnels de la gestion des services informatiques et leur cadre privilégié - ITIL ? Beaucoup. DevOps a changé la donne de manière inattendue. Par exemple, on a longtemps pensé que le changement était l'ennemi de la stabilité, et les organisations ont donc opté pour des versions peu fréquentes et "bien planifiées", ce qui n'a jamais semblé fonctionner aussi bien.

Puis est arrivé le DevOps. "10 déploiements par jour chez Flickr" a été le premier cri de ralliement en 2009. Ses systèmes devaient sûrement tomber en panne en permanence ? Non, ce n'est pas le cas. Lorsque la livraison continue est bien comprise et exécutée correctement, la stabilité des systèmes s'améliore. Seulement pour les startups de la Silicon Valley, non ? Au cours du mois de septembre 2016, Barclays Bank a déclaré que plus ses 800 équipes d'application Agile se déploient fréquemment, plus ses services sont stables. À toutes les échelles, il est clair que les changements plus petits et plus incrémentiels apportés aux systèmes complexes présentent moins de risques et favorisent la stabilité. En outre, le retour rapide de ces petits changements incrémentiels permet une nouvelle culture d'apprentissage basée sur le test d'hypothèses en apportant (en termes de Lean Startup) des produits minimum viables rapidement au client.

Que se passe-t-il et qu'est-ce que cela peut signifier pour une entreprise établie par rapport à une organisation en démarrage ? Une façon de comprendre l'impact d'Agile et de DevOps est d'utiliser un modèle de mise à l'échelle ou d'"émergence". Le problème avec les cadres, tels que ITIL et COBIT, est qu'ils sont présentés à l'échelle de l'entreprise. Le cadre peut indiquer qu'il doit être adapté aux besoins d'une entreprise particulière, mais la manière exacte de le faire est souvent laissée aux consultants. Ce qui fonctionne pour une grande entreprise peut ne pas avoir de sens pour une start-up. Dans son livre Scaling Up, Verne Harnish observe qu'il existe des regroupements naturels d'entreprises à certaines tailles :

  • 1-3 employés
  • 8 à 12 employés
  • 40-70 employés
  • 350-500 employés
  • 2 500 à 3 500 employés

Le processus de mise à l'échelle peut nous aider à comprendre les débats actuels dans le secteur, tels que "DevOps contre ITIL". Pensez aux processus informatiques en ces termes. Recommanderiez-vous un processus complet de gestion du changement pour une entreprise de 10 personnes ? Pourriez-vous gérer une entreprise de 3 000 personnes sans en avoir un ? À quel moment en introduiriez-vous un, et pourquoi ? Quels autres processus introduiriez-vous et quand ?

Agile fonctionne bien dans des contextes plus petits. Il est axé sur l'équipe, et les entreprises de toutes tailles réalisent de plus en plus que c'est dans l'équipe collaborative que la valeur est produite. Des recherches bien établies ont montré que les cultures collaboratives sont plus performantes que toutes les autres cultures (y compris les cultures compétitives). Une entreprise de 10 personnes est une équipe, mais une entreprise de 50 personnes doit se considérer comme une "équipe d'équipes". La question est de savoir comment fournir "la colle" à toutes ces équipes pour ne pas perdre l'alignement. Plus nous sommes "lâchement couplés" (selon les termes de la culture d'ingénierie de Spotify), plus nous avons besoin d'être "étroitement alignés" avec des approches communes qui facilitent la collaboration et la résolution des problèmes.

Cela peut sembler évident, mais à mesure que les entreprises se développent, elles se spécialisent en fonction de leurs fonctions :

  • Marketing
  • Recherche et développement
  • Ventes
  • Opérations et service
  • Back office (finances, RH, informatique)

En outre, il existe des sous-spécialités au sein de chaque fonction (par exemple, l'informatique se spécialise davantage en équipes chargées des applications et de l'infrastructure ; les équipes chargées de l'infrastructure se spécialisent en serveurs, stockage, mise en réseau, NOC 24 x 7, etc.)

L'informatique s'organise comme un "preneur de commandes", tant dans sa relation avec l'entreprise qu'en interne. Les équipes chargées des applications soumettent des "tickets" à l'équipe chargée de l'infrastructure pour obtenir les ressources nécessaires, par exemple. Ce modèle peut produire des systèmes et des services informatiques raisonnablement stables, mais ils sont souvent lents à livrer et à changer. Les silos fonctionnels et la réflexion sur les processus de bout en bout sont la norme, ce qui est un peu ironique car ce n'est pas ce que préconisent des cadres comme ITIL.

Aujourd'hui, la transformation numérique remet en question et perturbe les silos. Comme les produits destinés au marché contiennent de plus en plus de technologies de l'information, l'informatique de "back-office" converge avec la recherche et le développement et les opérations et services généraux. Maintenant que l'informatique est essentielle à la survie d'une entreprise, on lui demande d'être plus réactive aux besoins du marché. La stabilité est toujours nécessaire, mais les systèmes stables qui ne répondent pas aux besoins du marché en constante évolution sont sans valeur.

Les silos fonctionnels nécessitent des transferts. Ces transferts entraînent des retards et ralentissent la réactivité. Les silos fonctionnels ont tendance à développer une attitude "nous contre eux" à l'égard des équipes qu'ils desservent et auxquelles ils demandent des services. C'est pourquoi les méthodes agiles favorisent les équipes polyvalentes : comme le dit Marty Cagan dans son livre influent, Inspiré : Comment créer des produits que les clients adorent, l'équipe doit au minimum être capable d'amener un produit vers trois qualités nécessaires :

  • A-t-il de la valeur ?
  • Est-il utilisable ?
  • Est-ce faisable ?

Une équipe capable de produire des résultats conformes à ces trois dimensions peut être qualifiée de "pile complète". Scrum et d'autres méthodes Agile soulignent à plusieurs reprises que l'équipe doit être capable de fonctionner en général, par elle-même, avec un minimum de dépendances et de blocages externes.

Une autre pratique courante est "vous le construisez, vous l'exécutez". Il s'agit d'une bonne pratique et d'un grand changement par rapport à l'époque du "throw it over the wall and run", où les développeurs n'assumaient guère la responsabilité d'écrire un logiciel qui pouvait réellement être exécuté en production. Essentiellement, l'accent passe d'un "modèle d'usine" informatique verticale à une approche de "gestion horizontale". Dans ce cas, l'équipe est responsable de bout en bout, y compris de certaines des disciplines ITIL les plus traditionnelles comme la gestion des incidents et des problèmes.

Comme l'a dit Werner Vogels, directeur technique d'Amazon, "donner aux développeurs des responsabilités opérationnelles a considérablement amélioré la qualité des services, tant du point de vue du client que de la technologie". Désormais, les développeurs "portent de plus en plus le pager" et sont incités à écrire des logiciels stables, évolutifs et fonctionnant bien, en plus de répondre aux attentes de l'utilisateur en matière de fonctionnalité.

Qu'en est-il d'ITIL ?

Il a été démontré que ces approches fondées sur le travail d'équipe fonctionnent remarquablement bien, et c'est pourquoi les organisations, grandes et petites, du monde entier s'empressent d'adopter Agile et DevOps.

Cependant, au niveau de l'"équipe des équipes", c'est-à-dire au niveau des grandes organisations, la communication et la collaboration doivent traverser les équipes. Nous pouvons essayer de minimiser la nécessité d'une telle communication, mais à un moment donné, comment savoir si deux changements n'entreront pas en collision ? Les processus inter-équipes visant à coordonner et à synchroniser l'activité, doivent se concentrer rapidement sur les éléments d'information essentiels aux opérations et qui fournissent un contrôle de qualité minimal, mais essentiel (par exemple, l'énoncé de l'incident ou du problème).

Une approche commune de la résolution des problèmes au sein des équipes élimine certaines des barrières entre la gestion des incidents, des problèmes et des changements. Lorsque tout le monde "parle le même langage de résolution et d'exécution des problèmes", cela minimise le "temps mort" des activités inefficaces ou répétitives et améliore la façon dont les données sont utilisées et partagées.

Gestion du changementt

Comme ITIL préconise depuis longtemps un processus de changement rigoureux, il est devenu un obstacle pour de nombreux défenseurs d'Agile et de DevOps. Pourtant, le ralentissement du débit des changements (ce que tend à faire la gestion des changements ITIL) n'a pas été corrélé à la stabilité des systèmes.

Maintenant, pour être juste envers ITIL, les mises à jour continues d'une application ou d'un service dont la plate-forme est stable en général, sont considérées comme des changements "standard" ne nécessitant pas de discussion ou d'approbation. Rien dans ITIL ne l'interdit. Cependant, dans de trop nombreuses organisations, la réalité est de "faire attendre les développeurs" en utilisant une cadence de contrôle des changements d'une ou deux semaines.

Lorsque les ingénieurs d'exploitation sont chargés d'apporter les changements nécessaires à la production, un retard de changement peut être dû à une trop grande quantité de travail en cours et non à un manque de synchronisation entre les équipes (comme l'utilisation d'une réunion bihebdomadaire du comité d'approbation des changements pour évaluer les risques). Cependant, étant donné que de plus en plus d'équipes fonctionnent sur le principe du "vous construisez, vous exécutez", le fait que les opérations mettent en œuvre les changements de production est considéré comme une absence de valeur ajoutée. Même la préoccupation fréquemment citée de la "ségrégation des tâches" s'est estompée. (Voir le DevOps Audit Defense Toolkit, co-écrit par l'évangéliste DevOps Gene Kim et l'auditeur informatique James DeLuccia).

Au-delà de la gestion du changement

Au-delà de la gestion du changement, comment les équipes Agile et DevOps ont-elles vécu ITIL ? Les équipes qui gèrent les opérations, y compris la fonction de help desk et les centres 24 x 7 (qui sont deux services différents), ont tendance à adopter la formation et la terminologie ITIL et à avoir des équipes de service fonctionnant en silos fonctionnels.

Ces silos sont défendus par des commentaires tels que "nous n'avons pas assez de personnel pour donner à chaque équipe de développement son propre personnel d'exploitation ou ses ingénieurs d'infrastructure !" Mais cela passe à côté de l'intérêt des pratiques DevOps modernes basées sur le cloud et néglige des aspects importants de la gestion des services informatiques. ITIL préconise la mise en place de catalogues de services, qui sont souvent utilisés pour "mettre en avant" les services d'infrastructure. Historiquement, un processus de gestion des demandes de service prend en charge ces services, souvent avec un travail manuel (par exemple, un ingénieur analysant une demande de nouveaux serveurs).

Les approches du cloud et des micro-services sont en train de changer le visage de la gestion des demandes de service avec un front-end cohérent, basé sur un catalogue et un service entièrement automatisé. Qu'est-ce que le portail Amazon ou Azure Cloud sinon un catalogue de services avec un haut degré d'automatisation ? Le libre-service et l'automatisation renforcent les équipes fonctionnelles et libèrent les équipes d'infrastructure de la plupart des services de conseil et d'ingénierie à la demande, afin qu'elles puissent se concentrer sur la création et le maintien d'une infrastructure partagée en libre-service.

Passage à l'échelle de l'entreprise

Que se passe-t-il lorsqu'un état d'esprit Agile est amené à l'échelle d'une véritable entreprise ? Au-delà de la nécessité de coordonner une "équipe d'équipes", des problèmes de gestion des risques, de gouvernance et autres se posent. La continuité des activités, la gestion des problèmes et la réponse aux incidents majeurs deviennent des préoccupations essentielles. Selon Kepner-Tregoe, la gestion des incidents majeurs, en particulier, exige des compétences spécialisées qui contribuent à protéger l'entreprise contre les dommages et les pertes catastrophiques. Cette "capacité d'intervention" pour arrêter l'hémorragie lorsque des pannes majeures se produisent nécessite des spécialistes possédant à la fois des compétences exceptionnelles en matière de résolution de problèmes et des compétences en matière de facilitation et de communication, en raison de l'environnement naturellement sous haute pression et de la pléthore de parties prenantes à satisfaire.

En outre, les organisations ne peuvent pas se permettre, dans cet environnement en évolution rapide, de continuer à résoudre les mêmes vieux problèmes. L'introduction des principes Agile et DevOps dans une organisation ayant un arriéré insurmontable de problèmes ouverts (et, par conséquent, un volume croissant d'incidents) est une entreprise risquée. Pour qu'Agile et DevOps réussissent, les organisations doivent commencer à prendre la gestion des problèmes au sérieux et consacrer des ressources à la recherche de la cause profonde des problèmes. L'intégration de la gestion des problèmes dans le backlog de l'équipe, au même titre que les nouvelles "histoires" des utilisateurs, est une meilleure pratique émergente.

D'un autre côté, l'un des risques de la mise à l'échelle est que l'organisation mette en œuvre tellement de processus que l'expérience de l'équipe, si importante, est perturbée. Des processus multiples, davantage motivés par le besoin d'administration/documentation que par la valeur de leurs résultats, peuvent bloquer le travail de l'équipe, ce qui nuit à sa cohésion et à sa capacité à fournir de la valeur au client. Ce type de dégradation des performances est également un risque pour l'entreprise, peut-être le plus important de la mise à l'échelle.

En conclusion

Les pratiques ITSM ont beaucoup à offrir au nouveau monde Agile/DevOps. Elles offrent un alignement autour du langage et des pratiques éprouvées. Les catalogues de services, la gestion des changements, des incidents et des problèmes sont tous pertinents. Les organisations doivent cependant se garder d'utiliser l'ITSM comme une justification pour mettre l'accent sur la structure et les processus au détriment des résultats des services, perdant ainsi une partie de l'intention initiale de cadres comme ITIL. Une approche centrée sur les services et les résultats pour l'utilisateur fait depuis longtemps partie de la philosophie de l'ITSM, et les gestionnaires de services qui gardent cet objectif et ont la capacité d'appliquer une "réflexion rapide sur la qualité" continueront à bien se porter. En fin de compte, il s'agit de l'expérience du client et de son moment de vérité quotidien face à vos systèmes numériques, tant en termes de qualité que de stabilité.

À propos de Kepner-Tregoe

Kepner-Tregoe est le leader de la résolution de problèmes. Depuis plus de six décennies, Kepner-Tregoe a aidé des milliers d'organisations dans le monde entier à résoudre des millions de problèmes grâce à une analyse des causes profondes et à des compétences décisionnelles plus efficaces. Kepner-Tregoe s'associe aux organisations pour réduire considérablement les coûts et améliorer les performances opérationnelles grâce à
des services de formation, de technologie et de conseil en matière de résolution de problèmes.

À voir aussi

Déplacer vers la gauche ? Non, "Shift Down" pour le succès des services de soutien.

Le rôle stratégique du soutien à la clientèle dans la maximisation de la valeur actionnariale

Nous sommes experts en :

Nous contacter

Pour tout renseignement, information complémentaire ou un devis