archivo

Archivo de la etiqueta: 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.

Una tarea (que puede ser una subdivisión de una historia de usuario o una historia de usuario propiamente dicha) puede considerarse terminada bien cuando el desarrollador o desarrolladores la hayan finalizado y probado o bien cuando esa tarea de testing la haga un tercero, en ambos casos, nos puede surgir la siguiente pregunta: si las pruebas han sido correctas, ¿debemos considerar que el tiempo restante es 0?.

¿Qué puede pasar? Que cuando integremos con terceras historias aún en construcción o incluso todavía no iniciadas nos demos cuenta que existen errores en la que hemos dado por terminada y, por tanto, que el tiempo restante ya no sea cero, de manera que nuestras previsiones o expectativas si tomamos como referencia, por ejemplo, un burndown, se vean afectadas, sobre todo, si el defecto encontrado es importante.

La alternativa a no considerar el tiempo restante es 0, es dejar un cierto margen de tiempo restante en función de las probabilidades de error en la integración del componente, de su complejidad, criticidad, etc…, pero en cualquier caso, estaríamos especulando y, pese a que pueda considerarse una postura conservadora, no refleja con fidelidad el estado del sprint.

Por tanto, soy de la opinión de que cuando una tarea se considere terminada (eso sí, con una batería de pruebas ejecutada correctamente y que sea adecuada a su naturaleza) se considere que el tiempo restante sea 0, con independencia de que posteriormente sea necesario realizar reajustes en el mismo como consecuencia de problemas que se vayan detectando.

Nos encontramos con la siguiente situación: tenemos un sprint en el que es necesario modificar una funcionalidad crítica del sistema (motivada, por ejemplo, por un cambio normativo) y se tiene que hacer de una vez (no podemos dividirla en historias más simples) ya que si no se ejecuta de esa manera no va a funcionar cuando la pasemos a producción.

En ese sprint, además, hay otras historias de usuario que se están desarrollando y en un equipo en paralelo tenemos a personas solucionando incidencias, cuya entrega se iba a sincronizar con el sprint. En un determinado momento, nos damos cuenta de que no vamos a tener la funcionalidad lista para la fecha de finalización del sprint, ¿qué hacemos?.

Hay diferentes posibilidades. La solución a aplicar podría ser diferentes en cada proyecto:

– Lo más tentador es retrasar la fecha de finalización del sprint. A mi personalmente no me gusta y creo que solo se debería hacer en el caso de que no hubiera otra salida. ¿Por qué? Creamos un precedente y más pronto que tarde nos volveremos a encontrar con una nueva situación, en este caso con menos criticidad, en la que se termine aplicando la misma solución y se entra de esta manera en un bucle nada beneficioso.

– Reducir el alcance del sprint, centrando los esfuerzos en la funcionalidad crítica. Podría funcionar si se detecta pronto la desviación y si el fallo en la estimación del esfuerzo de construcción de la funcionalidad crítica no es muy sensible. Si se aplica esta estrategia habrá historias de usuario comprometidas que no se podrán completar.

– Incrementar la capacidad del equipo. Esto solo va a funcionar si las personas que se incluyen en el equipo conocen la tecnología, las dinámicas de trabajo o si las tareas a realizar no requieren ese nivel de especialización. Podría valer con incrementar la dedicación de personas que no estén a tiempo completo en el proyecto o pasar personas del equipo de resolución de incidencias al equipo del sprint. Esta estrategia podría combinarse con la anterior.

– Completar la funcionalidad crítica en el siguiente sprint, es decir, el sprint termina con las historias de usuario que se hayan podido completar y en el nuevo sprint se sigue trabajando con ella.

La decisión a adoptar debe contar con el consenso del responsable funcional porque afecta a los plazos en que determinadas funcionalidades se incorporan, modifican o corrigen en el sistema, también es importante mantener la calma con el objeto de aplicar la solución más adecuada. En la retrospectiva es fundamental que se analice en qué se ha fallado y se tomen las medidas oportunas para reducir la probabilidad de que este problema se vuelva a producir en un futuro.

Un error muy frecuente que nos encontramos con las estimaciones lo tenemos en pensar que se van a dar condiciones ideales: no se van a sufrir interrupciones inesperadas, no vamos a sufrir contratiempos técnicos y la capacidad calculada para cada persona no va a sufrir cambios (en el momento en que una persona por el motivo que sea no puede ir a trabajar un día, rompe ya los esquemas).

Si a eso le sumamos lo difícil que resulta acertar, estamos sometiendo cada sprint a una presión que los desarrolladores no van a poder aguantar porque la realidad será que para cumplir los compromisos se tendrá que incrementar la capacidad de todos y eso se traduce en overtime. El otro camino es dejar historias de usuario comprometidas para más adelante (sacarlas de la pila de sprint). Ambas soluciones son malas. La primera porque no es sostenible, ya que incluso los equipos más motivados no pueden aguantar un ritmo por encima de sus capacidades físicas durante un tiempo prolongado y la segunda porque perdemos predecibilidad y fiabilidad.

Ten en cuenta en que fase del proyecto te encuentras, no tienes el mismo conocimiento al principio que tras la sexta o séptima iteración y ten en cuenta que no se puede asegurar capacidades del 100% de nadie. Se puede estar asignado al proyecto un 100% pero prever una capacidad para el sprint inferior a esa, si después resulta que no han existido contratiempos y puede estar al 100% pues mejor, ya que así aprovechará para ayudar a otros compañeros, para ayudar a resolver contingencias que hayan podido ocurrir en la iteración, para refactorizar, etc…).

El equipo recibe muchas presiones (y quién esté libre de pecado que tire la primera piedra) para que asuma el mayor número de historias de usuario posible. Se tiene que aprender a decir que no y a respetar las condiciones para que un conjunto de personas puedan cumplir sus compromisos sin tener que reventarse.

Muchas veces nos encontramos con el término “épica” y no sabemos como encajarlos cuando tradicionalmente estamos acostumbrados a trabajar con historias de usuario.

Cuando estamos trabajando en un sprint, una posible estrategia de desarrollo la tenemos dividiendo todas o algunas de las historias de usuario en tareas, ya sea por cuestión de tamaño, por la posibilidad de dividir el trabajo entre diferentes desarrolladores, etc…

Una épica no es más que un nivel de agrupación por encima de las historias de usuario que permite clasificar las mismas por funcionalidades, módulos, subsistemas, etc… Es decir, se tiene en mente una imagen abstracta de lo que se quiere obtener con la épica (que se desarrollará probablemente en varias iteraciones), pero son las historias de usuario, su implementación en los sprints y el feedback los que terminan de darle finalmente la forma.