Ce qui fonctionne pour une équipe et un projet donné peut ne pas fonctionner ailleurs. L’architecture, la méthodologie, les pratiques en place qui ont fonctionné dans un contexte précis ne sont pas nécessairement transposables telles quelles d’une équipe à une autre ou d’un projet à un autre.
Voir la publication originale
Cette dernière est republiée ici afin de ne pas dépendre entièrement d'une plateforme tierce.
Il n’est pourtant pas rare de vouloir tout uniformiser en entreprise, parfois à l’extrême. Je vois et j’entends régulièrement des développeurs dire « il ne faut pas faire comme ça » ou « ça c’est une bêtise » en voyant telle ou telle pratique de code. Pourtant, ce sont des pratiques qui fonctionnent (parfois très bien) dans le contexte dans lequel elles sont utilisées. Simplement, cela sort des standards habituels connus des personnes qui font la remarque.
Il n’y a pas de recette universelle, pas de vérité absolue en informatique. « There’s no silver bullet » comme disent nos amis anglo-saxons. Une équipe de quelques développeurs sur un projet qui démarre n’a pas les mêmes contraintes qu’une équipe de dizaines de développeurs sur un produit mature.
Il est essentiel de comprendre le pourquoi derrière chaque pratique avant de la juger. C’est en comprenant les éléments qui ont conduit à sa mise en place qu’il sera possible de déterminer si elle est pertinente dans un autre contexte.
Les équipes qui fonctionnent le mieux ne cherchent pas à appliquer aveuglément ce qu’elles ont appris ailleurs. Elles questionnent, s’adaptent et font évoluer leurs pratiques en fonction de la maturité du projet et des personnes qui le composent.
