archivo

Archivo de la etiqueta: 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 se orienta el desarrollo a sprints (hay que tener en cuenta que el enfoque iterativo incremental es en sí un concepto más amplio) es, entre otros motivos, para conseguir un ritmo sostenible en el desarrollo.

Por eso cada sprint requiere tener preparada de antemano la materia prima, es decir, todos los inputs que necesita para poder ser completado, de lo contrario se tendrá que invertir tiempo en él para obtener esa materia prima, con el riesgo de producirse bloqueos por falta de esas entradas, lo que lo hará menos productivo y menos predecible en cuanto al cumplimiento de los compromisos.

Nos quejamos muchas veces y con razón de la falta de medios económicos para llevar a cabo el proyecto (acorde a las expectativas puestas en él y los plazos) y también de la falta de colaboración del área usuaria. Sobre esto último pocas veces nos paramos a pensar en los motivos que hacen que los usuarios no colaboren.

Uno de ellos puede ser precisamente la falta de medios para proporcionarnos la información y entregables que, una vez interpretados, conforman la materia prima de cada sprint. Es decir, muchas veces el product owner quiere pero no puede.

Se sobreentiende que quien contrata el trabajo ha tenido en cuenta esa carga de trabajo adicional (que en función del tipo de proyecto puede ser muy grande para las personas implicadas), sin embargo no es lo normal, ya que se piensa que con apoyos puntuales es suficiente, creyendo que el equipo de proyecto puede con todo y no, no puede, y si me apuráis, no debe, porque la carga de especificación del sistema debe recaer en el área usuaria.

Las consecuencias de esto es que determinadas tareas del sprint no estarán lo suficientemente definidas y eso hace mucho daño a esta dinámica de trabajo, tanto que nos deberíamos plantear, probablemente, objetivos menos ambiciosos.

Os indico a continuación algunas alternativas y aunque soy de la opinión de intentar reconducir la situación, no siempre va a ser posible:

– Adecuar la capacidad del equipo de proyecto a la carga del área usuaria. De nada vale tener una maquinaria capaz de producir x productos al día si solo entra material para producir x/4 productos.

– Plantear un enfoque iterativo incremental con fases de definición (con el nivel de detalle suficiente para el proyecto y la iteración) entre sprints. En este caso es más impredecible la duración de la fase de análisis pero más predecible la construcción.

– No plantear sprints propiamente dichos y aplicar estrategias de gestión del flujo de trabajo y del WIP (Work in progress), como por ejemplo, definiendo límites en el número de elementos terminados y no pasados a producción o dejando ese aspecto abierto y limitando el número de tareas en fase de análisis.

Cuando se falla en las estimaciones estamos golpeando en la línea de flotación del proyecto y también contra nosotros mismos. Se falla muy a menudo y después toca sufrir las consecuencias porque se adquieren compromisos que costarán muchísimo esfuerzo ser respetados.

¿Por qué nos equivocamos en las estimaciones? Son muchos los factores que pueden influir:

– La incertidumbre inherente que tienen los proyectos de desarrollo de software. Si aplicamos un enfoque iterativo incremental con sprints cortos tiene una menor o nula influencia dentro de ese segmento de trabajo, pero si consideramos el proyecto en su totalidad sí que la tiene cuando hay cambios significativos ya sea sobre las condiciones iniciales o sobre el producto que se lleva desarrollado.

– Se tiende a estimar considerando situaciones ideales y después sabemos que hay problemas.

– Se estima en muchos casos sin conocer suficiente detalle sobre el trabajo a realizar.

– Se estima en muchos casos sin conocer suficientemente las restricciones de la tecnología o del entorno de trabajo.

– No estima quien va a realizar el trabajo.

– La presión del cliente por tener plazos más cortos (y a menor coste).

Estoy seguro de que se os ocurren otro montón de causas que provocan que no se acierte con las estimaciones. Ahora bien, una cosa es que sea difícil estimar y otra que no se intente acertar en lo posible con las mismas porque no queda otra, por ese motivo es importante tomar el control de todos aquellos factores que estén en nuestra mano y que puedan afectar a la calidad de la estimación, esto dependerá como no podría ser de otra forma del proyecto en sí y de su contexto.

Como sabemos los problemas que hay con las estimaciones y que es necesario dar la importancia que se merece al feedback sería recomendable que el cliente pensase más en términos de valor que de agenda, si bien, no resulta sencillo conseguir esas condiciones ya que se mostrarán, por términos generales, reacios a considerar que el presupuesto inicial puede variar después …

En potencia todo, salvo el papel en blanco (y seguro que conocemos casos donde se han realizado estimaciones con un nivel de conocimiento del trabajo a realizar que se aproxima muy mucho a ese papel en blanco), es estimable, sin embargo, lo que queremos son estimaciones que se ajusten lo máximo posible a la realidad y para ello se requiere que cada historia de usuario esté lo suficientemente desarrollada como para conseguirlo.

Vuelvo a insistir en lo que comenté en el artículo de ayer, suficientemente desarrollada no es lo mismo que absolutamente detallada y/o llena de formalismos, sino que se adapte a lo que el proyecto (y su contexto actual) necesite.

Otra cosa es que nos equivoquemos en la estimación, cosa que sucederá sobre todo en los primeros sprints y/o hasta que se tenga dominada la tecnología y entorno sobre el que se va a desarrollar.

¿Para que sirven entonces las reuniones de planificación de sprint? Para terminar de perfilar el sprint. ¿No se hacen todas las actividades necesarias para poder estimar? La base son las historias de usuario y aunque puedas invitar al product owner a participar y aclarar dudas con él, cuando el proyecto se encuentra en una fase inicial o se incorporan funcionalidades con una cierta complejidad, no da tiempo en una reunión de planificación de sprint a tener lo suficientemente claro el alcance de la tarea por lo que la estimación corre más riesgos a lo que hay que sumar las consultas que de forma más que probable habrá que hacerle al product owner durante el sprint y que podrían bloquear determinados trabajos si no se han resuelto antes de que esas tareas se lleven a cabo.

Aplicando prácticas de Scrum y si me apuráis, por puro sentido común, tenemos que tener como objetivo que el resultado de cada sprint sea una versión entregable y por tanto, que se pueda pasar a producción.

Es muy importante desarrollar con intención para reducir el número de iteraciones (o dicho de otra forma para ganar en cantidad de trabajo efectivo por unidad de tiempo o lo que es lo mismo para ganar en productividad), para ello debemos minimizar (siendo el objetivo máximo eliminar), el número de componentes (funcionalidades) defectuosas que llegan al final del sprint (y por extensión a producción).

Para ello cada historia de usuario debe estar completamente terminada. ¿Qué es eso? Desde luego no es programar las tareas en que se descompone la historia y hacer cuatro pruebas, sino de tener la certeza de que efectivamente funciona, lo que implica una buena batería de testing y la verificación de que efectivamente cumple con las expectativas del usuario.

Una primera aproximación a esto último son las medidas para verificar la misma que aparecen en la historia de usuario, en las cuales tenemos que minimizar las ambigüedades para poder dar por bueno o rechazar la misma, ya que no debería haber medias tintas.

Estas medidas pueden estar implícitas en la propia descripción de la historia o separadas en un apartado diferente de la misma.

Otra cosa es que después, el product owner o por extensión los usuarios, se den cuenta de que la especificación realizada no satisface sus expectativas, en este caso el problema está en la especificación y para solucionarlo se requerirá evolucionar (modificar) esa funcionalidad en uno de los siguientes sprints.

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.

Resulta muy tentador comenzar una primera iteración prácticamente desde que se ha dado el pistoletazo de salida al proyecto.

Depende del proyecto, efectivamente. Si se trata de un nuevo aporte económico a otro ya existente y el equipo ha permanecido más o menos estable (tanto por parte de los desarrolladores como de los usuarios) casi que se puede empezar desde el principio, salvo que la evolución a realizar requiera hacer una revisión de la visión que se tenía del producto hasta la fecha y de lo que se preveía que iba a ser su devenir.

Sin embargo, para nuevos desarrollos, para evoluciones significativas de un sistema o para cambios significativos en el equipo de personas que intervienen en el mismo, es necesario hacer una parada para construir una imagen mental de lo que se quiere y que se traducirá en entradas en la pila de producto (que luego se refinará y mejorará conforme vaya avanzando el desarrollo y todas las partes vayan aprendiendo más y más porque las ideas al materializarse y cobrar forma requerirán ajustes y sugerirán algunos cambios de enfoque).

Esta etapa se llama exploración en XP y me parece acertada su denominación, ya que además, contempla la posibilidad de evaluar la tecnología y productos a utilizar durante el proceso de desarrollo.

Ahora bien, esta etapa no debe eternizarse y no conviene traspasar la frontera entre lo que es saber qué es lo que se quiere y obtener un análisis de requisitos detallado (digo que no conviene porque cada proyecto es diferente y tenemos que estar abierto a excepciones) porque de lo contrario habremos invertido (probablemente) esfuerzo que no va a retornar en beneficios, ya que todos sabemos que en el momento en que el usuario empiece a ver producto construido empezará a modificar las bases establecidas.

Tener una visión del producto es otro factor más para desarrollar con intención ya que permite tanto por parte del usuario como por la nuestra tener en cuenta más factores y esto se consigue viendo el producto y los problemas desde una escala más amplia.

Recomiendo la lectura del artículo: Preparando el primer sprint.

Mi recomendación es que las historias de usuario estén desarrolladas antes del inicio del sprint, así como que tengamos disponibles todos aquellos inputs que necesitamos en el mismo (por ejemplo, si una de las actividades consiste en una carga de datos, se necesitará tener acceso a ese origen de datos, si necesitamos conocer un determinado dominio de datos, necesitaremos que nos lo indiquen, etc…).

¿Qué es tener la historia de usuario desarrollada? Saber qué es lo que hay que hacer.

