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   , conocido también como el       o incluso   . Factor Bus problema del autobús, factor camión, factor camión 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   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. puntaje Bus Factor  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   dentro del proyecto. Es preferible una puntuación Bus Factor mucho mayor, pero no siempre es fácil de lograr.  único punto de falla  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:   , 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. Nikita Popov  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   es una organización sin fines de lucro cuya misión es asegurar la larga vida y prosperidad del lenguaje PHP. Fundación 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   , 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). NIH (Not Invented Here)  Un   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. puntaje bajo de Bus Factor  ¿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   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. mayores  Tu persona Bus Factor como profesor  Cuando identifiques a   , 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   . las personas de Bus Factor 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".

Different

2022 - All About Teamwork

2022 - HackerNoon Contributor of the Year - Management

Official Technical blog

Nominated for 2022 - All About Teamwork

Nominated for 2022 - HackerNoon Contributor of the Year - Management

Staff Software Engineer at TUI Musement

Este audio es producido en el idioma original de la historia!

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

About Author

COMENTARIOS

ETIQUETAS

ESTE ARTÍCULO FUE PRESENTADO EN

Related Stories

La guía completa para una migración exitosa a la nube: estrategias y mejores prácticas

¿Quieres ganar un concurso de redacción de HackerNoon? Esto es lo que recomiendan los ganadores del concurso #crypto-api

Navegando por las aguas: desarrollo de aplicaciones RAG de nivel de producción con lagos de datos

Las capas invisibles: por qué las entrevistas con los usuarios son un activo irremplazable

La guía completa para una migración exitosa a la nube: estrategias y mejores prácticas

¿Quieres ganar un concurso de redacción de HackerNoon? Esto es lo que recomiendan los ganadores del concurso #crypto-api

Navegando por las aguas: desarrollo de aplicaciones RAG de nivel de producción con lagos de datos

Las capas invisibles: por qué las entrevistas con los usuarios son un activo irremplazable

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps