Cette
semaine dans le cadre des rencontres d'affaires mobilité et digitale de
ROOMn, s'est tenue une table ronde pour faire le point sur la mise en
oeuvre de DevOps dans les entreprises. Dans une salle pleine et
très participative, ce fut l'occasion de faire le point sur les
questions pratiques que se posent encore les directions SI et marketing
sur DevOps et sur l'agilité en général, des démarches indispensables pour toute transformation digitale.Gaettan Falletta, qui participe à la stratégie Internet des Objets d'Airbus, Philippe Bedu, chargé de mission à la DSI groupe d'EDF et moi-même en charge de la Stratégie Digitale de Suez Smart Solutions, étaient interrogés par Olivier Bouzereau qui animait le débat avec la salle.
DevOps: une étape dans l'agilité de l'entreprise
De plus en plus de projets digitaux mettent en oeuvre une approche DevOps pour développer avec un cycle court et mettre en production avec le même rythme, par exemple hebdomadaire.Mais mettre en production toute les semaines si aucun client n'utilise chaque version livrée ne sert pas à grand chose, à part à dire qu'on travaille en mode agile. L'agilité n'a de pertinence que sur l'ensemble de la chaîne, donc en amont pour la production de besoins avec des cycles itératifs courts, et en aval avec la validation régulière des développements (plus rapide que le rythme choisi) et l'utilisation après mise en production de l'application par de "vrais utilisateurs".
D'ailleurs sans vouloir dévaloriser le travail d'une équipe dite de maîtrise d'ouvrage pour valider les nouvelles fonctions, la seule validation qui compte est celle des utilisateurs qui, en conditions opérationnelles réelles, vont utiliser ces nouveaux services, se les approprier voire en imaginer de nouveaux usages auxquels l'entreprise n'avait pas pensé au départ.
DevOps a t-il vocation a être la règle pour l'ensemble des projets d'une DSI ?
Les retours d'expérience d'Airbus et EDF montrent qu'une partie uniquement des projets sont gérés avec cette approche et que les objectifs sont au mieux de l'utiliser pour 20% à 50% des projets. Le "cycle en V" a donc encore de beaux jours devant lui ! Par exemple quand on veut travailler avec un prestataire unique au forfait. Le forfait est difficilement compatible avec une approche agile puisque le besoin n'est pas totalement spécifié au départ et donc ne peut faire l'objet d'un engagement ferme pour sa réalisation.Pour GreenSI, pour les projets de transformation numérique, on assiste à une augmentation du nombre de développements spécifiques pour développer des plateformes de plus en plus différenciantes. DevOps est totalement adapté aux développements spécifiques. On peut donc penser que cette approche pourrait représenter à terme 100% des développements spécifiques liés à la transformation digitale, principalement dans la mobilité et les plateformes numériques pour les clients.
Est-ce que DevOps c'est mieux que le cycle en V?
L'agilité n'est pas la panacée si l'entreprise n'est pas prête ou si la MOA ne comprend pas les fondamentaux de la démarche. Au contraire, une démarche agile ou DevOps peuvent être un risque d'échec des projets. La bonne pratique exposée consiste à définir les critères à respecter avant de partir tête baissée dans un projet en mode agile. Trois de ces critères discutés lors de cette table ronde ont été :- Le besoin d'arriver rapidement en production avec quelques services puis d'itérer avec de nouveaux services.
- La confiance établie entre ceux qui établissent le besoin, développent, gèrent la production et les utilisateurs finaux.
- La possibilité de supprimer les validations formelles longues, notamment auprès d'instances externes à l'entreprise.
Un projet agile amène plus vite UNE PARTIE des fonctionnalités (ex. "la patinette") en production. Il permet d'itérer et donc de s'améliorer, pour avancer vers un service de plus en plus adapté à l'utilisateur. C'est pour ces raisons que l'on doit choisir DevOps, et cela demandera une énergie au quotidien.
Une maîtrise d'ouvrage n'ayant pas cette énergie, ou trop prise dans son quotidien opérationnel, ne sera pas à l'aise dans un projet agile, et l'échec sera probable. En premier lieu, ce sera le rejet de la méthodologie de façon plus ou moins affichée, notamment le rejet des outils collaboratifs transverses pour revenir à des outils individuels et des documents, et parfois par la fin du projet lui même. En revanche si le projet est adapté à l'agile, ses chances de succès seront multipliées par rapport à celles dans un cycle en V.
C'est cette confiance et cette compréhension mutuelle qui est à l'origine et à la base du rapprochement des "Dev" et des "Ops", puis avec l'agilité des métiers et des développeurs.
Alors quand un chef de projet veut tout contrôler car il croit (comme dans un cycle en V) que son rôle est d'être justement le "chef" du projet, vous savez que la méthode agile n'est pas adaptée et qu'un cycle en V frustrera moins les équipes.
De même, elle n'est pas adaptée quand on n'arrive pas à nommer un product owner UNIQUE, et quand chacun veut donner son avis ou tout contrôler de l'interface aux priorités des scrums. Ceci sachant d'ailleurs que le seul avis qui compte à la fin, c'est celui de l'utilisateur final et de sa perception de son expérience (utilisateur), le Saint Graal du succès digital.
L'approche DevOps suppose donc la maitrise d'un fonctionnement transversal pour les équipes techniques ET métiers, plus ou moins simple en fonction de la culture d'entreprise. Elle s'inscrit donc bien dans la transformation - changer de forme - digitale de l'organisation et dépasse largement le cadre de la DSI et des équipes SI.
DevOps, c'est la fin de la documentation ?
C'est vrai que les projets agiles ont des exigences plus faibles en matière de documentation. Le manifeste agile reconnaît la valeur de la documentation mais lui préfère un logiciel opérationnel.
Pour GreenSI, DevOps oblige en fait à se reposer la question de ce qu'est une documentation, de sa finalité et donc du format et du moment le plus a approprié pour la produire :
- À quoi bon faire des spécifications détaillées dans d'épais classeurs si les développeurs ne les lisent pas?
- Ne vaut-il pas mieux documenter son besoin pour qu'il soit compris par ceux qui vont le réaliser plutôt que par ceux qui l'écrivent?
- À quoi sert un cahier de recette quand les tests sont automatisés?
- À quoi sert une documentation d'installation quand on a le script du robot qui déploie en continu dans la minute les versions successives et gère les retours arrière ?
La France en avance sur DevOps !
Une enquête menée à l’échelle mondiale en partenariat avec CA Technologies révèle que 87% des organisations françaises considèrent les pratiques agiles et le DevOps comme essentiels à la réussite de leur transformation numérique.Une sélection d’indicateurs clé de performances (KPI) permet de mesurer l’impact du DevOps et les conclusions pour la France sont sans équivoques :
- Les pratiques agiles diminuent la durée de développement et de lancement de nouveaux produits de 24% (de 9,59 à 7,33 semaines) ;
- Le DevOps raccourcit le temps nécessaire pour le développement et lancement de nouvelles applications de 38% (de 13,43 à 8,27 semaines) ;
- Les pratiques agiles augmentent la productivité des employés de 44% ; le DevOps de 43% ;
Cela fait 3 ans depuis le premier billet de GreenSI en 2014 qui s'étonnait que le sujet DevOps très développé outre Atlantique, n'avait pas encore atteint les côtes françaises. Visiblement en 3 ans la France a commencé à adopter cette bonne pratique, et certains prédisent que 2017 sera l'année de la généralisation.
