Il y a deux choses qui sont partulièrement difficiles en gestion de projet : les relations humaines, et les relations au temps. Cette relation au temps se décompose en deux : le délais et la vélocité qu'il faut fournir (en jour homme) pour atteindre l'objectif.
S'il nous arrive souvent d'être rattrapé par le temps, c'est qu'il est une contrainte forte. Elle est même si forte qu'elle fait oublier les béabas. Le mois dernier je reçois un coup de fil d'un ancien collègue qui en me donne de ses nouvelles :
- Je comprend pas quand tu bossais avec nous, on avait moins de retours clients, on arrive pas à comprendre pourquoi ?
- Tu as des exemples de retours ?
- La semaine dernière on a raté une mise en production, il y a une partie du site qui répondait plus. Les ingénieurs ont réparés en catastrophe, mais le client était pas content.
Tu m'étonnes ! En cherchant à savoir si les exigences de chaque environnement (de développement, de préproduction, tests et production) étaient respectées, je me suis aperçu que la préproduction était devenu l'espace de développement.
En réalité, ce n'est jamais aussi flagrant, et les ingénieurs sont persuadés de faire leur développement en local, et une fois terminé, de le passer en préproduction. Mais ce qui biaise la procédure, c'est que par manque de temps, certains développements, à peine terminés, sont intégrés aux travaux stables en préproduction sans même être testé par le développeur sur son environnement local. Plusieurs raisons sont fréquentes : le délais pour livre la fonctionnalité, l'environnement n'est pas à jour des contributions des coéquipiers, une contrainte spécifique au client l'empêche de reproduire fidèlement l'espace de production. Par suite, le bêta testeur va se focaliser sur les erreurs les plus énormes. Il y aura beaucoup d'aller-retour sur l'environnement de préprod. Au final, les bugs plus "cachés" ne sont détectés qu'en production.
Comment redresser la situation ?
1°) Les indices de ce "glissement d'environnement" font penser illico qu'il faut ajouter une étape à la procédure entre la préprod et le dév : une recette sur l'environnement de développement. En premier lieu j'ai eu le réflexe de conseiller cette méthode, puis me suis raviser.
En fait, oui pour une étape supplémentaire si elle est automatisé (cas de x programming) : jeu de tests unitaires, fonctionnels, ... dans ce cas elle est intégré au build. Non si c'est pour une recette des bêta testeurs : le développeur lui même doit livrer un travail le plus parfait possible et fonctionnel.
Si on ajoute une étape en croyant que cette contrainte sera un passage de plus dans un tamis garantissant moins de bugs, on se trompe. Si on ne contient pas ce phénomène de glissement d'environnement, en établissant les raisons, on ajoutera des tamis et toujours plus de tamis. Cela apportera une rigidité à l'ensemble néfaste pour la bonne conduite du projet. (voir l'algorithme de mon médecin)
2°) Rédiger simplement par écrit les procédures et en faire la communication
Il me semble important que l'équipe comprenne pourquoi le respect de chaque espace est important pour ne pas mettre en péril la qualité des mises en production. Dans la plupart des projets web, les procédures doivent rester à la mesure du projet, donc légères.
Finalement, c'est la communication qui sauvera l'affaire pour expliquer que certains raccourcis ne sont pas à prendre quand le temps presse en fin de sprint ou quand le délais du projet arrive à échéance.