archivo

Archivo de la etiqueta: sprint

Mientras el producto no esté en producción y, por tanto, no empiecen a llegar incidencias con diferente grado de prioridad y en cualquier momento, puede resultar relativamente sencillo mantener un determinado nivel de predecibilidad en los sprints, de manera que salvo errores importantes en las estimaciones se ejecutarán la mayor parte de las historias de usuario o incluso todas ellas.

Sin embargo, en el momento en que empiezan a llegar incidencias, la cosa cambia. Si no tienes capacidad de “reserva” para afrontarlas tocará tomar determinadas decisiones y para ello nos podemos hacer una serie de preguntas:

– ¿Dejo las incidencias para el siguiente sprint?.

Dependerá de la urgencia de las mismas y de lo que queda para que finalice el sprint, habrá veces en que se pueda aplazar al siguiente sprint, otras en las que incluso se dejará para más adelante y otras donde la criticidad haga que tengas que ponerte con ellas nada más conocer de su existencia.

– ¿Anulo el sprint e inicio uno nuevo en el que ya tenga en cuenta estas incidencias que han llegado?.

En este caso dependerá del número de incidencias y de su complejidad (además, como es lógico de su criticidad). Si vamos a tener que dedicar gran parte de la capacidad a trabajar en ellas, mantener el sprint definido deja de tener sentido. ¿Es la solución definir un nuevo sprint? Sí, pero en situaciones de inestabilidad, tal vez lo mejor sea que tengamos más peso de Kanban que de Scrum.

– ¿Cambio alcance del sprint de manera que sustituyo la realización de determinadas historias de usuario a cambio de las incidencias?.

Puede ser bastante práctico pero dependerá de las incidencias que lleguen porque si terminan desvirtuando el sprint, tal vez lo mejor sea cambiar de enfoque.

– ¿Introduzco las incidencias como parte del alcance del sprint, retrasando la finalización del mismo?.

La respuesta es similar a la anterior y dependerá también del contexto y situación del proyecto, de las incidencias y de lo que pueda aportar a la productividad de los equipos y a la efectividad de los trabajos mantener inamovibles la fecha de finalización de lo sprints.

Lo que quiero que saquéis como conclusión es que no es posible formular una solución que valga para todo. Tenéis que analizar qué os conviene más y siempre con una mentalidad abierta, más allá de la ortodoxia de la aplicación de una determinada estrategia o metodología.

No obstante, puede ser interesante, aún no siendo tampoco una solución universal, dejar siempre capacidad libre del equipo para atender a estas incidencias, de manera que no sea necesario mover el alcance del sprint salvo situaciones de saturación. Esa capacidad variaría en función de la estabilidad del producto y de las implantaciones (y de su importancia) que se estén realizando en ese momento.

¿Y si no se usa esa capacidad? Esa capacidad sobrante se puede utilizar para muchas cosas, desde tareas propias de infraestructura, programación por pares, realizar actividades opcionales sobre determinadas historias de usuario, etc…

Es cierto que hay determinadas metodologías que recomiendan que los sprints tengan una duración que se encuentre comprendida en un intervalo de tiempo reducido. Estoy de acuerdo con ellas en que las iteraciones deben ser de corta duración, sobre esa base, mi visión personal es la siguiente:

– Cada proyecto se desarrolla en unas circunstancias y un contexto diferente. Una duración de sprint que resulta adecuada para uno puede no serlo para otro.

– Lo ideal podría ser aplicar sprints de duración fija pero en la realidad resulta complicado ajustarlo de esa manera ya que hay que tener en cuenta diversos factores: falta de disponibilidad en unas fechas concretas del product owner, la necesidad de tener un sprint algo más largo para incluir una funcionalidad esencial, la necesidad de un sprint más corto para solo incluir determinados ajustes, etc… No hay que cerrar las puertas, ni mucho menos a definir sprints de tamaño variable (eso sí, cada sprint tendrá su fecha de inicio y de fin que deberá ser respetada) por mucho que eso se considere poco ortodoxo en la teoría.

Sprints de corta duración permiten dar una rápida respuesta al cambio y obtener feedback cada poco tiempo, esa rápida respuesta no solo es consecuencia de que disminuya el tiempo necesario para llegar a producción sino también por el hecho de que se reduce tiempo de espera para trabajar sobre una funcionalidad no contemplada en el sprint (el tiempo de espera medio es la mitad de la duración de la iteración).

