Factor de bus

Medición del riesgo de perder expertos técnicos clave

El factor bus 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 bus". También se conoce como escenario de camión de pan , problema de autobús , escenario de camión de cerveza , factor de lotería , factor de camión , ^{[1] número de} autobús / camión o factor de camión .

El concepto es similar a la idea mucho más antigua del riesgo de la persona clave , pero considera las consecuencias de perder expertos técnicos clave, versus ejecutivos financieros o gerenciales (que en teoría son reemplazables a un costo asegurable). El personal debe ser clave e insustituible para contribuir al factor bus; perder a una persona reemplazable o no clave no resultaría en un efecto de factor de bus.

El término se aplicó por primera vez al desarrollo de software , donde un miembro del equipo puede crear componentes críticos al crear un código que funciona bien, pero que tampoco está disponible para otros miembros del equipo, como el trabajo que estaba indocumentado , nunca compartido , cifrado , ofuscado o no publicado. . Por lo tanto, un componente clave se perdería efectivamente como consecuencia directa de la ausencia de ese miembro del equipo, lo que hace que el miembro sea clave. Si este componente fuera clave para el avance del proyecto, el proyecto se estancaría.

Definición

El "factor bus" es el número mínimo de miembros del equipo que tienen que desaparecer repentinamente de un proyecto antes de que el proyecto se detenga debido a la falta de personal capacitado o con conocimientos.

La expresión "atropellado por un autobús" describe a una persona que está muriendo o, en general, desaparece repentinamente del proyecto. Se utiliza para describir hipotéticas desapariciones futuras de una manera oscuramente humorística. Los miembros del equipo no tienen que ser literalmente "atropellados por un autobús" para que se aplique el "factor de autobús"; podría ocurrir cualquier número de eventos en los que un miembro del equipo podría verse repentina y sustancialmente impedido de trabajar en el proyecto. Esto podría incluir que una persona acepte un nuevo trabajo, tome una licencia parental o cambie su estilo de vida o su estado de vida.

Por ejemplo, digamos que un equipo de 30 personas produce pan en tres pasos necesarios: mezclar ingredientes, amasar la masa y hornear. Diez personas saben cómo mezclar ingredientes, las 30 personas saben cómo amasar la masa y 5 personas saben cómo hornear. Si las 5 personas que saben hornear desaparecen, entonces el equipo no puede producir pan, por lo que el factor de autobús del equipo es 5.

Existe una definición alternativa poco común para el factor bus, a saber: la cantidad de personas que son indispensables para el proyecto. ^[2] En otras palabras, es el número mínimo de personas que son un solo punto de falla . Si usa esta definición, entonces un factor de bus alto se considera algo malo (ya que la pérdida de cualquier persona incluida destruye el proyecto), y cero se considera el factor de bus ideal.

Historia

Un ejemplo temprano de este tipo de consulta 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. ^[3]

"Truck number" ya era un concepto recurrente en el libro Organizational Patterns publicado en 2004, ^{[4] en} sí mismo una evolución del trabajo publicado en el primer libro de la serie Pattern Languages ​​of Program Design en 1995, ^[5] que fue la publicación registro de la primera conferencia de lenguajes de programas de patrones en agosto de 1994, donde se hizo referencia en patrones que incluyen Solo Virtuoso . ^[6] El término se había convertido en un lugar común en la gestión empresarial en 1998 ^{[ cita requerida ]} y se usó ^{[ aclaración necesaria ]} en salud mentalen el mismo año. ^[7] Se vio en artículos de ingeniería de software en Association for Computing Machinery and Information Systems Frontiers en 1999, ^{[ cita requerida ]} en ingeniería en 2003, ^[8] y el proyecto Debian en 2005. ^[9]

Los estudios realizados en 2015 y 2016 calcularon el factor autobús / 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. ^{[10] [11]}

El término se utiliza principalmente en la gestión empresarial, y especialmente en el campo del desarrollo de software . ^{[ cita requerida ]}

Incrementando el factor de bus

En muchos proyectos de desarrollo de software, un objetivo es compartir información para aumentar el factor de bus hasta potencialmente el tamaño de todo el equipo. Un factor de bus alto se considera algo bueno, ya que significa que muchas personas saben lo suficiente para continuar y el proyecto aún podría tener éxito incluso en eventos muy adversos. ^[12]

Se han propuesto varias formas de aumentar el factor de bus:

• Reducir la complejidad, ^[13]
• Documentar todos los procesos y mantener actualizada esa documentación, ^[13]
• Fomente el entrenamiento cruzado . ^[13]

Referencias

1. Bowler, Michael (15 de mayo de 2005). "Truck Factor" . Asesoramiento ágil.
2. Coplien, James; Harrison, Neil (26 de julio de 2004). Patrones organizativos de desarrollo ágil de software . Wiley.
3. McLay, Michael (29 de junio de 1994). "¿Si Guido fue atropellado por un autobús?" (Lista de correo).
4. Coplien, James; Harrison, Neil (26 de julio de 2004). Patrones organizativos de desarrollo ágil de software . Wiley.
5. Coplien, James; Schmidt, Douglas (12 de mayo de 1995). "Capítulo 13, un lenguaje de patrones de proceso de desarrollo generativo". Lenguajes de patrones de diseño de programas . Addison Wesley. Bibcode : 1995plpd.book ..... V .
6. Coplien, James (4 de agosto de 1994), "Un lenguaje de patrón de proceso de desarrollo generativo", Actas internas de PLoP 1994 , Allerton Park, Illinois: inédito.
7. Simon, Robert (17 de mayo de 1998). El practicante de salud mental y la ley: un manual completo . Prensa de la Universidad de Harvard. pag. 69. ISBN 0-674-69721-9.
8. Redmond, Matthew C .; Newton, Paul (2003). "Integración de GIS en los procesos de ingeniería, planificación y diseño" (PDF) . Archivado desde el original (PDF) el 12 de marzo de 2012.
9. Reinholdtsen, Petter (11 de noviembre de 2005). "Re: Renuncias y subidas" (lista de correo).
10. Avelino, Guilherme; Valente, Marco Tulio; Hora, Andre (10 de septiembre de 2015). "¿Cuál es el Truck Factor de las aplicaciones populares de GitHub? Una primera evaluación" . Preprints de PeerJ . doi : 10.7287 / peerj.preprints.1233v3 .
11. Avelino, Guilherme; Passos, Leonardo; Hora, Andre; Valente, Marco Tulio (2016). "Un enfoque novedoso para estimar los factores de camiones". 2016 IEEE 24th International Conference on Program Comprehension (ICPC) . págs. 1-10. arXiv : 1604.06766v1 . Código bibliográfico : 2016arXiv160406766A . doi : 10.1109 / ICPC.2016.7503718 . ISBN 978-1-5090-1428-6. S2CID  19238548 .
12. James Coplien, Par de programación iluminada . Cita: "¿Cuántos o pocos tendrían que ser atropellados por un camión (o abandonar) antes de que el proyecto quede incapacitado?"
13. "Incrementar el factor de bus de su equipo" . 2008-09-03.

Otras lecturas

• Michele Marchesi, Giancarlo Succi, Don Wells, James Donovan Wells, Laurie Williams (2003). Perspectivas extremas de programación . Boston UA: Addison-Wesley. ISBN 0-201-77005-9.
• Laurie Williams , Robert Kessler (2002). Programación en pareja iluminada . Boston UA: Addison-Wesley. ISBN 0-201-74576-3.
• Kent Beck (2000). Programación extrema. Das Manifest (en alemán). sl: Addison-Wesley. ISBN 3-8273-2139-5.

enlaces externos

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