archivo

Archivos diarios: marzo 13, 2013

Yo también soy partidario de los sprints cortos: se tarda menos en conseguir un feedback efectivo sobre una versión del producto en producción y se reduce el tiempo medio de espera en la pila de producto de una historia de usuario urgente que no ha entrado en el sprint.

No soy partidario de sprints largos.

¿Cómo corto debe ser el sprint? No tengo la respuesta porque la tienes que encontrar tú en base a tu proyecto y tu contexto.

Un condicionante importante es la capacidad de aguantar el ritmo porque no solo se trata de adecuar la cantidad del trabajo a la velocidad, algo que se consigue en el momento en que todo el mundo (sobre todo el área usuaria o el product owner) está mentalizado en que es la mejor forma de trabajar y se acierta en las estimaciones (importantísimo), sino de tener en cuenta que además hay que ir preparando el siguiente sprint mediante el refinamiento de la pila de producto, que no es otra cosa que obtener el nivel de detalle suficiente en una historia de usuario para poder valorarse de manera adecuada y poder ejecutarse cuando sea posible, mientras se está pasando a producción la anterior entrega, algo que puede ser muy complicado en organizaciones que compartan un equipo de instalación de aplicaciones que esté fuertemente procedimientado, teniendo en cuenta, además, que hay que trabajar de manera priorizada con las incidencias que vayan saliendo.

Es posible que algunas de esas tareas que tienen dependencias externas, como el refinamiento de la pila o el paso a producción se retrase, lo cual hace necesario un mayor esfuerzo para tratar de mitigar en lo posible la desviación, lo que produce un fuerte desgaste cuando esta situación se hace reiterada en los sprints.

Un día, un amigo me preguntó: “¿por qué se le llaman sprints a las iteraciones?”, poco después por sí mismo pudo conocer la respuesta.

¿Realmente se puede decir que el producto está terminado antes de que finalice su ciclo de vida? La realidad es que no es así, incluso en aquellos casos donde se encuentre sin evolucionar durante años.

Es más correcto decir que un proyecto se ha terminado que indicar que el producto está terminado porque lo contrario sería suponer que el producto no va a sufrir más modificaciones.

Precisamente el problema de los responsables técnicos de los sistemas de información (que también debería serlo por parte de los propietarios del producto) es que en cualquier momento pueden surgir necesidades de evolución y lo mismo no hay posibilidades en ese momento de dar respuesta a la misma en la medida y forma que se necesita. Es decir, si tienes una vinculación con el producto y no con el proyecto no vas a poder separarte de él, salvo que cambies de empresa, de departamento o tu jefe te indique otras prioridades (aunque, como sabes, seguirás realizando por mucho, mucho tiempo tareas relacionadas con ese sistema).