Projets décisionnels : Il faut combiner Agile et DevOps

Qu’il s’agisse d’études de cabinets de conseil, où de simples constats en entreprises, beaucoup de projets de BI piétinent ou n'atteignent pas leurs objectifs. Alors que les promesses sont élevées, en terme de valeur créée par l’analyse de données, il semble difficile pour beaucoup de projets, de justifier a posteriori l’investissement en logiciel et en ressources.
Pour Stephen Brobst, les raisons sont nombreuses, et il tente de les lister :
- Les cycles de développement sont trop longs, et tiennent trop peu compte de l’avis et des besoins des utilisateurs d’affaires;
- Tenter de tout modéliser dans le cadre d’une architecture globale est une erreur, et cela ne permet pas de tenir suffisamment compte des besoins d’affaires, et surtout de leur évolution dans le temps;
- Pour tenter de répondre à tous les besoins, les développeurs BI embrassent trop large et construisent des “usines à gaz”;
- Les besoins d’affaires évoluent très vite, et de plus en plus vite. Les geler le temps du développement, conduit à livrer des solutions devenues inadaptées, et difficile à faire évoluer;
- Les projets d’intégration de données sont parmi les plus complexes développés dans les entreprises;
- Utiliser des ressources offshore pour réduire les coûts de développement est une bonne idée, mais c’est souvent incompatible avec l’agilité;
- Et surtout, les utilisateurs d’affaires n’ont pas confiance dans ce que les départements informatiques produisent, et dans les délais qui leur seront nécessaires pour livrer !

Même si la présentation est un peu caricaturale, Stephen Brobst résume ces antagonismes à une lutte de générations, qui se matérialise dans les tenues vestimentaires des protagonistes : il oppose les partisans du costume-cravate, et ceux de la simple chemise. Une comparaison amusante car Stephen Brobst intervient le plus souvent sur ce sujet lors des événements Teradata où seuls les “costume-cravate” sont invités, et où il est le seul à s’autoriser son éternelle chemise hawaïenne.

Le monde de l’informatique en entreprise serait donc binaire. D’un côté ceux qui détiennent actuellement les cordons de la bourse des investissements : ils lisent Decideo - je plaisante… quoique… - ils détestent prendre des risques, privilégient les vendeurs qu’ils connaissent bien et les gros éditeurs de logiciels, choisissent des technologies anciennes, éprouvées, et basées sur leurs compétences actuelles.
De l’autre, des jeunes moins vêtus : ils lisent aussi Decideo - ça j’en suis certain - ils recherchent en priorité des solutions open source, veulent travailler avec les dernières technologies disponibles, n’hésitent pas à prendre des risques, et même s’ils ne sont pas décideurs actuellement, ils aspirent à prendre rapidement part aux processus de choix.

Cette comparaison peu flatteuse bénéficie sans doute d’un second niveau de lecture, car les équipes de Teradata, en particulier du côté commercial et consulting, ressemblent encore aujourd’hui plus aux costume-cravate qu’aux jeunes en chemise hawaïenne. Un message subliminal que Stephen Brobst aimerait sans doute faire passer aux équipes.

Du point de vue méthodologique, les premiers sont cantonnés aux méthodes traditionnelles de gestion de projet (waterfall); les seconds sont adeptes des méthodes agiles.

Appliquée au décisionnel, l’opposition des deux méthodes est encore plus flagrante.
Les costume-cravate attendent que tous les besoins clients soient exprimés pour avancer, quand les jeunes porteurs de chemise sont à l’écoute des opportunités. Les premiers privilégient une approche de haut en bas, et la ré-utilisation des développements, quand les seconds partent des besoins des utilisateurs, et préfèrent du jetable pour être plus efficaces.
Les objectifs des premiers sont la prise de meilleures décisions, au niveau de l’entreprise; quand les seconds recherchent l’innovation.

Pour Stephen Brobst, les termes utilisés pour décrire leur organisations sont différents. Et il s’enflamme contre les BICC (Centres de Compétences en Business Intelligence). Pour lui, le terme de BI relève du passé, et se limite au reporting. Il faudrait aujourd’hui parler d’analytique. Et le terme de “compétences” souligne également le manque d’agilité et la capitalisation sur des technologies anciennes. Quant au terme de “centre”, il symbolise une centralisation, opposée à la collaboration moderne au périmètre évolutif.

