Ingeniería de Software de Élite

Muchos desarrolladores de software padecemos el “God Complex”: creemos que todas nuestras decisiones son acertadas y sabemos más que todos. También, que podemos resolver los problemas con poca o nada de ayuda.

Ágil parte de un hecho: empezamos a implementar la solución sobre un problema que ya comprendimos en su mayoría y lo que se descubre es el cómo resolverlo mejor.

Por eso, aquí te dejo tres recomendaciones de lo que debes entender bien antes de comenzar el desarrollo de un producto de software.

En nuestras observaciones, hemos encontrado que dan mejores resultados si los equipos se concentran en uno o dos temas a la vez y los atienden respondiendo cinco preguntas.

La retrospectiva es una práctica que aporta valor en la mejora continua, sin embargo he visto que muchos equipos evitan la práctica, los ingenieros prefieren ausentarse a la reunión porque la ven como pérdida de tiempo o, simplemente, le temen. Esto ocurre porque la actividad se ha distorsionado y ya no sirve para su propósito.

Esto es lo que nunca debes hacer en una retrospectiva.

Mi respuesta, desde hace algunos años, ha sido esta: todos y ninguno.

Aunque escuches y leas de los casos de éxito que ha tenido Scrum, de lo fantásticas que son los métodos de Netflix y Spotify, de lo terrible que es Waterfall (cascada) y de que solo Ágil puede funcionar, es una mala idea intentar copiar la forma de trabajo definida por otros y aplicarla así en nuestro equipo.

En esta ocasión te hablaré de lo que ocurre cuando los miembros del equipo colaboran activamente en establecer acuerdos, que les permiten obtener buenos resultados consistentemente.

Recuerda que el trabajo de software depende, en gran medida, de las interacciones entre las personas. Cuando los integrantes del grupo trabajan, saludablemente, en crear acuerdos, observarás que ocurre lo siguiente.

El Driver de la agilidad "Organización del equipo" procura la autonomía y la autodirección de los equipos de software. Es decir, que los equipos acuerden una forma de trabajo que les sirva. Si esto no se realiza adecuadamente, veremos algunos síntomas de un mal trabajo de desarrollo, como los siguientes.

¿Qué es más importante para un ingeniero de software, programar bien en el lenguaje de programación o saber ortografía y redacción en su idioma?

Aquí te comparto algunos de los aprendizajes que he obtenido al respecto a lo largo de mi carrera, que te ayudarán a conseguir equilibrio.

No aprendas a usar el framework haciendo el sistema

No apliques religiosamente una metodología

No elijas la tecnología antes de entender el problema a resolver

Asume roles activamente dentro del equipo

La influencia en los resultados proviene de cinco aspectos y en la capacidad de desempeñarlos bien o la ausencia de estos. Los llamamos "Drivers para el alto desempeño" y te cuento cuáles son.

Un equipo de trabajo con el que colaboré, estaba conformado por 7 personas (6 desarrolladores y 1 líder). El equipo comentaba que estaban muy ocupados y no podían iniciar trabajo con clientes nuevos con rapidez. También, se quejaban de que no les autorizaban contratar más personas, que pudiesen ayudarles a crecer su capacidad de producción. El equipo, en los tres meses que colaboramos, perdió un integrante que se fue a otro empleo y no fue reemplazado.

Muchas organizaciones entrarían en una crisis en ese escenario con los proyectos actuales. Sin embargo, el equipo del que les hablo tuvo un mejor resultado: incrementó su capacidad de atender nuevos clientes en 53% en un año, con 6 personas solamente.

El equipo creció sin aumentar la cantidad de integrantes. Otros equipos, en otras organizaciones, crecen en personal, pero no en capacidad en la misma proporción; incluso, algunos la reducen conforme más personas llegan. Hay varias razones para esto, aquí te expongo algunas.

Una vez, un director de empresa me dijo que su producto de software estrella se estaba quedando rezagado:

Tenía varias funciones, pero estaban especializadas en un nicho del mercado.

No podía ofrecerlo a nuevos clientes u otros giros.

No tenían a un encargado, que pudiese identificar nuevas tendencias y necesidades para incorporarlas.

Además, estaban retrasados en el mantenimiento correctivo de varias cosas. Entre otras dificultades de gestión de la configuración, de las que no hablaré el día de hoy.

Varias organizaciones, que desarrollan software para terceros o internamente, enfrentan esta dificultad: la brecha tecnológica (aprovechar al máximo la tecnología) se ensancha en lugar de cerrarse. Por esta razón, todas pierden oportunidades de negocio, pues no pueden vender un producto nuevo o sus operaciones internas se ralentizan porque la tecnología no está ahí para apoyarlas.

A continuación te presento algunas de las razones por las que las organizaciones de software pierden oportunidades de negocio.