Consejos Tecnológicos

3 historias de usuario de C: fáciles de explicar

Uno de los principales valores de la agilidad es que las personas están por encima del proceso. Scrum encarna esto y proporciona artefactos y funciones centrados en el cliente. Las historias de usuario son una característica que puede lograr transparencia, facilidad de comprensión, promover la colaboración y facilitar el proceso de entrega de los objetivos del sprint. En este blog, intentamos explicar las mejores prácticas de las historias de usuario, también conocidas como las 3C de las historias de usuario.

¿Cómo se definen las historias de usuario?

Las historias de usuario son explicaciones generales informales de las funciones del software escritas desde la perspectiva del usuario final. Su propósito es aclarar cómo las características del software brindan valor a los clientes: Atlassian

Para las personas que desarrollan el proyecto, los requisitos de redacción pueden ser sencillos. Pero, ¿qué pasa con los clientes que no siempre comprenden la terminología técnica? Scrum enfatiza la colaboración con el cliente y resuelve este problema con ayuda Historia del usuario.

Scrum implica dividir un proyecto complejo en partes más pequeñas.Cada bloque, llamado épico, se divide en unidades más pequeñas llamadas Historia del usuarioPor lo tanto, las historias de usuario son la unidad de trabajo más pequeña en un proyecto ágil. Describe el objetivo final que se debe alcanzar y siempre se cuenta desde el punto de vista del usuario. En otras palabras, las historias de usuario son la base o los bloques de construcción de unidades más grandes en el proyecto (como épicas y planes).

Debido a que se cuenta desde el punto de vista del usuario, está escrito en una forma que es fácil de entender para el usuario. Esto quiere decir que está escrito de forma sencilla e informal y explica qué debe lograr la función del software que representa. No es detallado, pero muy breve, no más de unas pocas frases. Si es necesario, puede agregar requisitos a la historia del usuario, porque habrá más requisitos durante el proceso de desarrollo de funciones en el sprint.

Entonces, en otras palabras, una historia de usuario describe una necesidad o requisito específico del usuario. También se le puede llamar escena. Las historias de uso se pueden escribir en fichas, documentos de Word o incluso en hojas de cálculo de Excel.

Las historias de usuario también son excelentes para estimar el trabajo por hacer o el trabajo restante. Es necesario estimar la cantidad de trabajo a realizar o la cantidad de trabajo requerido para completar el trabajo porque ayudará a determinar el cronograma, el costo y los recursos necesarios para cumplir con los requisitos.

Algunos métodos para estimar el uso de historias de usuarios incluyen:

  • Planificación de póquer
  • talla de camiseta
  • Sistema de cangilones
  • Mapeo de afinidad
  • Método de pedido, etc.

¿Cuándo se originaron las historias de usuarios?

Las historias de usuario son los bloques de comportamiento requeridos por el sistema de software.Se utilizan ampliamente en métodos de software ágiles para dividir una gran cantidad de funciones en partes más pequeñas para la planificación-Martin Fowler

Entonces, la pregunta aquí es, ¿cuándo comenzamos realmente a usar historias de usuarios? Según Agile Alliance®, Historia del usuario Extreme Programming se originó en 1989, un marco de desarrollo de software ágil, como MeléInicialmente, cuando se introdujeron, eran muy similares a los casos de uso, pero con el tiempo, sus detalles y alcance han cambiado.

Las historias de usuario y los casos de uso aún pueden sonar y verse muy similares, pero existen diferencias sutiles entre los dos. Las historias de usuario tratan más sobre las necesidades o requisitos de los usuarios, mientras que los casos de uso describen las funciones que creamos para satisfacer las necesidades descritas por los clientes. Son más técnicos y definen la interacción entre la función que se está construyendo y el resto del sistema, software o proceso. Por otro lado, las historias de usuarios son más fáciles de leer y comprender.

