Lean management et automatisation

Comme nous l'avons montré dans le numéro E-3 de février 2019, page 66, l'idée DevOps a de nombreux prédécesseurs et modèles qui ont surtout influencé le C (Culture), le M (Measurement) et le S (Sharing) dans le concept Calms. Mais les aspects du Lean Management (L) et surtout de l'automatisation (A) sont au moins aussi importants.

Alors que dès les années 1990, de nouvelles approches ont vu le jour pour développer des logiciels plus rapidement et de manière plus flexible, il a fallu attendre 2009 pour que tous les éléments de Calms soient réunis dans un concept.

L'objectif de cette approche est de rendre la collaboration entre le développement et l'exploitation informatique aussi agile et flexible que le développement lui-même : Depuis les premiers DevOps-Days à Gand, les expériences du développement et d'autres secteurs de l'entreprise sont rassemblées dans le concept DevOps, tel qu'il est présenté dans le manuel DevOps.

Changement de culture à tous les niveaux

La mise en œuvre de DevOps exige beaucoup des personnes concernées. Tous doivent changer leurs attitudes, leurs attentes et leurs méthodes de travail. Ainsi, à l'époque de DevOps, l'ère des grands projets prestigieux est révolue.

En revanche, la gestion économique d'un projet de développement passe au premier plan. La question de base est inversée : au lieu de se demander combien le projet va coûter, il s'agit de définir quelles fonctionnalités nouvelles ou améliorées du logiciel peuvent être réalisées pour un budget donné et gérable.

Une fois la réponse obtenue, la direction doit s'en contenter et faire confiance aux personnes impliquées dans le projet pour qu'il s'agisse d'objectifs réalistes. En même temps, il faut renoncer à un contrôle des détails venant d'en haut.

"Ce qui compte du point de vue de la gestion, c'est uniquement le résultat par rapport au plan, pas le contrôle des étapes individuelles. C'est ce qu'on entend par lean dans le concept DevOps. C'est à ce changement de perspective que doivent se soumettre aussi bien les top managers que les responsables des départements spécialisés, qui dépendent tout particulièrement de leurs collègues de l'informatique".

recommande James Roberts, CTO chez Basis Technologies.

Pour les release managers aussi, cela représente un grand changement. Ils ne tirent plus leur réputation de la présentation et de la gestion de grands chantiers, mais du fait qu'ils mènent à bien de nombreux petits projets, chacun uniquement pour des groupes d'utilisateurs sélectionnés dans les départements spécialisés.

Comme les projets individuels sont gérables, leur conception du rôle doit évoluer de celui de chef à celui de coach, de motivateur et d'entraîneur. Ils doivent également veiller à ce que la composition de l'équipe reste stable dans le temps.

L'esprit d'équipe ne naît pas seulement de l'orientation vers un objectif commun, mais aussi de relations fiables et confiantes entre les membres de l'équipe. Comme les grands projets stratégiques dans le monde DevOps sont divisés en de nombreux petits projets détaillés conçus de manière itérative, cela est structurellement possible.

Les membres de l'équipe doivent quant à eux être prêts à renoncer un peu à leur spécialisation et à partager leurs connaissances avec tous les membres de l'équipe. Ce n'est qu'ainsi que la compréhension des défis des uns et des autres peut grandir.

Ce n'est qu'en échangeant au sein de l'équipe que les développeurs apprennent les problèmes que leurs artefacts posent aux administrateurs de serveurs, de stockage et autres, tant pour la mise à disposition de l'environnement de test approprié que pour le transfert des modifications dans l'environnement de production.

Ce "partage" institutionnalisé (S), au-delà de la pensée et des frontières en silo, est l'aspect qui crée la confiance par la compréhension et pose les bases de la standardisation : Standardisation de l'approche, mais aussi des outils avec lesquels on travaille.

En comprenant comment un environnement de test fonctionne exactement et pourquoi les collègues de l'entreprise ont choisi celui-ci plutôt qu'un autre, les développeurs peuvent éviter de nombreuses réparations et risques lors de la mise en production ultérieure.

Cela correspond exactement à l'une des idées centrales de la méthode de développement agile Scrum, selon laquelle les équipes interdisciplinaires sont mieux et plus rapidement en mesure de produire de la nouveauté et de la qualité.

Cette double standardisation est la condition préalable à l'élément essentiel de DevOps qu'est l'automatisation (A). En effet, seul un environnement standardisé pour le monitoring, les tests et l'assurance qualité peut être mis à disposition en tant que self-service, avec lequel les développeurs peuvent travailler de manière autonome.

