Dans un précédent billet Industrialiser n’est pas automatiser, nous présentions les standards comme moteur de l’industrialisation, et base de l’amélioration continue. Voyons maintenant comment une équipe peut mettre en pratique ces principes.

Comment élabore-elle ses standards ? Comment les met-elle en application ?

Reprenons l’exemple de l’éditeur de logiciel de e-commerce, et de son équipe de développement. Pour rappel, l’équipe livre, toutes les 2 semaines, des fonctionnalités en mettant en œuvre Scrum.

Schéma en bazar

À chaque itération, le schéma de base de données évolue en fonction des besoins fonctionnels. Des tables, et des champs sont ajoutés, quelquefois renommés, ou même supprimés. Mais voilà, avec les différents environnements (développement, intégration, pré-production, production), c’est un peu le bazar. Et évidemment, pour ne rien arranger, les différentes versions de l’application n’attendent pas la même version de schéma.

Au démarrage, ou bien plus tard, il est fréquent que l’application plante, se plaignant de l’absence de telle table ou de tel autre champ. Il faut alors mettre en place la version adéquate du schéma. Faut-il alors recréer la base ? Faut-il altérer le schéma pour l’amener dans la version désirée ? Dans ce cas, quelle est la version effective de la base de données ? Inutile de dire que la manœuvre de rétablissement est terriblement chronophage. Inutile également de préciser qu’en recette, le client râle, et qu’il n’a pas tort. Et ça, l’équipe en est consciente.

Une pincée de standard maintenant

Elle est en plein apprentissage, et elle apprend vite. Ainsi, à cette occasion, elle décide de mettre en place ses standards (au sens lean du terme). L’équipe cherche des solutions pragmatiques et rapides, elle ne se fixe pas pour objectif d’éliminer tous les problèmes. Mais, réduire ne serait-ce que de 50 % les temps de résolution aura un impact très fort sur la crédibilité auprès du client, mais aussi la productivité. Une pierre, deux coups !

Au cours de la rétrospective (en jargon Scrum, le débriefing de l’itération), l’équipe décide d’un premier standard. Il s’agit simplement de versionner le schéma et de conserver les scripts dans le gestionnaire de version :

  • le script de création du schéma version 1,
  • et les scripts de modification du schéma de la version n à la version n+1.

L’équipe décide que ce standard prend effet immédiatement, et que le schéma actuel est la version 1. Pas de temps à perdre avec le passé ! Bénéfice immédiat ! Une itération engendre le plus souvent une nouvelle version du schéma, développement itératif oblige. Lors d’une itération, toute modification du schéma doit être scriptée, et adjointe dans le script de modification de schéma correspondante. L’activité de maintien du schéma devient une activité intégrée, dont les membres du projet sont tous responsables.

Des résultats tout de suite

Une itération plus tard, le standard est mis en œuvre comme prévu. Deux itérations plus tard, les problèmes de schéma sont 2 fois moins fréquents. À vue de nez ! Aux indicateurs précis, l’équipe a préféré la résolution des problèmes. Une fois les problèmes disparus, plus vraiment besoin de verser dans la statistique du ‘pas grand-chose’ !

Et ce n’est pas fini

Forte de ses premiers succès, l’équipe ne s’arrête pas en si bon chemin. Elle décide, au cours de l’itération, de stocker le n° de version du schéma dans une nouvelle table. Le script de mise à jour refuse de se lancer si le n° de version n’est pas le bon. Quelques jours plus tard, l’équipe fait quelques modifications mineures sur l’application, afin qu’elle ne fonctionne qu’avec la bonne version du schéma. Lors de l’itération suivante, une autre modification mineure permet à l’application de produire une page d’erreur rustique qui apparait en cas de problème de version. Sans le savoir, l’équipe applique le poka yoke, dans le jargon lean, un simple petit truc qui empêche de faire une erreur.

Deux itérations plus tard, l’équipe s’attaque à la migration des données lors du changement de version du schéma. Mais ça, c’est une autre histoire.

Petit pas pour l’équipe, grand pas pour le projet

Au travers de ces expériences, l’équipe développe des formes nouvelles de satisfaction, celle de faire mieux et plus vite, celle d’avoir en main le destin du projet, celle de voir grandir la satisfaction de son client.

L’équipe découvre aussi qu’un petit pas bien assuré vaut bien plus qu’un grand bon dans le vide. L’équipe est fière d’elle, et elle gagne aussi en humilité. Effectivement, on aurait pu confier la conception d’une méthodologie de gestion des schémas à quelques architectes. Aussi talentueux soient-ils, on aurait obtenu une belle documentation dans 3 mois, et jamais vraiment mise en œuvre par les équipes, parce qu’imposé d’en haut.

Finalement, l’équipe redonne son vrai sens à un mot terriblement galvaudé : ‘pragmatisme’. Elle recherche des gains immédiats et durables, et tente constamment de s’améliorer.

Billets sur le même thème