Clotaire Renaud

Le SMED chez un éditeur de logiciel

Limiter le temps perdu lors du remontage d’un environnement de développement spécifique à un client c’est optimiser la TMA (tiers maintenance applicative). Tour d’horizon de la méthode SMED.

Parmi les pertes de temps courante, celle lié au « changement d’outil » est sans doute la plus facile à identifier. Le SMED est une méthode permettant justement d’améliorer le temps de cette étape cruciale.

Qu’est ce que le SMED « Single Minute Exchange of Dies » ?

Prenons l’exemple d’une usine fabricant de gâteaux qui passent régulièrement de la fabrication de madeleines à celle de cakes. Ce qu’on appelle « changement d’outil » n’est autre que le changement de moule incluant les opérations de nettoyage, de rangement, ... bref, toutes les étapes entre la dernière madeleine produite et le premier cake commercialisable.

Chez un éditeur de logiciel ou une agence, un développeur zappe de demandes en demandes parfois plusieurs fois par jour. Ce peut-être une perte de temps considérable s’il ne dispose pas d’un outillage efficace permettant de basculer son environnement de travail d’un projet client à un autre. En effet, ce dernier doit disposer d’un environnement de développement personnel incluant tout le paramétrage du client, qui peut-être contenu dans une base de données, encore dans des fichiers ou dans les deux.
Si l’usage d’un outil de versioning est acquit pour la plupart des entreprises, cette solution est rarement un outillage suffisant. Limiter les efforts d’un développeur pour maintenir un environnement fidèle à la production lui permet de se focaliser sur la résolution de tâches à valeur ajoutée.

Faire un diagnostique permet de mettre en évidence un problème qui n’était jusqu’alors qu’un sentiment sous-jacent.

Voici quelques questions à se poser pour un premier diagnostic.

Quel est la fréquence de changement de client ? Moins d’une fois par mois Une fois par semaine tous les jours plusieurs fois par jour
Vous arrive-t-il de fixer le développeur qui va travailler sur un projet sur le seul critère de l’environnement de développement Jamais rarement parfois souvent
En tant que chef de projet, vous arrive-t-il de vous dire que vous ou votre développeur travail sur un environnement obsolète ? Jamais rarement parfois souvent
Un développeur junior peut-il se débrouiller seul ou a-t-il besoin de recourir à un membre de l’équipe plus expérimenté ? Jamais rarement parfois souvent
Y a t il une procédure générique ou une procédure par client ? Une seule procédure de rare changements de temps en temps souvent
La procédure est-elle documentée et simple ? Jamais rarement parfois souvent
Un développeur ne peut pas accéder à plusieurs environnement client en même temps sans changer sa configuration ? Jamais rarement parfois souvent
Ces dernières semaines, combien de temps au maximum un développeur met il pour ajouter un nouvel environnement client ? Moins de 10 min entre 10 min et 1 heure entre 1h et 4h plus d’une demi journée

Lister ensuite les différences entre l’environnement de développement et celui de production et l’impact en regard.

Exemple :

L'environement de développement dispose

  • d'un certificat SSL autovalidé > La conséquence est que le retour des systèmes de paiements ne peut pas être confirmés.
  • d'une version mineur du langage de programmation différente > Pas d'impact.
  • d'une impossibilité d’envoyer des emails > Il est nécessaire de scruter les logs d'envoi d’email dans un fichier.

Bilan du diagnostique : Si vous avez une majorité de « souvent » dans vos réponses, un travail sur le SMED vous sera sans doute bénéfique.

Je vous propose désormais de lister toutes les opérations nécessaires au changement de client et indiquer la durée.

La forme la plus appropriée est de réaliser un Gantt à partir de la liste d’actions à réaliser.

Exemple :

  • Demander les droits sur l’accès FTP au chef de projet. Et attendre sa réponse.
  • Se connecter sur le FTP pour récupérer le zip des fichiers et de la base de données.
  • Dezipper les fichiers.
  • Lancer le remontage de la base de données.
  • Lancer un script de nettoyage de la base de données
  • Ajouter la configuration du serveur web et relancer le serveur.
  • Changer de version de langage PHP et relancer le serveur web.
  • Reconfiguration du domaine dans la base de données.
  • Réaliser la check-list de contrôle de la conformité de l’environnement.

Classer les étapes ci-dessus selon les catégories :

  • Externes (avant): actions placées dans le temps de préparation de l'intervention.
  • Internes : actions réalisées pendant le temps d'arrêt.
  • Réglage : actions réalisées pendant le démarrage (phase de réglage)
  • Externes (après) : actions reportées après l'intervention
  • Inutiles : actions que l'on peut supprimer en optimisant l'organisation ou les moyens matériels

Si vous souhaitez brainstormer en équipe pour optimiser le processus utilisez un tableau, des étiquettes avec de la colle repositionnable de longueur proportionnelle à la durée.

  • Placez sur le tableau les étiquettes avec les différentes actions.
  • Indiquez à l’aide de gommettes de couleur chaque famille d’action.
  • Optimisez ensuite votre processus en parallelisant ce qui peut l’être.
  • Regroupez les actions qui peuvent être réunies au sein d’un script qui serait lancé en amont c’est à dire en tâche de fond pour le développeur.

Cette méthode SMED s’applique à tous les changements. Nous avons vu ici le cas des changements d’environnement de développement client mais elle peut être appliquée aux mises à jour logicielle qui nécessite un arrêt de service.