archivo

Archivo de la etiqueta: pila de sprint

Si se fija al final del sprint una demo o una entrega es necesario dedicar tiempo al testing cuando se hayan finalizado las tareas fijadas en la iteración (previamente los mismos desarrolladores han debido probar el código que han hecho y si hay equipo de testing han debido colaborar en esas tareas conforme se va trabajando) además de otras tareas como puede ser la propia preparación de la entrega (si hay paso a producción o si la instalación en un entorno de demo lo hace un equipo distinto).

Esto quiere decir que la fecha final de los trabajos de desarrollo en la iteración debe ser anterior a la fecha de finalización del sprint. Otra posibilidad es considerar esas tareas de testing como una actividad más dentro de la pila de sprint. El tiempo que se debe dedicar a esta actividad no debe ser exclusivamente el necesario para hacer el testing sino que hay que prever un tiempo para corregir incidencias, ese tiempo lo determinará el equipo en función de la deuda técnica, de la complejidad de las funcionalidades desarrolladas en el sprint y del estado actual del equipo de proyecto (si ha habido cambios en el equipo existirán más posibilidades de que se hayan producido incidencias).

En cualquiera de los dos casos se reduce la cantidad de trabajo que se puede abordar en la iteración pero siempre será mejor eso que entregar software deficiente porque supondrá una resistencia para la próxima (o próximas) iteraciones.

Si aplicamos las prácticas de Scrum de pila de sprint y que la misma no se debe modificar una vez definida e iniciados los trabajos nos encontramos ante una situación problemática si aparece una urgencia que es necesario tratarla a corto plazo.

Antes de nada lo que hay que hacer es analizar lo crítica que es la urgencia o lo que es lo mismo, ¿puede esperar a que terminemos el sprint y se pueda tratar en el siguiente?. Esto es importante porque no todo lo que parece urgente lo es realmente como para tener que romper una dinámica de trabajo.

Si efectivamente no puede esperar, tenemos que adaptarnos a esa circunstancia, ya que sería mucho más perjudicial no hacerlo. No sería ágil aferrarnos a la metodología.

¿Qué hacemos?

Hay diferentes alternativas y a priori ninguna tiene que ser necesariamente la mejor, ya que sería necesario conocer las circunstancias concretas del proyecto.

– Se anula el sprint y se inicia uno nuevo con esa tarea y las del anterior sprint que se consideren convenientes (como mínimo las que ya estén terminadas).

– Se intercambian tareas ya definidas en el sprint por la nueva tarea, teniendo en cuenta que el esfuerzo restante en las mismas debería ser mayor o igual que el de la misma tarea.

– Lo mismo pero considerando la nueva tarea fuera del sprint, es decir, se resta capacidad de la línea de trabajo para asignársela a la nueva tarea para pasar el cambio a producción cuanto antes.

– Similar al caso anterior pero realizada por una persona de fuera del equipo (esto solo funcionaría con tareas que no requirieran un conocimiento profundo de la arquitectura, tecnología o el negocio).

– Se incluye la nueva tarea y se alarga la fecha de finalización del sprint.

Y seguro que se os ocurren otras tantas. Y os digo lo de siempre, lo importante es el producto no la metodología.

Otra estrategia puede consistir en prever que este tipo de circunstancias se pueden producir en el proyecto, para ello os recomiendo leer los siguientes artículos:

Incidencias e iteraciones I.
Incidencias e iteraciones II.

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).

Otra circunstancia que puede darse es que tengamos en la pila de producto historias de usuario suficientes para completar la capacidad de trabajo del sprint, pero que muchas de ellas no se consideren prioritarias o lo sean bastante menos que otras que todavía no se han terminado de definir por completo, pero sobre las que se sabe que durante el período de ejecución del sprint van a terminar de completarse y que va a haber tiempo para abordar algunas de ellas.

No se trata en este caso, no tanto de no poder esperar sino de tratar de conseguir siempre el mayor valor posible del producto con respecto a la cantidad de esfuerzo invertido. Lo fácil sería tomar la decisión de trabajar sobre las historias de usuario que están definidas, incluso en muchos casos será la decisión acertada, pero no podemos cerrarnos a la posibilidad de que en determinadas circunstancias lo aconsejable sea dejar la pila de sprint abierta con una capacidad reservada para la realización de estas tareas.

En este caso, hay que anticiparnos con el objetivo de no desperdiciar capacidad de trabajo, de manera que si finalmente no da tiempo de definir algunas historias de usuario, se opte por trabajar con las que están definidos.

¿Y por qué no se han tenido definidas esas historias de usuario antes? Pues porque no siempre se puede, por mucha voluntad que le ponga el product owner o el equipo de desarrollo. Lo mismo uno y otros han tenido que dedicar su esfuerzo en otros objetivos del proyecto que hasta ahora han sido más prioritarios o el product owner ha tenido que consultar con terceros determinadas decisiones que le trascienden y cuya resolución se mueve en unos tiempos distintos al del proyecto y sus sprints.

