Au secours, il me faut 2 mois pour mettre en production !

Ces dix dernières années ont vu le développement incroyable des projets Agiles qui se sont généralisés à travers les DSI du monde entier. Que cela soit votre premier projet Agile ou que cela fasse des années que toute votre entreprise a terminé sa migration, le résultat est bien souvent le même, les projets Agile livrent très régulièrement de nouvelles versions applicatives.

Malheureusement une version livrée par l’équipe de développement n’est d’aucune utilité tant qu’elle n’est pas en production. Et c’est bien souvent là que les choses commencent à coincer…

Dans cet article en deux parties nous verrons tout d’abord les indices montrant qu’il y a un problème puis dans une seconde partie comment améliorer la situation.

Un problème ?

L’un de vos projets est passé en mode Agile et vous livrez toutes les 2 semaines ?
Félicitations !

Les utilisateurs ne voient rien arriver plus vite ?

Félicitations vous avez un nouveau problème !

Tout comme pendant des tests de performances la suppression d’une contention en révèle une autre, la même situation se produit à l’échelle d’un projet.

Voici quelques indices indiquant qu’il faut maintenant travailler sur les étapes en aval d’un projet :

Vous avez beau livrer plus fréquemment, les versions n’arrivent pas plus vite en production
MEP rime plus avec Mise en Problème que Mise en Production
L’infrastructure est très peu Agile: les projets attendent longtemps leur environnement ou des modifications sur celui-ci
Aucune communication entre les équipes projets et les équipes opérationnelles

Se rendre compte du problème est déjà un premier pas vers sa résolution. Regardons maintenant comment améliorer la situation.

Des solutions !

La première étape et la plus importante est de faire en sorte que les équipes de développement et les équipes opérationnelles communiquent régulièrement. Si le projet est d’importance, il est bon de détacher un exploitant à temps complet sur le projet. Dans le cas contraire des points de synchronisation hebdomadaires feront l’affaire et cela dès le début du projet.
L’idée principale est de réunir ces deux équipes sous le même but: faire en sorte de sortir rapidement et sûrement de nouvelles versions du produit.

Ensuite et suivant un principe bien connu, on ne peut améliorer que ce que l’on peut mesurer. La première étape sur la voie de la guérison est donc de recenser sur un tableau de post-its toutes les étapes suivant la livraison jusqu’à la mise en production et de faire estimer par le projet (équipe opérationnelle incluse!) la valeur de ces étapes par rapport à leurs coûts.
Cette technique, nommée Value Stream Map (VSM), fait apparaître très clairement les étapes coûteuses mais ne présentant que peu de bénéfices. C’est ces étapes ci qu’il faut optimiser en priorité.

Il arrive bien souvent que la VSM mette en exergue le fait que la mise en production ou l’installation de la plateforme sont les étapes les plus coûteuses du processus tout en étant de faible valeur. La meilleure façon pour améliorer ce point est d’automatiser. Cela permettra des déploiements plus rapides et avec moins d’erreurs.
Fort heureusement de nombreux outils remplissant cette fonctionnalité existent aujourd’hui et sont utilisés dans toutes les grandes entreprises. Citons par exemple Puppet, Ansible ou XL Release.

Une autre technique fonctionnant efficacement est d’appliquer la maxime « si c’est douloureux, faites le souvent ».
Si installer une nouvelle version tous les mois est problématique alors imposer une livraison toutes les deux semaines obligera à fluidifier le processus. Et il n’y a pas de limites supérieures, des entreprises telles que Facebook ou GitHub livrent des dizaines de fois par jour en production !

Ces solutions et bonnes pratiques (parmi bien d’autres) forment un mouvement qui se nomme « DevOps » et qui a pour but de faciliter les échanges entre les équipes de Développement (Dev) et les équipes Opérationnelles (Ops). De la même façon que les méthodes Agile aident au passage de l’idée au code, DevOps aide au passage entre le code et sa mise en place en production afin de délivrer la valeur attendue par le client.

De très nombreuses entreprises utilisent ces principes afin de fluidifier le passage de l’application venant des équipes Agile vers la production. Pourquoi pas vous ?

Si vous souhaitez en savoir plus, n’hésitez pas à consulter le Techtrends DevOps entièrement dédié à ce sujet:

Commentaire

5 réponses pour " Au secours, il me faut 2 mois pour mettre en production ! "

Published by Anas , Il y a 6 ans

Pour les projet java, JNDI est votre amis :-)
Published by Simon Pierre Nolin , Il y a 6 ans

Merci pour cet article qui fait étonnamment écho au mien (http://www.airmis.com/au-secours-agilite/) mais donne la vision « étude » de ce problème.
A votre disposition pour échanger sur nos visions!
Published by Gilles Perreymond , Il y a 5 ans

Il est vrai que le goulet d’étranglement des mises en productions/recettes n’aide souvent pas les études à voir l’intérêt et les gains de productivités des managements de projets en agiles.

J’adore particulièrement :
« si c’est douloureux, faites le souvent ».

Une approche diaboliquement efficace :)
Published by soufiane , Il y a 4 ans

Pouvez vous uplaoder a nouveau le fichier http://techtrends.xebia.fr/techtrends-xebia-devops.pdf en ligne ?
Published by Anne Beauchart , Il y a 4 ans

Bonjour Soufiane,

Le TechTrends DevOps est toujours disponible en téléchargement ici : http://www.xebia.fr/data/techtrends/techtrends-xebia-devops.pdf
Tous les autres TechTrends sont à retrouver sur http://www.xebia.fr/livresblancs.html.

Cordialement

Un problème ?

Des solutions !

Commentaire

Laisser un commentaire Annuler la réponse

Nous recrutons