El primer problema que te vas a enfrentar al momento de redactar historias de usuario es la calidad de estas. No hay una receta o fórmula que te garantice que la historia que acabas de redactar es buena, incluso la noción de calidad puede variar de persona a persona; mientras tu piensas que la historia que acabas de redactar es lo mejor de lo mejor, otro miembro del equipo puede encontrarle serios problemas estructurales. Existe una serie de cualidades que debe de tener una buena historia, estas se presentan mediante un acrónimo fácil de recordar como es la costumbre en TI, te lo explico.
¿Qué es INVEST?.
INVEST es un acrónimo que representa seis cualidades que las historias de usuario deben de tener. Estas cualidades deberían poder otorgarle valor al trabajo que se realizara.
Explicando INVEST.
Independent / Independiente.
Las historias de usuario no deben depender de otras historias de usuario. Esto no significa que las historias de usuario no pueden tener precondiciones o requisitos previos. Una vez que las precondiciones de las historia de usuario han sido cubiertas, esta debería mantenerse en pie por sí misma. Historias de usuario independientes pueden completarse más fácilmente y son menos problemáticas de mover al momento de una priorización de actividades.
Negotiable / Negociable.
Las historias de usuario pueden ser modificadas o reescritas en casi cualquier etapa, excepto cuando ya se están implementando. El orden en que son atendidas las historias también puede ser sujeto a cambio en el sprint o cadencia del desarrollo.
Valuable / Valuables.
La historia debe aportar un valor cuantificable al usuario final o al rol en torno al que gira la historia. Al ver las historias en términos de valor, se fuerza al equipo a ejecutar actividades en relación con el valor que se va a aportar al usuario final. Esto puede empujar tareas triviales al fondo del backlog o removerlas completamente del listado. Tener historias de usuario valuables permite
cuantificar el impacto del equipo al desarrollo en el proyecto. Tareas urgentes pueden ser de poco impacto al desarrollo y tareas importantes pueden ser de muy alto impacto positivo pero con poca urgencia.
Al tener métricas que permitan ver la salud del proyecto puedes estimar el trabajo faltante, el trabajo desperdiciado, el trabajo completado y la desviación de esfuerzo en el proyecto.
Estimables.
Se debe poder deducir un estimado significativo de la cantidad de esfuerzo por parte del equipo de desarrollo el llevar a cabo una historia. Esta debe de ser lo suficientemente pequeña como para que el equipo pueda entender la amplitud del trabajo, pero también lo suficientemente definida como para que el equipo pueda tener una idea de lo que se necesita para completarla. Una historia construida a partir de deseos o condicionales no es estimable.
Una historia de usuario se estima en puntos. Las actividades que involucran esta historia se pueden estimar en horas o días. Si puedes desglosar las actividades a realizar, entonces puedes estimar cuanto tiempo podrías tardarte en concluirla.
Small / Pequeñas.
Las historias deben ser lo suficientemente pequeñas como para que el equipo tenga una certeza razonable de cuanto tiempo tomara efectuarla. La probabilidad de que una historia no pueda ser completada crece directamente con el tamaño de esta. Historias pequeñas permiten al equipo dividir el trabajo en pedazos manejables. Una historia tampoco puede ser tan pequeña
que el valor que aporta se vuelva trivial, existe un límite subjetivo al momento de dividir la historias en unidades más pequeñas.
Testable / Que se pueda probar o verificar.
Esto significa que la historia debe definirse hasta el punto en el que podamos definir una prueba, esto requiere cierto nivel de especificidad, no se debe especificar el cómo será llevada a cabo una historia sino más bien cuál será su resultado final esperado. Si el valor que se espera de la historia no se cumple, entones esta no ha sido completada. Hay que hacer hincapié en el resultado, no es lo mismo una historia que espere «un diseño novedoso» como resultado final a «completar una compra en menos de 5 minutos». En el primer caso, probar el resultado final es completamente subjetivo, mientras que en el segundo define claramente que un proceso de compra debe completarse en menos de 5 minutos.
Autor imagen: Chris Potter
- NVL in SQL Server - 2023-11-01
- ¿Que es Cake Build? - 2023-02-22
- #How to fix error: MSB4019: The imported project «Microsoft.Data.Tools.Schema.SqlTasks.targets» was not found - 2023-02-20
