archivo

Archivo de la etiqueta: estabilidad

Las iteraciones o sprints requieren estabilidad, cambios en los requisitos te pueden destrozar el sprint. Si hay alguno de los objetivos que debe variar respecto a como se han especificado lo mejor es no llevarlo a cabo y dedicar ese tiempo a hacer alguna tarea contemplada en la pila de sprint con una prioridad menor y que no se tenía claro si iba a dar tiempo o no a realizarla.

En el caso de que no haya tareas de ese tipo (no se incluyen en el sprint tareas del tipo “por si acaso”), lo mismo hay que aprovechar ese tiempo para realizar alguna tarea de índole técnico en el proyecto (siempre habrá alguna que realizar: refactorización, mejora de la deuda técnica, mejorar la automatización de testing, mejorar los procesos de instalación, etc…) o para estudiar con más detalle algún aspecto funcional que no se termina de tener lo suficientemente claro.

Iteraciones o sprints demasiado largos están sometidos más tiempo a la incertidumbre y por tanto se incrementa la posibilidad de que haya cambios en las especificaciones (en muchos casos sin excesivo fundamento, solo por el hecho de que al responsable funcional, Product Owner o usuario se le ha ocurrido algo nuevo sin tener como elemento comparativo una versión del software funcionando con las funcionalidades que inicialmente comentó y que se iban a llevar a cabo en esta evolución).

Necesitamos estabilidad en las iteraciones pero las mismas deben tener la duración que se considere más adecuada para el proyecto en el que estamos trabajando, hay que jugar con ambas variables para intentar encontrar el punto más óptimo.

Desarrollar software requiere una cierta estabilidad, todavía más si cabe cuando el proyecto es complejo e intervienen diferentes equipos de trabajo.

Estabilidad no es renunciar a la adaptación al cambio, sino es mantener una línea de trabajo y una coherencia. Claro que es posible elegir lo que se va a desarrollar en la próxima iteración, aunque eso suponga rehacer funcionalidades ya implementadas. Lo importante es que el responsable funcional conozca las consecuencias y el coste y asuma sus responsabilidades como también debe hacerlo el equipo de desarrollo en caso de que se equivoque.

Los bandazos son el resultado de que se produzcan con frecuencia: cambios de prioridades o parones dentro de un sprint, parones entre iteraciones, cambios de interlocutores, cambios de enfoque radicales en las expectativas u objetivos del proyecto, cambios en capacidad de esfuerzo que puede asumir el equipo, etc…

No se trata, insisto, de eludir o rechazar la adaptación al cambio, se trata de que los cambios sean razonados y no fruto de caprichos o negligencias.

Los equipos para poder rendir de manera adecuada necesitan tener un ritmo. Las paradas y arranques, los continuos cambios de criterio, no benefician en nada a la capacidad de producción de los equipos y al proyecto e inciden en costes evitables ya que todo camino iniciado y no culminado requiere de nuevo volver al punto de origen y eso no es gratis.