Desarrollador individual 10x, bueno o malo?

Información tomada de : Abstractive

Efectivamente, el desarrollador mas productivo es aquel que conoce con un detalle intimo el/los componente(s) de software, debido a que el mismo lo(s) desarrollo. En un curso de Scrum, el instructor a este tipo de desarrollador lo catalogo como un "Rambo", rápidamente responde a los cambios y su productividad es alta. Para los otros miembros del equipo, cada cambio "da miedo" debido a que no conocen las consecuencias que esto involucra y debido a esto gastan tiempo en limitar el alcance de sus cambios para no causar serios problemas a la funcionalidad de la aplicación. Algunas recomendaciones cuando estamos en este tipo de situaciones, pueden ser:

• Considerar no hacer cambios - Esta es la manera mas rápida de desarrollar software, una persona sin coordinación con otros desarrolladores, se puede mover mas rápido que el equipo completo cuando el sistema es pequeño. Cuando el sistema es mas complejo o el sistema es importante para la organización, ya  no es aceptable el riesgo de que una sola persona tenga el control de la aplicación.
• Prohibir las palabras: "fácil","obvio","simple","sencillo". Estas palabras son relativas y cada ser humano tiene un contexto diferente para ellas.
• Siempre realizar pruebas. La experimentación es crucial para entender como un sistema funciona y también esto actúa como documentación.
• Trabajar en pares.Esta es una buena técnica para transferir el conocimiento de una persona a otra.
• Crear un readme.txt del proyecto, se describe de manera breve el propósito del sistema, como se desarrolla, se prueba y la detección de errores. En este documento también se deben de incluir los pasos para realizar la instalación/configuración de la infraestructura necesaria para nuestro desarrollo, se deben de incluir los comandos que típicamente se usan para compilar, probar, leer logs y acceder a la funcionalidad de la aplicación o sus componentes en cada una de las capas.
• Hacer que el equipo de desarrollo conozca también al cliente, no solamente un miembro del equipo, este permite formar canales de comunicación adicionales.
• Bajar la velocidad - Si una persona esta desarrollando a maxima velocidad en un proyecto, es complicado que alguien mas se mueva a esta velocidad y le sume simbiosis al proyecto. Si se integra alguien mas al proyecto no debe de trabajar solo, trabajar en pares. El trabajar el pares "reduce" la velocidad del proyecto, pero a la larga mejorara la velocidad del equipo de trabajo.
• Tomar en cuenta que en algunos momentos del desarrollo de software es posible que una sola persona tenga el control de todo y en algunos momentos se requiere un equipo solido de trabajo. Es decir, en que momento necesitamos un bus factor de 1 y en cuales situaciones no es posible.