Sobre Dioses y Procrastinación: Gestión ágil de proyectos

Compartir esta publicación

Tabla de contenidos

El año era 2001. Una nueva metodología aparecía en una, todavía joven, aunque en proceso de maduración, industria de desarrollo de Software. Llegó con el manifiesto por el Desarrollo Ágil de Software. El nuevo método, gestión ágil de proyectos, apareció para romper con la antigua, estricta, rígida, estrecha y profunda jerarquía en la cual el desarrollador estaba demasiado lejos del usuario final.

Rápidamente se ganó la confianza de unos, sin embargo otros la seguían ignorando. El gestión ágil de proyectos se pasó década y media ganando popularidad, convirtiéndose, hoy mismo, en una de las mayores tendencias y muchas de las empresas claman haber adaptado y aplicado sus principios. Eso es cierto, sin embargo casi siempre de una manera modificada o corrupta.

La mayoría de nosotros en desarrollo de software, hemos estado en diferentes equipos y proyectos, en algunos con el rol de desarrolladores, otros como team leads y en algunos incluso como managers. Hemos tenido que hacer frente a las expectativas de los clientes en eventos kick-off, descifrando Criterios de Aceptación y Wireframes, definiendo el MVP, aceptando cambiar los requerimientos y modificando el Scope en medio del Sprint. Nos equivocamos y aprendimos de la manera más dura, errores que no deberíamos volver a repetir. Sin embargo, los seguimos viendo en nuestros equipos, cuando visitamos a clientes o con gente exterior con la que trabajamos, etc. Esto será sobre lo que voy a hablar hoy, los problemas más frecuentes entre los managers – el equipo de developers y la Gestión ágil de proyectos

Gestión ágil de proyectos

Entrega justa de un proyecto dando más recursos a tu equipo

Observas la estimación para un sprint y te das cuenta de que tu equipo está 16 horas más atrasado de lo esperado. No parece que haya ningún problema, tienes un desarrollador que ya ha acabado con su proyecto, ayudando al equipo durante un par de días para volver a traer el proyecto dentro de los plazos estipulados.

Arquitectura android: repensando MVP en Android

Haciendo esto, posiblemente nunca se entregue el proyecto a tiempo, Porque? El error esta en pensar que el trabajo de un desarrollador de software es facil y automatizado. Sin embargo, no es así. Incluso si esta familiarizado con el lenguaje y las tecnologias que se utilizan en el proyecto, todavía le es necesaria una introduccion al trabajo, que se ha hecho, documentación, wireframes revisados y una larga lista de detalles. Ademas de que la productividad de este desarrollador será más baja de lo normal (al menos durante el principio), necesitará ser asistido por el resto del equipo para que le enseñen todo lo listado anteriormente. Una tarea que normalmente es asignada a una persona en particular. La realidad es que la productividad de esta última persona tambien caera en picado, ya que contará con una distracción extra y deberá utilizar más horas ayudando y enseñando al nuevo miembro del equipo.

La ley de Parkinson

Al principio, la Ley de Parkinson, tenía un significado distinto. Hoy está basado en “El trabajo se expande para completar el tiempo esperado de su finalización”. Dado un ejemplo, digamos que tenemos un problema de rendimiento en un proyecto, asignamos a nuestro mejor desarrollador el problema para que pueda investigar sobre el caso, trabajar en ello y arreglar los posibles fallos. Para ello, decidimos darle una semana de tiempo.

La ley de Parkinson no siempre está presente en un desarrollador, algunas veces es más fuerte y otras más débil. Ahora la libertad de tiempo en un proyecto, especialmente si no se tiene una clara fecha de entrega, tenderá a hacerse cada vez más grande. Ocupando finalmente todo el tiempo disponible para ello. Otras veces es incluso peor, donde las posibles soluciones dan a una mayor complejidad de la necesaria (Over-engineering). Para evitar esta situación, la tarea ha de estar marcada por unas pautas y criterios muy específicos, o de lo contrario, reuniones frecuentes donde se den a conocer los resultados a tiempo real.