Según Ron Jeffries, quien presentó la tarjeta. El diálogo, un modelo de confirmación de historias de usuarios, los casos de uso son prácticas de requisitos de documentos y las historias de usuarios son prácticas de requisitos sociales.

Las tres C de las historias de usuario, bien explicadas

«Tarjeta, diálogo, confirmación «; esta fórmula (deRon Jeffries) Capture los componentes de la historia de usuario: Agile Alliance

En 2001, Ron Jeffris propuso una tarjeta de historia de usuario, un diálogo y un modelo de confirmación para Extreme Programming, en el que señaló que la historia de usuario es un elemento clave del «ciclo de vida» de XP. Echemos un vistazo a tres aspectos de las historias de usuarios.

1. Tarjeta:

¿Dónde se escriben las historias de usuarios? En la carta. Se escriben manualmente en la tarjeta de índice. Este ejercicio ayuda a que las historias de los usuarios sean concisas. La tarjeta no contendrá toda o demasiada información sobre la solicitud. En cambio, las tarjetas solo tendrán suficiente información para identificar las necesidades y ayudar a todos a comprender cuál es la historia.

Las tarjetas representan necesidades y son una buena herramienta de planificación. También se puede utilizar para escribir más notas, como prioridades o historias y los costos involucrados. Una vez que el propietario del producto haya finalizado la historia del usuario que se seleccionará para un sprint en particular, entregará la tarjeta de la historia del usuario al desarrollador.

El formato estándar para escribir historias de usuarios en tarjetas es el siguiente:

como un [user type]Yo quiero / necesito [goal] Para que pueda terminar [justification/business value].

2. Diálogo:

La tarjeta es el primer paso en el desarrollo de una historia de usuario, pero debe discutirse, perfeccionarse y comunicarse a los desarrolladores. Esto se hace a través del diálogo. Desarrolladores, propietarios de productos, Maestro de Scrum Las partes interesadas también promueven la colaboración entre todas las personas, lo que ayuda a alcanzar un consenso sobre los requisitos y conduce al desarrollo de productos.

Este intercambio de pensamientos y opiniones a través del diálogo ocurre gradualmente a lo largo del tiempo, comenzando con las estimaciones de la historia realizadas durante el plan de lanzamiento y luego durante la reunión de planificación del sprint cuando se publica la historia. Dibujar para la implementación. Aunque la conversación es principalmente verbal, la documentación se puede utilizar para brindar apoyo.

3. Confirmar:

Incluso con las conversaciones más profundas, siempre hay preguntas sobre los requisitos que deben crearse. ¿Cómo tratamos las historias de usuarios y nos aseguramos de que esto es lo que dicen los requisitos?

Esto se hace a través de la tercera C de la historia del usuario: «Confirmación». La confirmación toma la forma de prueba de aceptación. La confirmación es el criterio de aceptación que captura los requisitos básicos y nos ayuda a probar el producto creado para asegurarnos de que cumple con el estándar definido.

Los criterios de aceptación generalmente los crea la persona a cargo del producto, y se refinan y amplían aún más en el refinamiento de los elementos pendientes. Los desarrolladores implementan criterios de aceptación o pruebas de aceptación. El incremento creado en base a la historia del usuario debe cumplir con la prueba de aceptación para confirmar que la función se ha implementado correctamente. Al final de la iteración, el desarrollador demuestra la finalización de la historia pasando los criterios de aceptación.Este es confirmar completamente.

Cuando se completan y satisfacen las tres C de la historia del usuario, las funciones creadas son competitivas y se pueden lanzar.

Plantillas de historias de usuario: roles, acciones y beneficios

Una especie de La plantilla de historia de usuario define el formato utilizado al escribir historias de usuario. Según Agile Alliance, el formato más común utilizado para las plantillas es «Como … quiero … así …»

  • Como (una persona que quiere lograr algo)
  • Quiero (lo que quieren lograr)
  • Entonces (¿por qué quieren lograr eso?)

