Factor de autobuses

El factor autobús (también conocido como factor lotería , ^{[ 1 ] [ 2 ]} factor camión , ^{[ 3 ]} o factor circo ^{[ 4 ]} ) es una medida del riesgo resultante de que la información y las capacidades no se compartan entre los miembros del equipo, derivada de la frase "en caso de que los atropelle un autobús".

El concepto es similar a la idea, mucho más antigua, del riesgo asociado a personas clave , pero considera las consecuencias de perder a expertos técnicos clave, en comparación con los ejecutivos financieros o de gestión (que, en teoría, son reemplazables a un costo asegurable). El personal debe ser clave e irremplazable para contribuir al factor de riesgo; la pérdida de una persona reemplazable o no clave no generaría dicho efecto.

El término se aplicó inicialmente al desarrollo de software , donde un miembro del equipo podía crear componentes críticos mediante código de alto rendimiento, pero que no estaba disponible para otros miembros, como por ejemplo, trabajo sin documentar , nunca compartido , cifrado , ofuscado o no publicado . De este modo, un componente clave se perdía como consecuencia directa de la ausencia de dicho miembro, convirtiéndolo en fundamental. Si este componente era esencial para el avance del proyecto, este se estancaría.

El "factor autobús" es el número mínimo de miembros del equipo que deben desaparecer repentinamente de un proyecto antes de que este se paralice por falta de personal capacitado o competente.

La expresión «ser atropellado por un autobús» describe a una persona que fallece o, en general, desaparece repentinamente del proyecto. Se utiliza para describir hipotéticas desapariciones futuras con un humor negro. Los miembros del equipo no tienen que ser literalmente «atropellados por un autobús» para que se aplique el «factor autobús»; pueden ocurrir muchos eventos que impidan de forma repentina y sustancial que un miembro del equipo trabaje en el proyecto. Esto podría incluir que una persona acepte un nuevo trabajo, se tome una baja por maternidad o paternidad, o que cambie su estilo de vida o situación personal.

Por ejemplo, supongamos que un equipo de 30 personas elabora pan en tres pasos necesarios: mezclar los ingredientes, amasar la masa y hornear. Diez personas saben mezclar los ingredientes, las 30 saben amasar la masa y cinco saben hornear. Si las cinco personas que saben hornear desaparecen, el equipo no podrá producir pan, por lo que su factor de seguridad es 5. Un factor de seguridad de uno representa un único punto de fallo .

Un ejemplo temprano de este tipo de pregunta fue cuando Michael McLay preguntó públicamente, en 1994, qué pasaría con el lenguaje Python si Guido van Rossum fuera atropellado por un autobús. ^{[ 5 ]}

El término "número de camión" ya era un concepto recurrente en el libro Patrones Organizacionales publicado en 2004, ^{[ 6 ]} que a su vez era una evolución del trabajo publicado en el primer libro de la serie Lenguajes de Patrones de Diseño de Programas en 1995, ^{[ 7 ]} que fue el registro de publicaciones de la primera conferencia Lenguajes de Patrones de Programas en agosto de 1994, donde se hizo referencia a él en patrones como Solo Virtuoso . ^{[ 8 ]} El término se utilizó en salud mental en 1998. ^{[ 9 ]} Se vio en ingeniería en 2003, ^{[ 10 ]} y en el proyecto Debian en 2005. ^{[ 11 ]}

Estudios realizados en 2015 y 2016 calcularon el factor de bus/camión de 133 proyectos populares de GitHub . Los resultados muestran que la mayoría de los sistemas tienen un factor de bus pequeño (el 65% tiene un factor de bus ≤ 2) y el valor es mayor que 10 para menos del 10% de los sistemas. ^{[ 12 ] [ 13 ]}

El término se utiliza principalmente en la gestión empresarial, y especialmente en el campo del desarrollo de software .

En muchos proyectos de desarrollo de software, uno de los objetivos es compartir información para mejorar el factor de colaboración, potencialmente hasta el tamaño de todo el equipo. Un buen factor de colaboración significa que muchas personas tienen los conocimientos suficientes para continuar y que el proyecto puede tener éxito incluso en situaciones muy adversas. ^{[ 14 ]}

Se han propuesto varias formas de mejorar el factor autobús:

• Reducir la complejidad, ^{[ 15 ]}
• Documentar todos los procesos y mantener esa documentación actualizada, ^{[ 15 ]}
• Fomentar el entrenamiento cruzado . ^{[ 15 ]}

• Memoria organizacional
• Camión-kun

• Michele Marchesi, Giancarlo Succi, Don Wells, James Donovan Wells, Laurie Williams (2003). Perspectivas de la programación extrema . Boston, EE. UU.: Addison-Wesley. ISBN 0-201-77005-9.{{cite book}}: CS1 maint: varios nombres: lista de autores ( enlace )
• Laurie Williams , Robert Kessler (2002). Programación en parejas: una introducción . Boston, EE. UU.: Addison-Wesley. ISBN 0-201-74576-3.
• Kent Beck (2000). Programación Extrema. El Manifiesto (en alemán). sl: Addison-Wesley. ISBN 3-8273-2139-5.

• Gente venenosa , una charla que incluye (entre otros temas) una discusión sobre el factor autobús y cómo aumentarlo.
• "¿Qué pasaría si Linus Torvalds fuera atropellado por un autobús?" - Un estudio empírico , una pieza de humor.