S'ils veulent tester, lors d'une modification de code, si celle-ci offre effectivement la nouvelle fonction souhaitée et quel est son impact sur l'ensemble du système, ils ne doivent plus attendre l'équipe d'exploitation, mais peuvent passer directement à l'action.

De son côté, l'exploitation informatique peut se concentrer pleinement sur l'assurance qualité des modifications réunies dans une version et sur leur mise en œuvre dans la production.

Enfin, pour que l'interaction entre le développement et l'exploitation soit continuellement améliorée, la mesure (M) des paramètres doit également être automatisée.

Il s'agit par exemple d'évaluations de la vitesse et de la ponctualité ou d'informations sur la qualité, comme le nombre d'erreurs détectées et leur évolution dans le temps.

Accéléré vers SAFe SAP

C'est le changement culturel qui entraîne le changement structurel, et non l'inverse. Au contraire, ce sont généralement les initiatives des développeurs concernés et de leurs collègues dans l'entreprise qui sont à l'origine de la révolution DevOps, à la manière d'un mouvement de fond.

C'est ce que montrent régulièrement des études, comme par exemple le 2018 State of DevOps Report. Ces pionniers ont d'autant plus de succès que la tâche qu'ils entreprennent est gérable et urgente du point de vue de l'entreprise ou d'un service spécialisé important.

Les clients existants de SAP peuvent, à ce stade, recourir au concept Accelerated SAP, qui décrit déjà le travail agile à la Scrum. Une fois qu'ils ont pré-expérimenté la nouvelle culture et sa supériorité, ils peuvent et doivent impliquer la direction à différents niveaux et en faire des sponsors de la révolution DevOps.

Ce soutien d'en haut est décisif pour le succès. En effet, les équipes DevOps ne peuvent pas vivre dans deux mondes en même temps, ni travailler d'une part selon le modèle en cascade et d'autre part selon les méthodes agiles, les pertes dues aux frictions seraient trop importantes.

Cela signifie notamment que la direction libère les membres des équipes DevOps à constituer de leurs tâches actuelles. Ils doivent pouvoir se concentrer entièrement sur les nouveaux processus et éventuellement sur les nouveaux outils.

C'est ainsi que de plus en plus de domaines informatiques peuvent être convertis à DevOps. Les managers trouvent une description de leur nouveau rôle dans le cadre Scaled Agile for Enterprises ou SAFe de Scaled Agile, qui guide non seulement les équipes individuelles, mais aussi tous les niveaux de management vers DevOps.

La confiance et l'assurance sont des éléments clés, en particulier dans l'environnement SAP, où la méfiance envers DevOps est peut-être la plus grande en raison de la complexité et des interdépendances internes et externes des différents composants des environnements SAP.

Les développeurs et les administrateurs SAP dépendent plus que tout autre groupe de l'informatique d'entreprise non seulement de relations personnelles, mais aussi d'outils permettant d'instaurer cette confiance.

Ils ont besoin d'outils capables de reproduire de manière fiable toutes les dépendances et de tester sous toutes les coutures les nouvelles versions, y compris leurs effets sur les environnements de production.

Parmi ces outils, on trouve notamment des outils de test de régression automatisés. Les outils appropriés couvrent pratiquement tout l'environnement de production et fournissent donc des résultats si proches de la réalité que le code testé positivement peut être implémenté avec un risque fortement réduit.

C'est la condition préalable à la livraison de versions à intervalles rapprochés dans des environnements SAP productifs. Dans le jargon DevOps, cette chaîne de livraison est appelée Continuous Delivery Pipeline ou - dans le framework SAFE - Agile Release Train avec les étapes individuelles d'exploration, d'intégration et de déploiement.

Si des problèmes devaient toutefois survenir, comme des baisses sensibles de performance ou des erreurs fonctionnelles, de tels outils d'automatisation doivent en outre offrir la possibilité d'annuler la version sans interruption - comme les utilisateurs sont habitués à le faire dans le cloud.

Automatisation

Si la confiance dans l'automatisation du côté Ops fait défaut, l'exploitation est et reste le goulot d'étranglement qui empêche l'introduction de DevOps dans l'environnement SAP d'une entreprise.

Faut-il s'étonner que de nombreux clients SAP existants utilisent déjà aujourd'hui DevOps dans leur informatique, sauf qu'ils ne l'utilisent pas dans leur propre environnement SAP, mais dans des solutions tierces ?

Dans les environnements SAP, les outils d'automatisation jouent définitivement un rôle plus important que dans d'autres domaines. Plus encore : même si au début de DevOps, il y a la culture, l'automatisation dans les environnements SAP est tout aussi importante que celle-ci.