Cette combinaison permet d’appliquer l’agilité tant au centre de développement qu’à la mise en production. DevOps est en effet, en résumé, l’application des méthodes agiles à la phase de test, et de passage en production d’une application.
Se limiter à du développement agile, c’est en effet se limiter à la moitié du chemin. Les applications sont développées rapidement, en interaction avec les utilisateurs. Mais cela bloque lors de leur mise en production. Et le bénéfice de l’agilité lors du développement est en partie perdu lors de la mise en production.
DevOps encourage la livraison d’évolutions rapides du projet, en se focalisant sur la valeur produite pour les utilisateurs.

En résumé, la méthodologie agile consiste à :
- donner plus d’importance aux personnes et aux interactions, qu’aux processus et aux outils;
- privilégier un logiciel qui fonctionne, à sa documentation;
- valoriser la collaboration avec les clients/utilisateurs, plutôt que la négociation contractuelle;
- et surtout accepter les changements et leur apporter des réponses, plutôt que de s’accrocher au suivi du plan initial.

Ce qui est résumé sur l’image ci-dessus : dans une méthodologie traditionnelle, les besoins sont figés; en face, les ressources et les délais sont estimés. Dans une méthodologie agile, les ressources et les délais sont fixes, et les fonctionnalités qu’il est possible de développer sont estimées.

Pour que cela fonctionne, le processus de développement doit donc être modifié :
- Les solutions doivent être développées par étapes, et chaque étape donne lieu à un livrable; Cela améliore la satisfaction des utilisateurs qui voient que des fonctionnalités à valeur ajoutée sont développées régulièrement;
- Chaque version intermédiaire répond à un besoin d’affaires précis; la collaboration dans les équipes est améliorée, tout comme leur productivité;
- Et les développements en cours sont présentés fréquemment à leurs futurs utilisateurs, afin de recueillir leurs réactions, et ce avant que chaque développement ne soit finalisé; Cela montre aux utilisateurs la capacité de l’équipe de développement à s’adapter à l’évolution de leurs besoins - accepter et comprendre que les besoins d’affaires peuvent évoluer rapidement et que les développements doivent suivre;
- La vitesse est privilégiée : des développements rapides, intégrés rapidement, et livrés rapidement; mais développement rapide ne signifie pas absence de qualité. Au contraire, les développements intermédiaires sont testés plus rapidement, et les erreurs sont détectées, avant qu’il ne deviennent compliqué de les corriger;
- Un planning de production à court terme, mis à jour fréquemment. Des mises à jour quotidiennes donnent de la visibilité aux utilisateurs, à chaque itération.

Selon Stephen Brobst, Teradata a fait évoluer ses méthodes de gestion de projets clients, et est en mesure d’appliquer maintenant cette combinaison Agile / DevOps à ses propres projets clients.

A la base de cette nouvelle méthode, la décomposition d’un projet en incréments. Chacun de ces incréments apporte une solution à un besoin d’affaires précis. Ainsi les cycles sont plus courts, et la valeur est démontrée aux clients plus rapidement. L’accent est beaucoup plus mis sur la satisfaction des attentes du client, que sur le confort de l’équipe de développement. Même en interne dans une entreprise, il s’agit d’appliquer le principe de la satisfaction client, et d’un département informatique au service de ses clients internes.
Tout cela n’est finalement que du bon sens. Depuis notre jeunesse, on nous a toujours expliqué que pour résoudre un problème qui semble trop complexe, il faut le découper en petits morceaux, et avancer pas à pas.
Bien sur, la méthodologie proposée par Teradata s’appuie sur Scrum. Ce cadre de développement agile précise comment les développements sont découpés en “sprints”, de petites étapes itératives, qui chacune donne lieu à un livrable, et surtout à une validation permanente par les utilisateurs.
Sans doute in fine, le temps de développement global est-il un peu plus long, mais il permet d’aboutir à une solution qui répond aux besoins. Trop de projets respectent peut-être le planning initial, mais leur solution est finalement inadéquate pour les utilisateurs, d’où l’insatisfaction et le sentiment d’échec présenté en introduction.

