Español
日本語
Portuguese
简体中文
繁體中文Principio INVEST para crear historias de usuarios
Además de un formato estandarizado y elementos completos, una buena historia de usuario también debe seguir los principios de INVEST : 1. Yo dependiente; 2. N egociable; 3. Valioso ; 4. Estimable ; 5. Pequeño ; 6. T estable.
1. Independiente : es importante que una historia de usuario sea lo más independiente posible de las otras historias de usuario. Mantener la independencia entre las historias de los usuarios no solo facilita la priorización y la alineación, facilita la planificación de versiones e iteraciones, facilita la comprensión independiente, el seguimiento, la implementación, las pruebas y la entrega frecuente, sino que también hace que el alcance de la estimación del tamaño de la historia del usuario sea más claro y, por lo tanto, el sesgo de estimación. menor.
2. Negociable : el contenido de una historia de usuario es negociable; una historia de usuario no es un contrato. Una historia de usuario es solo una breve descripción de la historia de usuario sin muchos detalles; los detalles específicos se producen durante la fase de comunicación. Una historia de usuario con demasiados detalles en realidad limita al usuario, las ideas y la comunicación del equipo.
3. Valioso : cada historia debe ser valiosa para el cliente (ya sea un usuario, un comprador o un rol interno de la empresa). Las historias de usuario son valiosas para el usuario final, por lo que deben escribirse desde la perspectiva del usuario, describiendo una CARACTERÍSTICA en lugar de una TAREA.
Esta característica facilita un cambio del estilo de trabajo tradicional basado en directivas a un estilo de trabajo autodirigido y orientado al valor para los miembros del equipo de desarrollo y pruebas, de modo que todos en el equipo conozcan el valor del trabajo que hacen todos los días.
4. Estimable (se puede evaluar): una parte muy importante dentro de la reunión de planificación es la estimación de los puntos de la historia. En realidad, es una estimación aproximada de la historia de usuario que se desarrollará para que el equipo pueda conocer la complejidad (carga de trabajo) de esta historia de usuario.
La atención se centra en si la historia de usuario se puede completar en la iteración actual de acuerdo con las condiciones de recepción de esa historia de usuario y los DoD (criterios de finalización) definidos por el equipo, y si no se puede completar, se da el motivo y el PO decide si dividir o rediseñar la historia de usuario.
Los problemas que dificultan que los desarrolladores calculen la historia provienen de: falta de conocimiento del dominio (en cuyo caso se necesita más comunicación) o la historia es demasiado grande (en cuyo caso se debe cortar en partes más pequeñas).
5. Pequeña : una buena historia debe ser lo más corta posible en términos de carga de trabajo, preferiblemente no más de 10 personas ideales por día, al menos para garantizar que se complete en una iteración. Cuanto mayor sea la historia de usuario, mayor será el riesgo en la programación, la estimación de la carga de trabajo, etc.
6. Comprobable (comprobable): una historia de usuario debe ser comprobable para confirmar que se puede completar. Si una historia de usuario no se puede probar, entonces no puede saber cuándo se completará. Un ejemplo de una historia de usuario no comprobable: el software debe ser fácil de usar.
Tres Directrices
Una historia de usuario es básicamente una buena historia de usuario cuando se siguen los principios de INVEST. Luego nos enfocamos en tres pautas para ayudar a cumplir mejor con los principios al producir historias de usuarios.
Las tres pautas son: un usuario, valor completo y sin dependencia.
1. Un tipo de usuarios : incluya solo un tipo de usuarios, ya que varios usuarios suelen tener matices. Por lo general, es un usuario típico, a menudo con una necesidad común de algún tipo.
2. Valor completo : brinde valor al cliente en su totalidad. Una historia de usuario completa significa que cuando esta historia está completa, el usuario puede alcanzar un objetivo claro y significativo.
3. No dependencia : los tres tipos comunes de dependencias son: superposición, secuencia y contención.
En general, se debe evitar la superposición de puntos funcionales entre pisos; las relaciones secuenciales son una realidad y pueden resolverse por algún medio en la mayoría de los casos; y las relaciones de inclusión son útiles para sistemas complejos, con implicaciones para programar versiones y planes de iteración que necesitan atención.
Dependencias superpuestas
Las dependencias superpuestas son la forma de dependencias que causan más problemas, especialmente cuando varias historias de usuario contienen varias partes superpuestas diferentes. Es difícil encontrar un conjunto de historias de usuarios que puedan representar el conjunto de funciones para ese producto mínimo viable, que debe contener y solo contener las funciones necesarias una vez.
Solución
Elimina las partes superpuestas como historias de usuario separadas.
División racional de las historias de usuario y mantenimiento de las superposiciones en solo una de las historias de usuario más cohesivas.
Usa el modelo de desarrollo Scrum.
Dependencias secuenciales
La dependencia secuencial significa que para que se complete una historia de usuario, se deben completar una o más historias de usuario antes. Las dependencias secuenciales suelen ser inofensivas y existen formas de mitigar dichas dependencias.
Desde una perspectiva de desarrollo ágil, todo el sistema evoluciona gradualmente desde un producto viable mínimo inicial hasta un producto robusto, y cada paso posterior se basa en los anteriores.
Pero desde otra perspectiva, las dependencias secuenciales innecesarias dificultan la clasificación y la priorización, lo que a su vez afecta el desarrollo de los planes de lanzamiento e iteración y dificulta la estimación del tamaño de las historias de usuario.
Solución
Haga que las historias de usuario dentro de una iteración estén lo más libres posible de dependencias intrínsecas.
Mantener solo dependencias unidireccionales entre iteraciones, con solo dependencias unidireccionales en el tiempo desde historias en iteraciones posteriores hasta historias en iteraciones anteriores (dependencias hacia adelante).
Eliminar las dependencias centrales como historias separadas y no mezclar requisitos dependientes y no dependientes en una sola historia.
Inclusión de dependencias
Las dependencias contenidas se refieren al uso de la gestión jerárquica en la organización de historias de usuario, como la gestión común de dos niveles de historias de características, donde una característica contiene varias historias de usuarios, lo que constituye una dependencia contenida de la característica en sus historias subordinadas.
Solución
El nivel de historia de usuario se usa para la planificación de iteraciones, evitando la planificación de iteraciones de granularidad gruesa con el nivel de características, que se puede usar para la planificación de versiones.
El nivel de función también se puede dividir hasta que alcance el nivel de una función comercializable mínima, y las historias de usuario que contiene se pueden agrupar por separado en las funciones recién divididas.
Siguiendo el concepto de producto mínimo viable, una característica se implementa en múltiples iteraciones de múltiples historias de usuarios, cada una de las cuales puede resultar en un producto potencial o proporcionar comentarios internos o externos.
Referencias
Español
English
简体中文
繁體中文
Deutsch
Français
العربية
Italiano
Português
日本語
Nederlands
Русский