Las historias de usuario se escriben desde la perspectiva del usuario. Describe el rol del usuario, la operación o lo que el usuario necesita y el motivo de la historia o los beneficios que brinda.

Veamos cada uno de estos componentes en detalle:

  • Papel: Los roles se refieren a los usuarios que utilizan el sistema o crean funciones para él. El desarrollador no es usuario de esta función.
  • Esa acción: La parte de «qué» de la historia implica la acción o comportamiento del sistema. Cada historia tiene una acción única.
  • beneficio: Este es el resultado de la operación, que es lo que el usuario necesita que suceda.

ejemplo:

Como<用戶>, Espero poder<搜索>así que eso<我可以獲得我想要的產品>

Como<用戶>, Espero poder<將商品添加到購物車>,así que eso<我可以查看商品>

Cómo utilizar INVEST para escribir buenas historias de usuario

Inversión es un acrónimo de lo siguiente:

  • independiente
  • Negociable
  • valioso
  • estimar
  • pequeña
  • Comprobable

Una buena historia de usuario debe incluir todos estos atributos. Revisemos cada una de estas funciones:

  • independiente: Mantener las historias independientes entre sí ayuda a priorizar las historias en la lista de tareas pendientes. Si una historia depende de otras historias, entonces no se puede ocupar hasta que se completen las otras historias, incluso si tiene una prioridad más alta.
  • Negociable: La historia es negociable, lo que significa que se puede cambiar en función de las conversaciones que se produzcan entre los desarrolladores, los propietarios de productos y los consumidores. Es necesario un diálogo colaborativo entre el desarrollador y el usuario o el agente del usuario (es decir, el propietario del producto) para quien se desarrolla la función. Todas las partes deben ponerse de acuerdo sobre una visión común antes de que pueda comenzar el desarrollo.
  • valioso: La historia del usuario debe ser medible, lo que significa que debe agregar valor a todo el proyecto. Por lo tanto, las historias de usuario no solo deben agregar valor a los usuarios en desarrollo, sino que también deben satisfacer requisitos no funcionales.
  • estimar: Las historias de usuario deben ser estimables para que se pueda medir su valor y la prioridad posterior. Esto ayuda a los propietarios de productos a determinar su prioridad en la lista de tareas pendientes del producto.
  • pequeña: La historia del usuario representa la unidad de trabajo más pequeña en el proyecto Scrum y representa una pequeña función proporcionada por el producto. Si las historias de usuario son grandes, deben dividirse en unidades más pequeñas, porque las unidades de usuario más pequeñas ayudan a entregar funciones más rápido.
  • Comprobable: Cada historia de usuario debe ser comprobable para confirmar que funciona como se espera y proporciona valor a los clientes. Los criterios de aceptación se redactaron con este fin. Cuando la historia del usuario pasa los criterios de aceptación, está completa y lista para enviarse.

Consejos para crear grandes historias de usuarios

Roman Pickler Estos consejos se proponen para ayudar a crear historias de usuarios a prueba de fallas:

  • Escribe historias de usuarios desde la perspectiva del usuario.
  • Usa personajes para crear los mejores escenarios de historias de usuario.
  • Garantice la colaboración al crear historias de usuarios
  • Mantenga la historia simple
  • Empiece con épico
  • Sigue mejorando la historia hasta que estén listos
  • Agregar criterios de aceptación
  • Utilice papel / fichas para escribir historias de usuarios
  • Asegúrese de que su historia sea visible y accesible

Nota final

El éxito de un proyecto Scrum depende en gran medida de los detalles, y la historia del usuario es un detalle que no se puede ignorar. No es solo una herramienta para crear funciones, sino también una herramienta para promover la colaboración y la transparencia entre los miembros del equipo y las partes interesadas. Las historias de usuario bien escritas son una condición necesaria para un proyecto Scrum, porque pueden aclarar los requisitos y ayudar a crear características y productos reconocidos por el cliente.

Publicaciones relacionadas

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Botón volver arriba