Por ponernos en contexto, un poco por refrescar cosas, el ciclo de vida ágil es un tipo especial del veterano ciclo de vida iterativo e incremental. Entre otras matizaciones, un ciclo de vida iterativo e incremental podríamos decir que es ágil si la parte incremental se lleva al extremo, en lo que refiere a la constante, en muy cortos periodos de tiempo, entrega de valor (o valor listo para ser entregado) y funcionalidad a usuarios, cada pocos días o incluso horas (alguna referencia más).
El ideal es la entrega continua de funcionalidad, valor, al usuario. Y si la naturaleza de tu desarrollo no posibilita esas puestas en producción frecuentes, al menos, valor o funcionalidad en pre-producción o en condiciones de ser usado (te dejo esto ¿Un Sprint termina con un paso a Producción?).
Lo de «entrega continua» es una de las muchas diferencias de un ciclo de vida ágil frente al cascada, en el cascada se entregaba mucho al después de mucho tiempo, en el ágil se entrega poquito muy frecuentemente (y lo que se entrega es útil, típicamente funcional, para el usuario).
Lo más normal es que para ir realizando esos incrementos de valor- funcionalidad a usuarios se haga uso de las «historias de usuario», que representan funcionalidad pequeña. Hay muchas más características de lo que es una historia de usuario, pero no me extiendo en ello, hay post en el blog que hablan de ello. Pero si que quiero destacarte dos cosas, pequeñas y funcionales (end to end), sería bueno aquí leer Historias vs Tareas… una sutil e importante diferencia.
¿Y por qué tanta obsesión en que las historias de usuario sean pequeñas? Y añado, pequeñas a la vez que funcionales, de hecho, si las historias no son funcionales… no son historias. Y por ser más explícito, hacer una BBDD, un driver, no sé qué clase Java, etc., son cosas que tienen mucho valor pero no son funcionales (el usuario no las ve), por ello, los anteriores son tareas y no historias.
Te voy a dejar 4 razones, de muchas otras, que me parecen fundamentales para que te obsesiones con hacer historias de usuario pequeñas (y funcionales)…
«Feedback» frecuente con usuario
Cuanto antes vea el usuario lo que estamos haciendo antes nos aseguramos de que es eso lo que quiere, y sino lo es, cambiaremos cosas pequeñas no cosas grandes, difíciles de cambiar, y de las que incluso ya ni nos acordamos.
La nota importante de este punto… es de las más importantes de todo esto… nos será más fácil acertar con qué quiere de verdad el usuario, qué le aporta valor.
Podía haberlo puesto en un punto más, pero como está muy relacionado con este lo dejo aquí… historias de usuario pequeñas nos dan más capacidad de cambio, de adaptarme a las necesidades.
Saber de VERDAD dónde estamos
Aquí hablo del tradicional problema del seguimiento del «proyecto». Antiguamente, se hacían cosas muy raras como porcentajes de avance en función de tiempo transcurrido, etc., que tenían fiabilidad escasa. Realmente sabemos que algo está terminado cuando, va lo obvio… lo está. Que lo esté es que lo use el usuario (con los adjetivos que quieras ponerle respecto a las condiciones en que lo usa).
Historias de Usuario pequeñas me muestran el avance REAL en cortos periodos de tiempo, sacándome del lado oscuro de ver avances en función de horas.
Integraciones menos complicadas
Todos hemos sufrido lo que es una integración, hay «proyectos» en los que la integración ha durado más que el desarrollo. Tu, o un equipo, hace una cosa y yo, u otro equipo, hace otra y una cosa depende de la otra y en algún momento hay que juntarlas. Y todos sabemos que cuánto más tiempo pasa más difícil es unir.
Historias de usuario pequeñas llevan a pocos días para su realización y llevan a integraciones más frecuentes y por ello menos desastrosas.
Testeo frecuente
Muy en línea con el anterior, dejar el Testing para el final, para dentro de mucho no es buena cosa. Si tengo historias de usuario pequeñas, testearé muy frecuentemente, y lo que el Testing encuentre aún será posible de resolver, pero si Testeo en real (o pre-producción) cada mucho tiempo, encontraré cosas que será muy difícil de resolver.
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Las 3 matrices de priorización Ágil - 19 octubre, 2023
- Etapas del Agile Product Management - 12 octubre, 2023
- Agile Product Management: DINÁMICA «Árbol Solución Oportunidad» + «Valores Esperados» - 5 octubre, 2023
Hola a todos.
El doctor de mi trabajo fin de grado me dice:
«Historias de usuario son solo las funcionalidades de la aplicación. Quita lo que no lo sean.»
Una parte de lo que opino de una historia de usuario es:
«Una historia de usuario recoge una funcionalidad, idealmente es una funcionalidad, a veces las utilizamos para recoger no funcionalidades. No es una especificación muy detallada de requisitos software, sino que recoge un requisito de manera muy breve, cuyo objetivo no es especificar al máximo todos los detalles, sino hacernos recordar y tener en mente que es lo que esperamos que se valla a desarrollar en cada uno de los prototipos del proyecto.»
El conflicto es que en el trabajo fin de grado me piden redactar una memoria y el código con un tiempo aproximado de 296 horas.
Mi profesor opina que el redactar la memoria no es una historia de usuario porque no es una funcionalidad de la aplicación.
Yo por el contrario opino que si es una historia de usuario porque es un requisito imprescindible para realizar el trabajo fin de grado, es decir, no puedes entregar el trabajo fin de grado sin su memoria.
Es necesario dedicarle tiempo y esfuerzo a la tarea de redactar la memoria, además de ser un entregable.
En mi caso pienso que todo lo que requiera tiempo en el proyecto debe de estar en Scrum registrado.
Porfavor, dame tu punto de vista, atentamente.
Interesante! Buen post, y de acuerdo con que tienen que ser pequeñas…pero, ¿qué significa lo suficientemente pequeñas? ¿qué tan pequeñas? Posiblemente tu primera respuesta sería: «¡eso, lo más pequeña posible!. Okay, imagina una historia que pudieras tener Done en 10 minutos (sólo por poner un ejemplo). Esto es: diseñada, construida, probada y en producción en 10 minutos. Lo siguiente es recibir feedback al respecto, y tendrías feedback cada 10 minutos. Ahora imagina que tenemos historias que pueden estar listas en 5 minutos….y luego en 1 minuto. Suena genial, feedback cada minuto. No obstante, recuerda que el recibir el feedback y el paso en sí mismo a la etapa de recibir un feedback posee un costo, lo que se denomina el costo de transacción o costo por el transporte del ítem. Este aumentaría en función del volumen de historias que tenemos listas. Lo que disminuye, es el costo de holding o costo de inventario del ítem. A historias más pequeñas no tenemos inventario y no pasan mucho tiempo «descansando» hasta salir a producción. Historias más grandes, descansan más, más costo de holding. Por un lado, mínimo costo de almacenamiento y costo alto de transacción. El tamaño de la historia o del ítem (batch size) debe lo suficientemente pequeño de tal forma que le permite optimizar su flujo, en el punto donde el costo de transacción y el costo de holding sea lo menor posible, mi opinión.
De todas formas, es muy buen post!
Se podría complementar este tema con el elephant carpaccio de cockburn y la idea de ir… a lo más pequeñas
Una historia de usuario podría representar un tipo de necesidad no funcional. Es decir, el cliente quiere que la bbdd sea MongoDB. Se consideraría una HdU ya que por ejemplo supone una migración de la bbdd de origen? Al final si se completa esta HdU aporta valor al producto. Un saludo!
La HU, por definición, es end to end funcional, si no es otra cosa, un Item en general o una tarea….
Sería bueno que tras una definición colocar un ejemplo.