Desmitificando Redux

Diversos proyectos en diferentes equipos

Aunque puedas encontrar millones de artículos ahí fuera sobre cómo triunfar aplicando metodología Agile a tus equipos, gestión ágil de proyectos, hay que tener en cuenta, la distribución de tareas, entendimiento del tiempo y la diversidad en la cultura dentro del equipo, etc… no todos ellos pueden decir que esa metodología haya funcionado en ellos. Especialmente cuando cada uno de los desarrolladores, a su vez, forma parte de otros equipos. En el intento de hacer de los desarrolladores un “todoterreno”, acaban trabajando en diversos proyectos al mismo tiempo. Por ejemplo, Lunes y Martes proyecto A, y Miércoles y Viernes en el proyecto B.

Probablemente hayas oído hablar del developer’s focus. Ocurre cuando un desarrollador está siendo productivo, si pierde la concentración, le cuesta bastante trabajo volver a ponerse con la misma productividad que antes.

Pues lo mismo ocurre mientras se intercambian equipos y se chequea los avances mientras se ha faltado. Aunque algunas herramientas ayudan a mitigar el problema, como Dailies, Jira o Trello, se sigue dejando por el camino un porcentaje de esa productividad.

Es fácil discrepar sobre esto, pero por principios, yo defiendo los 6 principios del Manifiesto Agile, para ambos aspectos, tiempo y espacio.

“La manera más eficiente y efectiva de transmitir información en un equipo de desarrollo es cara a cara”.

La presión del tiempo aumenta la productividad

Es sorprendente cómo de común es entre compañeros de trabajo, descubrir que muchos de ellos comparten las más oscuras experiencias de trabajo. A menudo en una startup o compañía pequeña, con un gran manager que les hizo “creer en ellos mismos y en el producto”, desencadenó en un sin fin de horas extras, stress y entregas imposibles de conseguir. Cómo desarrolladores aceptar estas condiciones, únicamente ayuda al manager a presumir que su equipo es productivo, a cambio de que el ratio de tiempo en las entregas es bastante alto.

En realidad, la productividad del equipo puede considerarse alta, siempre y cuando no tengas en cuenta la calidad del trabajo hecho, las horas extra (no pagadas). Estas condiciones desarrollan en estos dos resultados:

Bunkerización avanzada

Primera, la calidad del código. Esto significa más bugs que pasan entre el código (no hace falta explicar que un bug es mil veces más caro solucionar para una compañía, que el tiempo empleado en hacer un buen código para evitarlo), errores en el test coverage, la funcionalidad es implementada parcialmente, etc.

Bajo la presión del tiempo, los desarrolladores no van a trabajar mejor, sino mas rapido. La ecuación es cantidad sobre calidad.

Segundo, llegado un punto el desarrollador se rinde y se retira. Una vez se da cuenta de que las cosas no van a cambiar, y que es una actitud enfermiza con el trabajo y compromiso hacia la empresa, se irá buscando mejor suerte a otro lugar. Normalmente, el primero que se va es el que soportaba una mayor presio. El que sabe que hay una solución mejor para el trabajo a realizar, y adivina que, ese es el único que no se puede dejar escapar!

Para acabar en el artículo, me gustaría resaltar la conexión entre el código con el que trabaja un desarrollador de software y su motivación. Normalmente, desarrollo de software es algo que “paga las facturas”, es una pasión. Para un desarrollador, tener la oportunidad de trabajar con un código de calidad es una subida de motivación. Quítale eso, y te has quedado sin motivación para una gestión ágil de proyectos.
Y cuando la función principal de un manager es mantener la productividad alta, no suele salir muy bien. Sin embargo, cuando la calidad es el foco de atención, la productividad sube a unos niveles extraordinarios.