Me encanta encontrar definiciones más o menos conocidas de conceptos o ideas que se nos han pasado por la cabeza en algún momento sin saber que otros ya les habían dado forma, porque demuestra que todos los que nos dedicamos a esto tenemos poco más o menos las mismas inquietudes.En este caso, me ha entusiasmado dar por casualidad con el "bus factor", un término que seguro muchos conocíais pero para mi ha sido un descubrimiento reciente, que básicamente da forma a la pregunta que seguro que todos nos hemos hecho sobre la continuidad de algunos proyectos ante determinados acontecimientos inesperados.
Imaginemos que todo el equipo de desarrollo de un proyecto va caminando por la calle, y un autobús que circulaba cerca pierde el control y les arrolla de forma violenta. ¿A cuántos miembros del equipo tendría que afectar fatalmente este accidente para poner en gran peligro la continuidad del proyecto?
"The bus factor connotes the number of team members that can be unexpectedly lost from a project ('by a bus', as it were) before the project collapses due to lack of knowledgeable or competent personnel"
-- Bus Factor (Wikipedia)
Pues bien, ese número es el "Bus factor", también es conocido por variantes como "Truck factor" o "Lorry factor" o similares, atendiendo al tipo de objeto que provocaría el estropicio. Básicamente, es una medida de la concentración de información y conocimiento en determinadas personas del equipo, y es peor cuanto más pequeño resulta.-- Bus Factor (Wikipedia)
Un valor de uno es el mínimo, y seguro que lo reconocéis en muchos proyectos que habréis visto a lo largo de los años: indica que toda la información y conocimientos vitales del proyecto están depositados en una única persona, por lo que bastaría con que el autobús se cebara con ella para que el proyecto fuera al traste. Como muestra, hace años se decía que Linux tenía un Bus factor 1, lo cual se entendía como un gran riesgo para el proyecto por la gran dependencia que existía hacia su creador.
Por aportar algo a la causa, yo casi añadiría que también existe un "Bus factor 0": proyectos que se ve a la legua que van a ir al traste aunque el autobús no atropelle a nadie, pero esto es harina de otro costal… ;)
En bastantes empresas y proyectos de tamaño pequeño o mediano es curioso, a la vez que espeluznante, ver que el Bus factor suele ser uno, o acercarse peligrosamente a este valor. Esto podemos detectarlo fácilmente, por ejemplo, cuando:
- La visión completa del proyecto está concentrada en muy pocas personas.
- El equipo tiene uno o algunos key developers, cowboys o rockstars que llevan sobre sus hombros gran parte del desarrollo.
- Hay "zonas delicadas" en el código, que sólo algunos pocos iluminados son capaces de entender y tocar.
- Hay información secreta o datos que conocen pocas personas.
- 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.
- Hay pocas personas con implicación real en el proyecto o el equipo está muy desmotivado.
Para mejorar el bus factor se pueden tomar una serie de medidas, principalmente relacionadas con mejorar la comunicación y hacer que la información y conocimiento esté lo más distribuido posible entre los miembros del equipo. Algunas prácticas que podrían ayudar a ello son:
- Mantener al equipo continuamente actualizado sobre el avance del proyecto. Por ejemplo, los stand-up meetingsde 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, pair 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 algo más adelante, ya estamos tardando en replantearla. 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, imaginad un proyecto que tira adelante con un único desarrollador. Aumentar el bus factor 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 sucediera.
Publicado en Variable not found.
_______________________________________
Referencias y más información en:
- Presentación sobre Bus Factor
Israel Alcázar - What’s the bus factor of your software project? (+ Bus factor calculation tool for Github)
Jordi Cabot - ¿Es posible evitar que solo unas pocas personas tengan el 100% del conocimiento de un proyecto?
Javier Garzás - Bus factor
Wikipedia