archivo

Archivo de la etiqueta: pila de producto

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 un proyecto puede presentar problemas presupuestarios cuando se prevé un alcance y una complejidad mayor que cuando se hizo su estimación económica, la solución debería pasar, no por intentar meter todas las funcionalidades con calzador, sino por tratar de buscar una solución más racional que permita obtener un producto que satisfaga las prioridades que se han establecido con un alto nivel de calidad, aunque esto implique dejar fuera o para más adelante (en muchos casos es necesario gestionar con los responsables funcionales el síndrome de la última versión), otra serie de funcionalidades que pueden resultar interesantes.

El primer paso debería consistir en dividir el proyecto en diferentes entregas, siendo conscientes todas las partes de que el desarrollo será iterativo incremental porque del feedback de cada versión vendrán, muy probablemente, solicitudes de mejora por parte del área usuaria.

Si se trata hacer todo de golpe se correrá el riesgo de que se agote el presupuesto y que en medio del proceso de desarrollo se entre en un conflicto entre las partes sobre cuál será el alcance final.

La experiencia dice que por muy buen acuerdo que se alcance se verá afectada la calidad del software porque el proveedor tratará de minimizar pérdidas, porque los desarrolladores tendrán overtime y llegado a un punto el cansancio y las ganas de terminar darán lugar a precipitación que se traduce en deuda técnica y en un producto menos probado.

Por otro lado, el cliente tendrá una mayor desconfianza y la comunicación entre las partes, tan necesaria en un proyecto de desarrollo de software, perderá fluidez y en función del grado de desgaste en las relaciones podría dar lugar a situaciones del antipatrón “arrojar al otro lado del muro“.

También se puede agotar el presupuesto con el enfoque iterativo incremental, la diferencia está en que al reestructurar el proyecto de esta manera todas las partes conocen las reglas del juego: se trabaja así no solo porque sea el enfoque que mejor pueda convenir al proyecto sino porque permite gestionar de manera adecuada las prioridades, el seguimiento y consumo económico del proyecto.

El siguiente paso consiste en trabajar con pila de producto e historias de usuario. Los responsables funcionales priorizan estas historias que una vez tasadas y ajustadas a la capacidad del sprint, se convierten en lo que será el resultado final de la entrega.

Si no lo ves claro (y también si lo ves claro), no dudes en dividir el proyecto en partes y cada parte en componentes o trabajos más simples (historias de usuario). Será más manejable, te beneficiarás el feedback y la gestión económica será mucho más transparente y mejor entendida entre las partes.

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.

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

Yo también soy partidario de los sprints cortos: se tarda menos en conseguir un feedback efectivo sobre una versión del producto en producción y se reduce el tiempo medio de espera en la pila de producto de una historia de usuario urgente que no ha entrado en el sprint.

No soy partidario de sprints largos.

¿Cómo corto debe ser el sprint? No tengo la respuesta porque la tienes que encontrar tú en base a tu proyecto y tu contexto.

Un condicionante importante es la capacidad de aguantar el ritmo porque no solo se trata de adecuar la cantidad del trabajo a la velocidad, algo que se consigue en el momento en que todo el mundo (sobre todo el área usuaria o el product owner) está mentalizado en que es la mejor forma de trabajar y se acierta en las estimaciones (importantísimo), sino de tener en cuenta que además hay que ir preparando el siguiente sprint mediante el refinamiento de la pila de producto, que no es otra cosa que obtener el nivel de detalle suficiente en una historia de usuario para poder valorarse de manera adecuada y poder ejecutarse cuando sea posible, mientras se está pasando a producción la anterior entrega, algo que puede ser muy complicado en organizaciones que compartan un equipo de instalación de aplicaciones que esté fuertemente procedimientado, teniendo en cuenta, además, que hay que trabajar de manera priorizada con las incidencias que vayan saliendo.

Es posible que algunas de esas tareas que tienen dependencias externas, como el refinamiento de la pila o el paso a producción se retrase, lo cual hace necesario un mayor esfuerzo para tratar de mitigar en lo posible la desviación, lo que produce un fuerte desgaste cuando esta situación se hace reiterada en los sprints.

Un día, un amigo me preguntó: “¿por qué se le llaman sprints a las iteraciones?”, poco después por sí mismo pudo conocer la respuesta.

En un enfoque iterativo incremental hay diversas formas de gestionar las incidencias. Vamos a considerar dos tipos de incidencias y las analizamos por separado: las que se producen sobre la aplicación en el entorno de producción y las que aparecen en la iteración en la que estamos trabajando.

En este artículo vamos a analizar el primer caso, en el artículo de mañana, el segundo.

En función de la criticidad e impacto de cada incidencia se puede decidir incluirlas en la pila de producto para ser tratadas en iteraciones sucesivas o bien trabajar con ellas dentro de este ciclo. En este segundo caso puede impactar sobre los objetivos del sprint porque las historias de usuario y tareas sobre las que se trabaja están adaptadas a la capacidad (velocidad) del equipo de trabajo y esas tareas de más implican que el equipo debe incrementar la velocidad para cumplir los objetivos, a veces se podrá (pero cuidado con la calidad de los resultados) y otras no será suficiente e implicará que alguno de los hitos de la iteración no se puedan ejecutar, salvo que se decida prolongar la duración del sprint.

No estoy hablando de metodologías concretas sino de un enfoque iterativo incremental y que cada cual lo gestione cómo crea que conviene mejor al proyecto y es mejor. Con respecto a retrasar la fecha de finalización del sprint yo no soy partidario, aunque en determinadas situaciones puede ser la mejor opción (no tenemos que encorsetarnos, nos debemos a los proyectos no a las metodologías).

Si se decide trabajar con incidencias dentro de este ciclo existe la posibilidad de tener una persona (o un conjunto de ellas) que se dediquen a corregir las mismas, “fuera” del equipo de personas que trabajan en el sprint. Lo pongo entre comillas porque perfectamente pueden ir rotándose con personal del equipo “principal” o ser parte de hecho de ese equipo principal pero no computarse su esfuerzo en la capacidad del equipo de trabajo (la rotación podría ser incluso dentro del mismo sprint).

El resultado del trabajo de estas personas podría sincronizarse con el sprint, conformar un sprint independiente o simplemente empaquetar incidencias corregidas y decidir el mejor momento para pasar a producción (sin sincronizarse con el sprint o adoptar un enfoque iterativo).

Estas personas podrían ayudar al equipo de desarrollo del sprint en caso de que no entrase suficiente carga de trabajo como consecuencia de incidencias.