Factor bus 🚌
El Factor Bus (truck o pony factor) intenta medir:
El número de integrantes que, si fueran atropellados por un autobús, dejarían al proyecto sin capacidad de reacción ni continuación.
Lo intentaré explicar en una breve historia:
Llevas tiempo trabajando en un importante proyecto, sabes que aplicaste buena ingeniería a los problemas, corregiste los errores (en su mayoría), documentaste, en fin; mucha historia ha transcurrido durante este último semestre. Entonces, tú y tu equipo, están a punto de pasar a producción esa mejora que los diferenciará de la competencia.
Por todo lo anterior, coordinas con tu gente un “after office”: La razón es simple, festejar por todos los objetivos logrados. Llegó el tan ansiado “Viernes de verano”, esa misma tarde calurosa deciden juntarse en la esquina de aquel bar tan famoso, ya que todos los integrantes del equipo deben estar en un mismo punto (o el ejemplo no funcionaría 🤫).
Son las 18:45, ya llegó el último integrante y deciden entrar al bar. Ahora el escenario cambia radicalmente y lo trágico comienza. Varios se percatan que un autobús se acerca a ellos a una gran velocidad. Ruido, bocinas y gritos se apoderan del lugar. Intentan huir de una manera penosa y sin frutos (somos desarrolladores). Triste final para algunos, la mayoría mueren atropellados.
Bueno, no es necesario morir para ser considerado dentro del factor, que un autobús te atropelle es tan solo uno de los posibles casos, otros escenarios serían:
- Que los integrantes del equipo busquen nuevos y mejores rumbos (cambiar de trabajo)
- Tener un hija/hijo/perro/gato/jirafa
- Aburrimiento o cualquier cambio radical en la vida de los desarrolladores que los haga abandonar el proyecto repentinamente o sin aviso (millennials)
- Un meteorito (pobres dinosaurios)
Se puede asignar una puntuación a este factor para así calcular “donde se concentra la información” relevante del proyecto. Como regla, cuanto más bajo es el factor, menos desarrolladores deben morir (abandonar) para que el proyecto fracase, ya que esto implica que la información depende demasiado de un grupo pequeño de gente.
Calculando el factor bus
Al no existir un estándar, no existe un “método” que lo respalde. Una opción es analizando los commits de cada desarrollador individual. Se asume que cada commit implica un cierto “conocimiento” de ese desarrollador sobre los archivos a los que afecta el commit. A partir de ahí, se va agregando la “experiencia” para calcular qué desarrolladores acumulan un conocimiento tal que es suficiente como para formar parte del factor bus.
SOM-Research/busfactor busca solucionar esta incógnita, presentando una solución con una interfaz web que permite obtener el cálculo del factor para cierto repositorio de código. Pero claro, es un ejercicio que se puede aplicar a proyectos de larga trayectoria, la idea es evitar las malas prácticas.
Detectando el factor bus
En la mayoría de los casos, nosotros somos los culpables de que este factor sea bajo, ya que fomentamos lo siguiente:
- La visión completa del proyecto está concentrada en muy pocas personas. Generalmente la toma de decisiones depende de los líderes o en gran medida de las cabezas de la empresa ya que no existe una forma “fácil” de permear la información de otras áreas.
- El equipo tiene uno o algunos “key developers”, “cowboys” o “rockstars” que llevan sobre sus hombros gran parte del desarrollo: Seguramente te haz topado con estos casos, en donde trabajar con cierto desarrollador se hace complejo ya que no maneja un estándar en la codificación.
- Hay “zonas delicadas” en el código, que sólo algunos pocos iluminados son capaces de entender y tocar: Las mejor llamadas “cajas negras” — si funciona, no lo toques.
- Hay información secreta o datos que conocen pocos desarrolladores.
- Hay demasiada especialización en los miembros del equipo, por lo que cada uno gestiona áreas o tecnologías en la que no entran los demás y gestionan en exclusividad. Esto también se da, cuando el proyecto depende de una tecnología y el desarrollador que la implementó se fue a otro proyecto o simplemente fue abducido.
- Hay pocas personas con implicación real en el proyecto o el equipo está muy desmotivado. Este es un escenario complejo, en donde debes conocer a tu gente y tener claro el termómetro de las distintas “expectativas”.
Como explicaba anteriormente, no es necesario esperar a que llegue una catástrofe al equipo o proyecto para darnos cuenta de que tan bajo es el factor bus. La idea es implementar buenas prácticas en el día a día, fomentando una cultura rica en el flujo de información.
Buenas prácticas
- Mantener al equipo continuamente actualizado sobre el avance del proyecto. Por ejemplo, los stand-up meetings de Scrum o Kanban son una buena forma de poner en común los progresos, lo que cada uno hace, lo que piensa hacer o los problemas que está encontrando.
- Evitar secretismos o información restringida, facilitando la colaboración y el libre intercambio de información entre los miembros del equipo.
- Tener todos los activos del proyecto siempre disponibles en repositorios compartidos o almacenamientos a los que sea fácil acceder por parte de los miembros del equipo.
- Hacer a las personas partícipes y responsables del proyecto. Aumentar la sensación de “este es mi proyecto” en lugar de que cada uno se centre en una tecnología, funcionalidad o área. Favorecer la compartición colectiva del código, evitando propietarios en exclusiva de partes específicas.
- Aumentar la redundancia en habilidades y conocimientos. Esto puede conseguirse promoviendo la formación interna para romper la tendencia natural a la especialización, o llevando a cabo prácticas como pair programming con mucha rotación o code reviews frecuentes.
- Seguir convenciones y estándares comunes que hagan sencillo el movimiento de responsabilidades de un miembro del equipo a otro.
- Evitar complejidad excesiva y grandes ideas geniales que sólo unos pocos serán capaz de entender en el futuro. Si estamos seguros de que hay partes del código que no entenderemos ni nosotros mismos en solo un par de semanas más, ya estamos tardando en re-plantear el diseño. El código mantenible es fundamental, así como un cierto nivel de documentación, especialmente los procesos clave.
- Por último, si el equipo de desarrollo es excesivamente pequeño, tiene mala solución; llevándolo al extremo, imagina un proyecto con un único desarrollador. Aumentar el factor bus pasa irremediablemente por aumentar el tamaño del equipo. Si esto no es posible, la solución es aún más compleja: la forma de minimizar el riesgo sería aumentando el volumen y calidad de la documentación, de forma que ésta pudiera servir como base para retomar el proyecto si algo “extraño” sucediera.
En resumen, para aumentar el factor bus de nuestro proyecto, dependerá netamente de la cultura que exista en el equipo para subsanar la carencia de documentación. Una buena forma de comenzar es implementando algunos ejercicios de la metodología ágil, como por ejemplo, los stand-up meetings. También ayuda aplicar un estándar para la documentación de pull requests, esto último facilitará el code review. Y lo más importante: es enriquecer la cultura del flujo de información entre las distintas áreas de la empresa.
