Le principe du feu de camp

Il y’a quelques jours, un ami me demandais pourquoi certains projets auquel je participais ne finissait pas immédiatement, ou que je revenais parfois dessus pour « bidouiller ».

Et j’ai ainsi pu lui expliquer par l’analogie du feu de camp, c’est assez simple à appréhender pour un non initié et vais vous la montrer ici.

Tout d’abord, il faut voir un projet comme un feu de camp : plus nous codons les structures de base, plus nous ajoutons du bois à notre feu. C’est ce que nous appelons un MVP : produit viable minimum; le coeur de l’idée du projet auquel nous participons.

Exemple : pour un blog, le mvp sera un CRUD article et l’affichage de ces articles du coté utilisateur.

Plus notre feu de camp sera important, plus le nombre de contributeurs autour de celui-ci pour le maintenir et chauffer sera important.

Mais la masse critique de ce feu ne peut pas s’étendre à l’infini sans créer une montagne de bois et de feu qui ne sera pas maintenable sur le long terme sans épuiser tous les contributeurs et brûler la forêt autour (brûler les ressources de l’entreprise).

C’est ainsi que nous devons réaliser des petits feu de camp pour toujours garder le même nombre de contributeurs au même endroit, en ayant découpé le nombre d’opérations par petits camp de x contributeurs (disons pour 10, 2 à 5 contributeurs, afin que FnContributeurs <= 50% de TotalContributeurs).

Ainsi, une fonctionnalité (feature) en développement aujourd’hui doit être la même chose qu’un petit feu de camp à proximité du camp principal : il doit fonctionner de manière indépendante, que les autres petit feu n’aient pas nécessairement besoin de celui-ci (mais peuvent l’améliorer), si une dépendance est nécessaire, cela ne doit jamais impacter le feu principal en faisant porter un risque d’extinction.

Il est temps d’aller se faire fondre des marchmallow maintenant, have fun !