archivo

Archivo de la etiqueta: historia de usuario

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.

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.

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…

Llega un momento en la evolución de un producto o en un proyecto de desarrollo de software donde echamos en falta todo ese esfuerzo que no se ha aprovechado de manera adecuada, ¿por qué? lo necesitamos ahora o prevemos que lo vamos a necesitar pronto y ya ha desaparecido.

Una de las causas que hacen que el aprovechamiento del esfuerzo no sea óptimo es trabajar con historias de usuario, requisitos o especificaciones que no están claros y en los que existe una probabilidad importante que la solución implementada requiera ser modificada de manera sensible más adelante.

Es mejor invertir el esfuerzo en aquellas tareas donde el retorno de la inversión sea más probable, en donde el efecto sobre el valor del producto sea más inmediato.

Lo que no esté claro debe tratar de solventarse hasta donde se pueda ya que de esta manera se desarrollará con una mayor intención y los ajustes posteriores serán de menor entidad.

Tampoco podemos estar paralizando indefinidamente el desarrollo de una funcionalidad que sea crítica o importante para el sistema pero sí podemos esperar hasta el último momento posible para tratar de que esté lo mejor definida posible.

Cuando se está trabajando en el refinamiento de la pila de producto (en paralelo al desarrollo de un sprint), una herramienta muy útil para definir con más detalle una historia de usuario es la utilización de maquetas o prototipos estáticos o dinámicos que permitan a los desarrolladores comprender mejor una determinada funcionalidad y a los responsables funcionales o product owners ver materializadas (de manera más o menos simplistas) esas ideas abstractas que tienen en la cabeza.

Sin embargo, llegados a un punto, continuar trabajando con esos prototipos para seguir perfilando una funcionalidad puede llegar a convertirse en esfuerzo invertido en vano, ya que el feedback que se obtiene deja de resultar significativo.

¿Cuándo se llega a ese punto? Cuando prácticamente no se obtiene un feedback de lo funcional y sí del diseño pero ya en aspectos poco significativos (de aquellos que hoy te dicen una cosa, mañana otra y pasado todo lo contrario).

En ese momento es fundamental, que el siguiente feedback se obtenga sobre la funcionalidad ya implementada sobre una versión del producto en el sprint en que se decida llevarla a cabo.

Feedback, sí, siempre que se pueda, pero con intención y fundamento.

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