Tener la pila abierta de esa manera es poco ortodoxo, lo sé, pero cada proyecto tiene sus propias circunstancias y en base a ello tanto el product owner como nosotros tenemos que tomar decisiones, con fundamento, con intención, evitando la arbitrariedad, siempre pensando en lo que más conviene al proyecto y al producto y con la mente abierta a hacer excepciones puntuales o no tan puntuales sobre la estrategia que venimos aplicando.

Hemos visto que un motivo puede ser la resolución de incidencias, bien porque no se ha previsto capacidad para resolverlas o incluso haciendo la previsión porque su volumen y/o complejidad, lo supera. No es la única circunstancia que nos puede llevar a modificar el alcance del sprint pero en cualquier caso, el product owner debe participar en la decisión como responsable de la línea de desarrollo del producto.

Otro posible motivo puede ser que el mismo product owner, una vez pactado el alcance del sprint, quiera que se trabaje sobre una historia de usuario no contemplada inicialmente. La experiencia del product owner resulta esencial para determinar si efectivamente es tan necesario ese cambio, porque supondrá una variación de los compromisos definidos, ya que para que una historia de usuario entre, otra u otras tienen que salir.

Lo de la experiencia lo digo no solo por su capacidad de acertar o no, sino por el hecho de que el desarrollo necesita estabilidad (siempre que sea posible y las circunstancias lo permitan) y los cambios de criterio no ayudan a conseguirla y, además, hay que tener en cuenta que los sprints son de corta duración y que el tiempo de espera para afrontar la tarea o tareas no contempladas no será excesivo.

También es posible incrementar la capacidad del equipo pero sabemos que las circunstancias que se tienen que dar para que eso sea efectivo son muy especiales, ya que generalmente este tipo de estrategias para conseguir objetivos a corto plazo no suele dar buenos resultados. ¿En qué casos puede funcionar? Reduciendo la capacidad de trabajo dedicada a la corrección de incidencias o incluyendo personas que por algún motivo han salido del proyecto no hace mucho tiempo y que controlan la tecnología, la infraestructura de desarrollo y determinados aspectos del negocio.

Personalmente soy partidario de tener pilas de sprints cerradas porque eso quiere decir que se han trabajado las historias de usuario y que se dispone de toda la materia prima necesaria para ejecutar el proyecto. Además representa predecibilidad, con lo complicado que resulta eso en el desarrollo de software, ya que es el reflejo de una serie de compromisos del equipo de desarrollo con respecto al product owner dentro de la capacidad de trabajo que se puede asumir.

Para darle un tratamiento a las incidencias soy partidario de la existencia de personas, fuera del alcance del sprint, que se encarguen de ellas (no quiere decir que sean personas que específicamente se encarguen de esto, ya que podría ser válida la decisión de reservar una capacidad concreta del equipo de proyecto sobre el total para la realización de estas tareas). De esta forma, el cumplimiento de los compromisos no se debería ver afectado por la resolución de las incidencias (aunque esto es teórico porque una incidencia mal corregida o de gran impacto puede afectarle).

En el caso de que no llegasen incidencias en número y complejidad que consuman la capacidad disponible, siempre se puede aprovechar ese tiempo para trabajar sobre el sprint y ayudar al cumplimiento de los compromisos, además de realizar otro tipo de tareas que pueden resultar positivas: refactorizar código para reducir deuda técnica, realización de testing, automatizar pruebas, hacer mejoras sobre la infraestructura de desarrollo, etc…

Pero independientemente de que mi preferencia sea esa, soy de la opinión de que siempre hay que estar abierto a las circunstancias que se puedan producir en el proyecto y que si hay que abrir la pila de sprint, hacerlo.

Dependerá de si prefieres utilizar prácticas de Scrum o de Kanban, o de incluso si utilizas prácticas de ambas.

En el mundo real, es complicado ser muy ortodoxo con las metodologías y no es cuestión de ser más o menos disciplinado, ya que puedes tener unas ideas concretas sobre qué prácticas aplicar y después que las propias circunstancias del proyecto que te obliguen a cambiar sobre la marcha.

Sí que es conveniente trabajar sobre una idea pero es necesario ser flexible cuando las circunstancias lo aconsejen. De lo contrario estamos poniendo a la metodología sobre el producto y sabemos quién sale perdiendo cuando eso sucede.

Scrum parte de la idea de tener pilas de sprint cerradas. ¿Qué hay que corregir incidencias? No podemos ponernos una venda en los ojos cuando son críticas (si no lo son, se podría esperar a una de las siguientes iteraciones y contemplarlas como una tarea más dentro de la pila). Ante esta situación se puede renunciar a alguna de las historias de usuario comprometidas y dedicar el tiempo a solucionarlas o se ha podido prever la existencia de una o varias personas fuera del sprint dedicadas a hacer este tipo de tareas y que durante o al final del sprint (mejor cuanto antes) sincronizan o integran su trabajo con la línea base del producto.

En el ejemplo anterior, en una de las posibles soluciones, le hemos quitado la llave a la pila de sprint y sustituido una o más historias de usuario por una o más incidencias de carácter crítico (realmente se trata de una decisión a tomar en la que el carácter crítico de la incidencia puede influir más o menos) y no pasa nada, no por ello somos menos diligentes con la metodología, simplemente se han dado unas circunstancias y nuestra decisión, acertada o no, ha sido esa.