Ahora bien, sprints cortos requieren que el proceso de paso a producción sea rápido porque de lo contrario parte de las ventaja (sino toda) de las iteraciones cortas se quedan en nada. Esta situación no es posible en todas las organizaciones.

Sprints más largos se adaptan mejor a ese inconveniente y admiten más carga de trabajo (proporcional al tiempo).

Ambas soluciones tienen sus ventajas e inconvenientes pero podemos jugar con ellas en función de las necesidades que tenga el proyecto en cada momento, ya que no es ágil cerrarnos en banda a una duración determinada porque estaríamos priorizando la metodología a las necesidades del proyecto y del producto.

Si no has probado a hacer un seguimiento del sprint utilizando un gráfico de burndown te recomiendo que lo hagas porque te permitirá detectar desviaciones de manera temprana y poder tomar decisiones que permitan eliminarlas o paliarlas en el caso de que se considere necesario (y se pueda).

El concepto es igualmente aplicable a ciclos más largos o a otras estrategias de desarrollo, si bien, resulta maś efectiva en contextos donde el nivel de acierto en las estimaciones sea más alto.

El burndown por otra parte no puede ser más simple, en el eje X tenemos la división en días del sprint (puedes poner día 1, día 2, etc… o fechas reales) y en el eje Y el esfuerzo restante para terminarlo, en la unidad de medida que se considere (horas, jornadas, puntos por historia, etc…). Sobre esa gráfica se dibuja una recta que representaría la proporción entre el esfuerzo restante en el proyecto con respecto al día de desarrollo suponiendo que el nivel de avance es lineal.

Lo realmente importante es la segunda línea, la que representa el avance real y que se calcula a partir del tiempo que resta para la finalización de cada tarea o historia de usuario (en función del grado de desagregación que hayas decidido utilizar). Los momentos en que esta segunda línea esta por encima de la recta representa retraso respecto a lo previsto y cuando está por debajo representa un adelanto.

Como podéis ver su mantenimiento es muy simple y los desarrolladores no tienen que realizar ningún esfuerzo significativo para ir actualizando estos datos, si bien deben ser objetivos a la hora de estimar el esfuerzo restante ya que de lo contrario se estarán tomando decisiones a partir de datos incorrectos.

Si un proyecto puede presentar problemas presupuestarios cuando se prevé un alcance y una complejidad mayor que cuando se hizo su estimación económica, la solución debería pasar, no por intentar meter todas las funcionalidades con calzador, sino por tratar de buscar una solución más racional que permita obtener un producto que satisfaga las prioridades que se han establecido con un alto nivel de calidad, aunque esto implique dejar fuera o para más adelante (en muchos casos es necesario gestionar con los responsables funcionales el síndrome de la última versión), otra serie de funcionalidades que pueden resultar interesantes.

El primer paso debería consistir en dividir el proyecto en diferentes entregas, siendo conscientes todas las partes de que el desarrollo será iterativo incremental porque del feedback de cada versión vendrán, muy probablemente, solicitudes de mejora por parte del área usuaria.

Si se trata hacer todo de golpe se correrá el riesgo de que se agote el presupuesto y que en medio del proceso de desarrollo se entre en un conflicto entre las partes sobre cuál será el alcance final.

La experiencia dice que por muy buen acuerdo que se alcance se verá afectada la calidad del software porque el proveedor tratará de minimizar pérdidas, porque los desarrolladores tendrán overtime y llegado a un punto el cansancio y las ganas de terminar darán lugar a precipitación que se traduce en deuda técnica y en un producto menos probado.

Por otro lado, el cliente tendrá una mayor desconfianza y la comunicación entre las partes, tan necesaria en un proyecto de desarrollo de software, perderá fluidez y en función del grado de desgaste en las relaciones podría dar lugar a situaciones del antipatrón “arrojar al otro lado del muro“.

También se puede agotar el presupuesto con el enfoque iterativo incremental, la diferencia está en que al reestructurar el proyecto de esta manera todas las partes conocen las reglas del juego: se trabaja así no solo porque sea el enfoque que mejor pueda convenir al proyecto sino porque permite gestionar de manera adecuada las prioridades, el seguimiento y consumo económico del proyecto.