¿Cuál es el nivel de detalle que se necesita? Lo mismo. El que te permita saber qué hay que hacer, y eso puede variar en función de cada historia de usuario. No se trata de una especificación detallada de requisitos, tampoco de casos de uso (ahora bien, si entiendes que lo tienes que hacer así o que la historia de usuario lo necesita, adelante), se trata de tener la suficiente información para hacer una buena estimación y para conocer si necesitas algún tipo de input (para de esta forma tenerlo antes de empezar).

¿Eso quiere decir que no hará falta comunicación con el responsable funcional durante el sprint? No. La comunicación es esencial, la base. Una cosa es saber lo que hay que hacer y otra conocer todos los detalles.

¿Cuándo se debería hacer esa tarea? Este refinamiento de la pila de producto (porque al conocer más detalle se puede precisar mejor el valor de la historia de usuario y, en consecuencia, su prioridad), se hace mientras se está ejecutando un sprint.

¿Mientras se ejecuta un sprint? Sí, lo que no quiere decir que esté contemplada en el sprint. Decides tú. Puedes dedicar capacidad dentro del sprint a realizar esta actividad o hacerlo como una actividad paralela. Personalmente me gusta más la segunda opción, si bien, es importante que quien o quiénes la hagan participen en el sprint (lo que se hace es detraer de la capacidad total del sprint un porcentaje de estas personas para dedicarlo a generar el detalle de las historias de usuario).

¿Y si no se tiene detallada una historia de usuario y se quiere incluir en el sprint? Se puede hacer, ¿por qué no?, lo mismo la historia es tan simple que con su propia descripción ya se entiende qué es lo que hay que hacer (esto sucederá, sobre todo, cuando ya se tiene el producto bastante maduro).

Pero tampoco es necesario que la historia sea sencilla, también se puede hacer con otras más complejas, teniendo en cuenta que será más complicado acertar en la estimación, lo que puede afectar, si nos equivocamos, al cumplimiento de compromisos en el sprint.

Y no solo eso, al no tener la historia de usuario detallada, estamos dependiendo de que el responsable funcional pueda dedicarnos el tiempo que necesitamos para obtener la información que necesitamos o para que nos generen los inputs necesarios. Esto nos puede romper la producción y no solo afectar al desarrollo de esta historia, sino de otras que también formen parte del sprint.

Si tenemos en cuenta que cuando estemos trabajando en un sprint, tendremos que estar generando materia prima para el siguiente (o siguientes) ya nos está dando una pista de que tenemos que reservar capacidad del total disponible para realizar esta tarea y que, por tanto, no se va a invertir toda la capacidad disponible en el sprint en curso.

Sin embargo no va a ser la única capacidad que vamos a tener que sacar del sprint, ya que en un contexto real en el que tengamos una parte de la aplicación en producción van a surgir necesidades que requerirán invertir esfuerzo en ellas: solucionar defectos, explotación de la información, y en, general, tareas que se van a tener que realizar de forma paralela al sprint.

Por tanto, tendremos una línea base en el sprint, otra línea para la generación de materia prima y otra para todo lo demás. Esta última se puede gestionar de diversas formas, desde el uso de kanban a una priorización de las mismas de manera periódica por el product owner con la colaboración de algunas personas del equipo de desarrollo.

Es importante analizar la carga de trabajo que se requiere invertir en tareas paralelas al sprint porque puede suponer una modificación de la línea base, al análisis de si resulta necesario tener otro equipo dedicado a estos otros trabajos o al análisis de si se está realizando una correcta gestión y priorización de la demanda de trabajo.

No tener en cuenta que puede ser necesario invertir tiempo en estas actividades puede poner en riesgo el sprint en el momento en que tenemos que dedicar capacidad del mismo a la realización de las mismas, de esta forma el resultado de los sprints se convierten en menos predecibles.

En un burndown se suele representar una recta que representa la proyección lineal del tiempo restante para completar el sprint con respecto a la duración del mismo y otra línea que representa diariamente el restante real.

Si la línea del restante real se encuentra por encima o por debajo de la proyección lineal se puede decir que vamos peor o mejor de lo esperado respectivamente.

Por tanto, si tenemos ese dato, ¿tiene interés representar una línea con el esfuerzo real?. Desde mi punto de vista, dependerá si de alguna forma queremos representar el esfuerzo que supone conseguir avances en el sprint, ya que se pueden invertir horas en una historia de usuario y que el tiempo restante no disminuya en la misma proporción y también puede pasar que la dedicación real de algunos de los desarrolladores en el sprint sea superior a la jornada laboral que esté fijada.

De esta forma podemos tener un sprint que puede ir bien con respecto a lo esperado pero que sin embargo esté suponiendo un esfuerzo significativo para el equipo y esto puede tener consecuencias en los próximos sprints, ya que el overtime termina afectando al rendimiento de las personas, por lo que puede ser necesario tomar decisiones como, por ejemplo, modular la velocidad del equipo a estas circunstancias, analizar los motivos que han dado lugar a que las estimaciones realizadas no hayan sido acertadas o a que el trabajo no se haya realizado con la fluidez deseada.

Es cierto que estas conclusiones se pueden sacar al final, no obstante, si se hace un análisis a diario es posible tomar determinadas decisiones dentro del sprint que puedan solucionar alguno de los problemas que provocan esta situación.