Autre composant de la méthode préconisée par Teradata, le “data driven design”. Plutôt que de tout embrasser au départ, il s’agit de se focaliser sur une partie des données, celles qui correspondent au besoin d’affaires traité, et de suivre l’intégralité de la chaîne de collecte, nettoyage, préparation, stockage, analyse. Puis de passer au jeu de données suivant.
Fini donc l’épais rapport qui détaille comment construire l’énorme entrepôt de données d’entreprise, qui finalement ne correspondra plus aux besoins une fois mis en place. On prend les données une par une, et on avance, encore une fois, pas à pas, besoin d’affaires par besoin d’affaires.

Mais c’est l’implémentation de DevOps qui représente la principale évolution méthodologique. “DevOps, c’est la collaboration entre les développeurs, et les gestionnaires opérationnels du système d’information, qui travaillent ensemble sur tout le cycle de vie applicatif, depuis la définition des besoins, jusqu’à la mise en production, en passant par le développement logiciel”, explique Stephen Brobst. Jusqu’à présent les équipes de mise en production attendaient qu’un développement soit parfaitement finalisé avant d’accepter de le mettre en production. On cumulait donc une méthode de développement agile, et une méthode de mise en production à l’ancienne. Pour le client, en bout de chaîne, seule la lenteur de mise en production était perceptible, effaçant les apports du développement agile qui la précédait.
Evidemment, les intentions des équipes de mise en production sont louables; elles ne veulent pas déployer des outils instables ou mal testés. Mais attendre n’est pas forcément la solution. Ainsi, Netflix, qui pratique le DevOps, a-t-il mis en place une équipe de choc, en charge de tester les développements, tout au long du processus, sans attendre la version finale. Ces développements sont soumis à tests intenses, permettant de faire corriger les erreurs tout au long du processus de développement agile.

Stephen Brobst suggère l’utilisation de plusieurs outils pour supporter DevOps :
- des outils de gestion des versions : Jenkins, Travis, Teamcity
- des outils de gestion des configurations : Puppet, Chef, Ansible, Cfengine
- des outils d’orchestration : Zookeeper, Noah, Mesos
- des outils de virtualisation et de mise en conteneurs : Amazon Web Services, OpenStack, Vagrant, Docker
Mais il insiste aussi sur un des défauts de nombreux passionnés de technologie : utiliser ces outils ne signifie en rien que vous mettez DevOps en pratique; ce ne sont que des outils, ils sont utiles mais pas suffisants, et ne font que supporter la méthode.

Sur le papier, cela peut sembler simple. Il suffirait d’appliquer les recettes décrites ci-dessus. Mais les réticences sont fortes de la part des “costume-cravate” conscients que leur pouvoir s’appuie sur une méthodologie plus à leur service qu’au service des clients. Cela remet également en question les hiérarchies et les organisations. Stephen Brobst propose un certain nombre de questions que vous devrez garder à l’esprit :
- Comment allez-vous demander à vos managers d’exercer leur nouveau pouvoir de direction ?
- Comment les membres des équipes vont-ils devoir maintenant se comporter ?
- La transparence totale peut faire peur. Comment gérer cela ?
- L’organisation physique des bureaux peut devoir évoluer, pour faciliter le travail en équipe et l’application des méthodes agiles. Est-ce possible chez vous ?
- Qui sont les champions de cette nouvelle agilité ?
- Comment faire évoluer les signes extérieurs de l’organisation : titres, évolution de carrière, compétences, organigramme ?
- Comment ajouter une dose de plaisir au travail en équipe ?

Cette rupture entre les anciennes et les nouvelles méthodes, entre les anciennes et les nouvelles équipes… les anciennes et les nouvelles manières de s’habiller… est visible partout dans le monde, pas uniquement dans la Silicon Valley. En France comme au Canada, en Espagne comme en Amérique du Sud, il suffit de passer un peu de temps dans les conférences professionnelles. Les “costume-cravate” sont confortablement installés dans des conférences où l’on parle de Business Intelligence et de Big Data. Les “chemises” en sont absents. En revanche, les meetups, les hackathons, sont fréquentés par les plus jeunes générations, adeptes de Data Science. Pendant que les premiers réfléchissent à la “transformation digitale”, les seconds la mettent en oeuvre. Attention à la disruption !