Le score du facteur de bus : combien de membres de l'équipe peuvent être heurtés par un bus avant que l'équipe ne tombe en panne ?

Un peu d'histoire

Bien que le titre puisse sembler assez extrême, une phrase similaire a été demandée publiquement par Michael McLay en 1994 :

Si Guido a été percuté par un bus ? (Guido van Rossum est le créateur du langage Python)

Cette question a conduit à la création du facteur bus , également connu sous le nom de problème de bus , facteur camion , facteur camion ou même facteur loterie .

Qu'est-ce qu'un "facteur de bus" ?

Bien qu'il existe plusieurs définitions légèrement différentes sur le Web, nous pouvons les résumer comme suit :

Le facteur de bus est le nombre total de personnes qui devraient être frappées d'incapacité, par exemple en se faisant heurter par un bus afin que le projet soit laissé pour mort.

Pour rendre cela plus descriptif, le score du facteur de bus est une estimation des personnes qui sont si vitales pour votre projet que sans elles, il stagnera. Si ces personnes disparaissaient du projet pour une raison quelconque (comme un "accident" ou même prendre des vacances, se faire virer ou quitter le projet), personne ne serait en mesure de maintenir le projet.

Le score de facteur de bus le plus bas possible est de 1, ce qui signifie que si une personne quitte le projet, elle s'arrêtera ou mourra. D'un point de vue plus technique, cela pourrait être considéré comme un point de défaillance unique au sein du projet. Un score de facteur de bus beaucoup plus élevé est préférable, mais pas toujours facile à atteindre.

Problème de la communauté PHP

Fin 2021, la communauté PHP a reçu la triste nouvelle qu'après 10 ans d'implémentation d'innombrables corrections de bogues, fonctionnalités et maintenance de PHP, l'un des principaux contributeurs : Nikita Popov , a décidé de se concentrer sur le travail dans une langue et une communauté complètement différentes (Rust & LLVM), dont il était déjà séparé depuis quelques années.

Semblable à l'histoire du langage Python, cette décision a montré que le langage PHP a un très gros problème avec un score de facteur de bus aussi bas. Cela a mis l'avenir du langage qui alimente ~ 78% du Web dans une position dangereuse.

Pour améliorer l'état actuel, les personnes et les entreprises travaillant sur PHP ont uni leurs forces et ont lancé une nouvelle initiative : PHP Foundation .

La Fondation PHP est une organisation à but non lucratif dont la mission est d'assurer la pérennité et la prospérité du langage PHP.

La première décision prise par la fondation a été d'embaucher/sponsoriser de nouveaux développeurs pour travailler sur les composants de base de PHP. De cette façon, ils pourraient commencer à augmenter le score du facteur de bus à un niveau plus sûr. C'est l'une des nombreuses étapes qui doivent être franchies par la communauté pour rendre l'avenir de PHP sûr et stable.

Problèmes de l'entreprise

De nombreuses entreprises pour lesquelles j'ai travaillé, des startups aux entreprises, ont souvent été durement touchées par le Bus Factor. Beaucoup de leurs équipes (la plupart du temps pas intentionnellement) sont tombées dans le NIH (Not Invented Here) , ce qui a entraîné des problèmes de maintenance et un niveau d'entrée plus élevé pour les nouveaux arrivants, car de plus en plus de choses ont été créées par des personnes qui pouvaient quitter le projet. à n'importe quel moment. Cela a souvent conduit à une dette technique élevée (que j'essaierai d'expliquer dans un article ultérieur).

Un faible score de facteur de bus fait souvent partie du temps de croissance rapide où seuls quelques développeurs créent la plupart des fonctionnalités qui deviennent plus tard la base d'un projet de plus en plus complexe. La plupart des entreprises commencent de gros plans d'embauche au cours d'une telle croissance, mais ce n'est pas quelque chose qui peut augmenter le facteur bus à lui seul.

Comment augmenter un score de Bus Factor bas ?

Séances de coaching et programmation en binôme

Chaque nouveau membre doit avoir au moins 30 minutes d'une session de programmation en binôme avec l'une des personnes les plus expérimentées au sein du projet qu'il rejoint. Au cours de ces sessions, une personne moins expérimentée devrait effectuer la majeure partie du codage, tandis que les mentors seniors donnent l'exemple et suggèrent des parties qui peuvent aider à atteindre l'objectif de la tâche.

Votre personne Bus Factor en tant qu'enseignant

Lorsque vous identifiez les personnes de Bus Factor , vous devez vous concentrer sur la manière dont elles peuvent partager les connaissances qu'elles ont accumulées pendant toutes ces années de votre projet. Leurs connaissances sont l'une des plus grandes valeurs de votre équipe. Demandez-leur de se concentrer davantage sur la rédaction de documentation, la création de feuilles de triche, la réalisation de présentations internes et le partage de connaissances lors de sessions individuelles avec leurs coéquipiers. Leur concentration sur la programmation devrait être réduite .

Culture de revue de code

Alors que l'adoption de la culture de révision du code est effectuée par des équipes pour améliorer la qualité du code et le processus de révision, le résultat le moins évident est le partage direct des connaissances entre les personnes du projet. Les avis ne doivent pas être comme donner un cachet d'approbation. Ils devraient indiquer pourquoi quelque chose a été fait de cette façon, pas une autre, menant à des discussions constructives entre les seniors et les autres coéquipiers sur ce qui pourrait être fait différemment, du point de vue des seniors. Les avis doivent donner lieu à discussion.

Réduire la complexité des projets

Souvent, le problème des entreprises à croissance rapide est la dette technique à croissance rapide, qui conduit à un score de facteur de bus faible. L'une des techniques efficaces consiste à réduire la complexité des projets en les divisant en projets plus petits et plus dédiés. Cela conduit à une entrée de gamme inférieure, à une adoption plus rapide et à une maintenance plus facile. Tous ces points permettent d'augmenter assez efficacement le Bus Factor global. Le plus gros problème que vous devez éviter lors de la réduction de la complexité des projets est de toujours impliquer des équipes (même petites) dans le refactoring pour éviter de créer le même problème dans le(s) nouveau (x) sous-projet(s) .

"Remuement" d'équipe

Cela peut être le moyen le plus efficace d'augmenter le score du facteur de bus, mais c'est aussi le plus difficile et le plus dangereux. Vous devez planifier en profondeur toutes les possibilités pour éviter de perdre le moral de l'équipe. Le "Shuffling" ne doit pas être forcé, mais proposé aux membres de l'équipe de manière régulière, comme : une fois tous les deux trimestres ; les coéquipiers ne peuvent pas changer d'équipe trop souvent car ils devront être intégrés comme un nouveau venu. Si elles sont bien planifiées et exécutées, vos équipes acquerront une expérience beaucoup plus large dans différents domaines, partageant les connaissances acquises en travaillant avec d'autres équipes.

Budget formation

La planification des budgets de formation pour vos développeurs peut également augmenter le score du facteur de bus, car les personnes accumuleront une expérience plus large et élargiront votre équipe pour avoir plus de personnes dans chaque rang d'ancienneté au sein de la hiérarchie de votre entreprise.

Sommaire

Ce n'est pas si facile, pas cher ou rapide d'augmenter le score du facteur de bus de votre équipe. Il y a des cas où vous ne voulez pas (ou même ne pouvez pas) augmenter facilement ce score, par exemple lorsque le projet contient des données sensibles et que vous ne pouvez pas faire confiance à vos nouvelles recrues pour commencer à les gérer. Mais maintenant, vous connaissez certaines des bases qui peuvent vous aider à éviter que vos opérations ne s'arrêtent en raison d'un "accident de bus".