Bus Factor : c'est quoi ce truc ?

Alors, parlons du bus factor, aussi apellé "truck factor" ou "lottery number". Derrière ce terme se cache une question que vous devriez vous poser si vous travaillez sur n'importe quel projet en équipe :

 Combien de personnes clés
dans votre équipe peuvent se faire renverser par un bus avant que votre projet échoue ? 

Estimez le bus factor de votre projet

Pour chaque personne dans votre équipe vous pouvez vous poser cette question : 

 le projet pourrait-il continuer dans de bonnes conditions si cette personne venait à quitter l’équipe ? 

Le bus factor est un chiffre, c'est le nombre de personnes qui, additionnées, sont absolument indispensables à l'équipe et que vous ne pouvez pas vous permettre de perdre en même temps.

Bus factor = 1

Je vous explique : là tout de suite, vous pensez peut-être à votre administrateur système qui a absolument tous les mots de passe des serveurs en tête et s'il venait à disparaitre demain, les serveurs tombent, vos utilisateurs partent et c'est la fin du monde. Ça, c'est un bus factor de 1 et c'est vraiment pas bon du tout.

Bus factor = 2

En plus du sysadmin, il y a aussi le développeur qui a bossé sur un énorme projet pour la refonte de votre nouveau site et qui a travaillé en local et tout stocké dans son ordinateur. Pas de bol, lors de la collision avec le bus 172 en direction de frisange, il avait son ordinateur portable dans son sac à dos, et en plus d'avoir perdu votre seul et unique développeur, vous avez aussi perdu 7 mois de développement. 

Vous avez encore moins de chance : le développeur sortait du bureau en même temps que l'admin système et les deux ont été renversés en même temps.

Là vous vous dites que votre bus factor et de 2, et que c'est un peut moins grave. Malheureusement s'ils avaient une passion commune pour le macramé, ils ne discutaient pas beaucoup boulot et ne pouvaient pas reprendre le travail de l'autre s'il l'un des deux étaient absent.

Vous avez donc un bus factor de 1. Et ça craint.

Pour avoir un de 2, il faut que les deux métiers soient proches, ou dumoins que les personnes partagent des compétences communes et sachent sur quoi l'une et l'autre travaille pour pouvoir reprendre un projet en cours. Sans oublier des sauvegardes et de la documentation, ça aide pour reprendre une tâche en cours.

Bus factor = 3

Admettons que vous ayez 3 développeurs, qui travaillent sur la même technologie, avec les mêmes outils, sur le même projet, avec des sauvegardes régulière et une documentation correcte. Là en théorie, c'est un bus factor de 3. Mais si a coté l'administrateur système ne partage rien, reste dans son coin et que personne ne peut prendre le relai, au final votre bus factor restera de 1.

Ça peut être aussi la personne qui fait la compta et qui ne payera pas de fournisseurs à temps, ou le patron, qui aura la vision globale à long terme et des contacts "un peu secrets" pour la prochaine levée de fond. Bref, vous voyez, c'est pas si simple d'avoir un bus factor supérieur à 1.

Si vous avez mis tout votre code sur github, il existe un outil très sympa (gittrends) qui vous permettra d'avoir plein de statistiques sur votre projet et entre autres, de calculer votre bus factor. Evidemennt, le chiffre donné ne sera basé que sur le code. Si vous avez une documentation correcte et que chaque personne de l'équipe partage ses connaissances, il faudra recalculer ce chiffre vous-même.

Pour vous donner un ordre d'idée, voici le flop 5  des projets connus ayant le plus petit bus factor :

  • Font-Awesome: 1 
  • Bootstrap: 3
  • React: 4
  • jquery: 4
  • AngularJS: 6

Bon, à partir de 4 c'est déjà moins risqué, mais je connais quand même au moins 2-3 sites qui utilisent React ou jquery et ça me rassure pas trop trop que ces 4 personnes voyagent ensemble. Pas vous?

De l'autre coté, on a le top 5 des projets ayant un bus factor super élevé

  • Linux: 163
  • Homebrew-cask: 160
  • Oh-my-zsh: 74
  • Github-services: 44
  • Faker: 32

C'est quand même assez peu probable qu'un seul bus soit capable de renverser d'un coup les 163 developpeurs de Linux. Mais ne sous-estimez pas le bus 172.

Comment augmenter votre bus factor ?

Il y a quelques techniques pour réduire les chances de couler votre boîte ou votre projet

1. Partagez les connaissances

Dans l'idéal, composez votre équipe de personnes ayant un profil en T (des connaissances solides sur un sujer/une spécialité + des connaissances de bases sur des sujets proches partagés par d'autres personnes dans l'équipe). 

Encouragez le cross-training, proposez des sessions pour former aux connaissances de base de chaque métier dans votre équipe.

Lors des réunions régulières (et j'espère que vous bossez en agile), faites aussi le point sur l'avancement de chaque personne sur le projet.

Aussi, pensez à dédier du temps aux personnes clés de votre équipe pour partager des informations cruciales concernant le projet.

2. Simplifiez les procédures

Automatisez un maximum de trucs : les outils, la gestion des mots de passe, les mises en production. Vous gagnerez aussi du temps !

KISS : keep it simple stupid. Pourquoi faire compliqué ? Si vous pouvez vous permettre de prendre un peu de temps pour simplifier vos procédures, pitié, faites-le.

Choisissez la bonne technologie, qui conviendra aux besoins et qui sera connue de tous, avec une documentation correcte et des mises à jours régulières. Ne tentez pas d'utiliser un framework obscur seulement parce que votre lead developper est un hipster et qu'il a juste envie de nouveauté. Si vous n'avez qu'un seul spécialiste de ce framework et aucune documentation, ça va pas trop bien se passer si votre hipster disparait.

3. Documentez

Et pas seulement dans le code hein. La documentation, c'est pour tout le monde. Documentez votre code, vos designs, vos tâches, vos pull requests. Mettez tout au même endroit, genre sur un wiki. Pensez aussi à expliquer dans vos tickets comment le problème a été résolu. Si le problème revient dans 2 ans, vous passerez probablement moins de temps à le corriger.

4. Sauvegardez

Ça parait évidement comme ça, mais pitié, sauvegardez tout, tout le temps, vraiment. Et pas seulement sur un disque dur externe vous vous baladerez en même temps que votre ordi portable dans votre sac à dos, qui sera aussi touché lors de l'impact avec le bus 172 à destination de Frisange. Dropbox, git, svn, la demi tonne de clouds et de serveurs amazon sont aussi là pour ça. Et n'oubliez pas de faire des sauvegardes du wiki aussi. Ça serait quand même dommage de perdre toute votre documentation aussi.

5. Arrêtez de traverser la route

Bon j'ai essayé mais c'est quand même pas trop trop pratique.
Pensez à regardez des deux cotés de la route quand vous traversez.
Et traversez au vert, hein.

Qui peut le plus peut le moins

J'arrête pas de vous parler du bus 172, mais y'a un truc qui risque de vous arriver prochainement : des vacances.

Si vous pouvez vous permettre de mourir, vous pouvez partir en vacances tranquillement et personne ne viendra vous appeler alors que vous serez sur votre transat à bronzer au bord de la piscine.

Conclusion

Arrêtez de vous rendre indispensable.

Dès lundi, essayez d'augmenter votre bus factor