El siguiente paso consiste en trabajar con pila de producto e historias de usuario. Los responsables funcionales priorizan estas historias que una vez tasadas y ajustadas a la capacidad del sprint, se convierten en lo que será el resultado final de la entrega.

Si no lo ves claro (y también si lo ves claro), no dudes en dividir el proyecto en partes y cada parte en componentes o trabajos más simples (historias de usuario). Será más manejable, te beneficiarás el feedback y la gestión económica será mucho más transparente y mejor entendida entre las partes.

Es razonable definir plazos. De hecho si aplicamos sprints, éstos tienen una fecha de finalización.

La metodología definida en una organización puede exigir la entrega de determinada documentación asociada al proyect sea o no documentación que resulte necesaria para el trabajo a diario en el proyecto.

Puede ser deseable que los ítems necesarios para el proyecto puedan cubrir las necesidades de la organización pero en cualquier caso, quien se encarga de definir los procedimientos de trabajo es el que tiene que valorar el coste de exigir determinada documentación que se puede considerar adicional a lo que se está necesitando.

Lo que veo todavía más discutible es el hecho de exigir plazos a una documentación dentro de un sprint. Sí que puedo entender que se fijen fechas tope y que el equipo de proyecto pueda jugar con ellas, pero exigir fechas concretas para cada uno de ellos dentro del sprint me parece excesivo y contraproducente.

Hay que entender a la organización y sus procesos, pero no debemos olvidar que el fin último de cada proyecto es entregar un software de calidad y la documentación no es condición necesaria ni suficiente para ello.

Una de las principales ventajas que tenemos si trabajamos con pilas de producto, además de tener un registro de todo lo que está pendiente por hacer (hasta el momento e independientemente de que se hagan todas o no, ya que seguirán apareciendo nuevas historias de usuario y otras se descartarán por la propia evolución del producto), es que el product owner o los responsables funcionales tienen todo un inventario de tareas que poder elegir, sobre las cuales deberán aplicar una prioridad, conociendo de antemano (puede ser pactado en función de las necesidades del sprint) cuál es la capacidad de trabajo máxima que se puede asumir en el sprint.

Independientemente de que después se afine el número de jornadas de cada historia, es fundamental (al menos lo pienso así) que cuando los usuarios están priorizando (o repriorizando) sepan cuánto peso va a tener cada una. De esta forma, tienes una lista de la compra (las historias de usuario), un presupuesto y se deberán quedar con lo que realmente les resulta más prioritario o más adecuado en este momento.

De esta forma los usuarios son conscientes realmente de la cantidad de trabajo que se puede asumir en un sprint y ellos mismos son responsables de elegir lo que se va a hacer.

Se requerirá algo de tiempo para que entren en la dinámica de los sprints y de que no deberían haber cambios mientras se está ejecutando, si bien, no debemos cerrar la puerta a excepciones debidamente justificados, aunque de esta manera perdamos pureza si aplicamos prácticas de Scrum (os recuerdo que las prácticas y metodologías son útiles pero no debemos olvidar que una de las bases del agilismo es la adaptación al cambio y a los contextos).

Me estoy encontrando con algunos proyectos en donde el seguimiento de una determinada metodología o de un conjunto de prácticas se antepone a lo que realmente se necesita.

Sprints de dos o tres semanas por tratar de seguir las recomendaciones de Scrum, trabajando sin historias de usuario sólidas, sin tiempo para refinar la pila de producto y sin tener todavía una perspectiva del proyecto.

Después pasa lo que pasa y hay que escuchar los comentarios de siempre: “los desarrollos ágiles no mejoran nada, incluso lo empeoran”, “se ha perdido mucho dinero en proyectos desarrollados con Scrum”, etc…, sin entrar a valorar si realmente las prácticas aplicadas se adaptaban a lo que necesitaba el proyecto y si la actitud ha sido realmente ágil.

El feedback es la clave, todos lo sabemos, pero para sacar verdadero provecho es necesario que se trabaje con intención, es decir, con una cierta base, tirando a dar. Si hay que tirar todo lo desarrollador en el sprint (y parte del trabajo generado en otros previas), se tira, pero que no lo sea por probar sistemáticamente a ver qué pasa.

Ya lo decía Séneca: “A los que corren en un laberinto, su misma velocidad los confunde”.