The Bus Factor Score: ¿Cuántos miembros del equipo pueden ser atropellados por un autobús antes de que el equipo falle?

Un poquito de historia

Si bien el título puede sonar bastante extremo, Michael McLay preguntó públicamente una oración similar en 1994 :

¿Si Guido fuera atropellado por un autobús? (Guido van Rossum es el creador del lenguaje Python)

Esa pregunta llevó a la creación del Factor Bus , conocido también como el problema del autobús, factor camión, factor camión o incluso factor lotería .

¿Qué es un “Factor Bus”?

Si bien hay varias definiciones ligeramente diferentes en la Web, podemos resumirlas como:

El Bus Factor es el número total de personas que necesitarían ser incapacitadas, como ser atropelladas por un autobús para que el proyecto se dé por muerto.

Para hacer esto más descriptivo, el puntaje Bus Factor es una estimación de las personas que son tan vitales para su proyecto que sin ellas se detendría. Si esas personas desaparecieran del proyecto por cualquier razón (como un "accidente" o incluso tomando vacaciones, siendo despedidas o abandonando el proyecto), nadie podría mantener el proyecto.

El puntaje de Bus Factor más bajo posible es solo 1, lo que significa que si una persona abandona el proyecto, se estancará o morirá. Desde un punto de vista más técnico, esto podría considerarse un único punto de falla dentro del proyecto. Es preferible una puntuación Bus Factor mucho mayor, pero no siempre es fácil de lograr.

Problema de la comunidad PHP

A fines de 2021, la comunidad de PHP recibió la triste información de que después de 10 años de implementar innumerables correcciones de errores, funciones y mantenimiento de PHP, uno de los principales contribuyentes: Nikita Popov , decidió concentrarse en trabajar en un lenguaje y una comunidad completamente diferentes (Rust & LLVM), del que ya se había separado durante unos años.

Similar a la historia del lenguaje Python, esa decisión mostró que el lenguaje PHP tiene un gran problema con un puntaje de Bus Factor tan bajo. Puso el futuro del lenguaje que alimenta ~78% de la Web en una posición peligrosa.

Para mejorar el estado actual, las personas y empresas que trabajan en PHP se unieron y comenzaron una nueva iniciativa: Fundación PHP .

La Fundación PHP es una organización sin fines de lucro cuya misión es asegurar la larga vida y prosperidad del lenguaje PHP.

La primera decisión que tomó la fundación fue contratar/patrocinar nuevos desarrolladores para trabajar en los componentes principales de PHP. De esa manera, podrían comenzar a aumentar el puntaje de Bus Factor a un nivel más seguro. Este es uno de los muchos pasos que debe tomar la comunidad para que el futuro de PHP sea seguro y estable.

Problemas de la empresa

Muchas de las empresas para las que trabajé, desde nuevas empresas hasta corporaciones, a menudo se vieron muy afectadas por el factor autobús. Muchos de sus equipos (la mayoría de las veces no intencionalmente) cayeron en NIH (Not Invented Here) , lo que provocó problemas con el mantenimiento y un nivel de entrada más alto para los recién llegados, ya que más y más cosas fueron creadas por personas que podían abandonar el proyecto. en cualquier momento. Esto a menudo ha llevado a una deuda técnica alta (que trataré de explicar en una publicación posterior).

Un puntaje bajo de Bus Factor a menudo es parte del tiempo de rápido crecimiento cuando solo unos pocos desarrolladores crean la mayor parte de la funcionalidad que luego se convierte en la base para un proyecto cada vez más complejo. La mayoría de las empresas inician grandes planes de contratación durante dicho crecimiento, pero eso no es algo que pueda aumentar el Bus Factor por sí solo.

¿Cómo aumentar una puntuación baja de Bus Factor?

Sesiones de coaching y programación en pareja

Cada nuevo miembro debe tener al menos 30 minutos de una sesión de programación en pareja con una de las personas mayores dentro del proyecto al que se une. Durante tales sesiones, una persona con menos experiencia debe realizar la mayor parte de la codificación, mientras que los mentores principales predican con el ejemplo y sugieren partes que pueden ayudar a lograr el objetivo de la tarea.

Tu persona Bus Factor como profesor

Cuando identifiques a las personas de Bus Factor , debes enfocarte en cómo pueden compartir el conocimiento que acumularon durante todos esos años en tu proyecto. Su conocimiento es uno de los mayores valores para su equipo. Pídales que se concentren más en escribir documentación, crear hojas de trucos, hacer presentaciones internas y compartir conocimientos en sesiones individuales con sus compañeros de equipo. Su enfoque en la programación debe reducirse .

Cultura de revisión de código

Si bien la adopción de la cultura de revisión del código la realizan los equipos para mejorar la calidad del código y el proceso de revisión, el resultado menos obvio es el intercambio directo de conocimientos entre las personas del proyecto. Las revisiones no deben ser como dar un sello de aprobación. Deben señalar por qué algo se hizo de esa manera y no de otra manera, lo que lleva a discusiones constructivas entre los seniors y otros compañeros de equipo sobre lo que se podría hacer de manera diferente, desde la perspectiva de los seniors. Las revisiones deben conducir a la discusión.

Reducir la complejidad de los proyectos

A menudo, el problema de las empresas de rápido crecimiento es la deuda técnica de rápido crecimiento, lo que conduce a una puntuación baja de Bus Factor. Una de las técnicas efectivas es reducir la complejidad de los proyectos dividiéndolos en proyectos más pequeños y dedicados. Esto conduce a un nivel de entrada más bajo, una adopción más rápida y un mantenimiento más fácil. Todos estos puntos permiten aumentar el Bus Factor general de manera bastante efectiva. El mayor problema que debe evitar durante la reducción de la complejidad de los proyectos es involucrar siempre a los equipos (incluso los pequeños) en la refactorización para evitar crear el mismo problema en los nuevos subproyectos .

Equipo "barajando"

Esta puede ser la forma más eficaz de aumentar la puntuación de Bus Factor, pero también es la más difícil y peligrosa. Necesita planificar profundamente todas las posibilidades para evitar perder la moral del equipo. El "barajar" no debe ser forzado, sino propuesto a los miembros del equipo de manera regular, como: una vez cada dos trimestres; los compañeros de equipo no pueden cambiar de equipo con demasiada frecuencia, ya que deberán incorporarse como un recién llegado. Si está bien planificado y ejecutado, sus equipos obtendrán una experiencia mucho más amplia en diferentes dominios, compartiendo el conocimiento aprendido mientras trabajan con otros equipos.

Presupuesto de formación

La planificación de presupuestos de capacitación para sus desarrolladores también puede aumentar el puntaje de Bus Factor, ya que las personas reunirán una gama más amplia de experiencia y ampliarán su equipo para tener más personas en cada rango de antigüedad dentro de la jerarquía de su empresa.

Resumen

No es tan fácil, barato o rápido aumentar la puntuación de Bus Factor de su equipo. Hay casos en los que no desea (o incluso no puede) aumentar fácilmente ese puntaje, por ejemplo, cuando el proyecto contiene datos confidenciales y no puede confiar en que sus nuevos empleados comiencen a manejarlo. Pero ahora conoce algunos de los conceptos básicos que pueden ayudarlo a evitar que sus operaciones se detengan debido a un "accidente de autobús".