archivo

Archivo de la etiqueta: historias de usuario

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.

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.

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.

Hace un par de días publiqué un artículo en el que indicaba que las especificaciones contractuales, por regla general (y con las matizaciones que hice), suponen un freno o una resistencia al objetivo de tratar de conseguir el mayor valor posible con la inversión realizada.

En este artículo voy a tratar de exponer que una situación diferente (que no necesariamente contraria), que no otra es la pérdida de una visión global de lo que se pretende conseguir, también supone un riesgo importante.

¿Por qué? La clave se centra igualmente en el valor. El valor de cada historia de usuario desarrollada junto a las expectativas de lo que se pretende conseguir en el proyecto, siempre y cuando estas se adapten a la propia evolución de los trabajos y de la propia organización, es lo que permite conseguir el equilibrio.

Esa pérdida de visión de sus propias expectativas por parte de un product owner, cuando se empeña, por ejemplo, en refinar sobremanera funcionalidades que, siendo importantes, ya funcionan de manera adecuada, provoca que se sobrevaloren historias de usuario que puestas en contexto tienen un valor muy
inferior porque existen otras necesidades en el sistema que pueden que no tengan todavía un funcionamiento aceptable o ni siquiera se han abordado.

Pero la búsqueda de la perfección no es el único problema, también lo tenemos cuando el product owner se centra en aspectos relacionados con lo que le puede gustar o dominar más, dejando de lado, otros más ásperos, complejos o que requieran un consenso que no resulta siempre facil de conseguir pero que también resultan necesarios para tener un sistema de mayor valor.

La visión del proyecto y expectativas no son fijas pero existen o deben existir para poder dar el valor adecuado a cada historia de usuario en la que se trabaja y para ir orientando la línea de desarrollo del producto hacia lo que se pretende conseguir, de lo contrario es posible que no se centren los esfuerzos y la inversión en lo realmente importante.

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.

Aunque la intención sea que sí la realidad es que no.

Se puede tratar de plasmarlo todo y por muy cuidadoso que se sea siempre habrá algún detalle que se escape. Y lo más importante de todo, cada persona que lea los requisitos podrá darle una interpretación diferente.

De hecho muchos líos que se montan en los proyectos son precisamente por eso, por interpretarse de manera distinta lo que se indica y por cubrir cada cual a su modo los huecos que no se han especificado de forma completa.

Por ese motivo, los requisitos, vistos como el traspaso de los mismos a un documento electrónico o digital es insuficiente si no vienen acompañados por un diálogo continuo entre desarrolladores, product owners, usuarios, etc…, por eso las historias de usuario están venciendo a los requisitos tradicionales ya que parten desde una perspectiva basada en la colaboración.

Pero no solo es eso, los requisitos parten como verdades absolutas, sin embargo, muchas de ellas van perdiendo fuerza conforme avanza la elaboración del producto, surgen nuevas necesidades, se redefinen prioridades y se descubre que diversas percepciones iniciales son incorrectas.