Agile Methodology, kanban, lean, scrum, scrumban

Guía aplicada de Historias de usuarios en scrum ágil, prácticas recomendadas de historia de usuario – Yodiz Project Management Blog


 Guía aplicada de Historias de usuarios en scrum ágil, Mejores prácticas de User Story

User Story es una herramienta de metodología de desarrollo de software ágil que ayuda a capturar una descripción de una función de software desde la perspectiva del usuario final. User Story ayuda a crear una descripción de requisitos.

User Story describe tres cosas:

  • Tipo de usuario
  • ¿Qué quiere el usuario?
  • ¿Por qué quiere el usuario?

En desarrollo de software Agile User Story es una descripción que consiste en una o más oraciones de los usuarios finales o de los usuarios del sistema que captura lo que un usuario hace o lo que necesita.

Escribiendo historias de usuarios, ejemplos y plantillas en metodologías ágiles

1. Plantilla de historia de usuario

Las historias de usuario están escritas por el propietario del producto o según los comentarios de los usuarios finales. La plantilla User Story es una buena guía para los usuarios finales. Ayuda en la creación de User Story. La plantilla User Story les ayuda a escribir User Story en un patrón seleccionado.

Nota: Agile no fuerza ninguna plantilla de User Story.

2. Casos de uso

Casos de uso son la lista de acciones para lograr un objetivo específico. En Agile, la mayoría de las personas relacionadas con negocios piensan que User Story y Use Cases son iguales.

¿Son realmente iguales?

La respuesta es no. Porque User Story es un requisito del usuario final en palabras cortas y simples. Cualquier persona no técnica puede escribir una historia de usuario, pero los casos de uso son escritos por expertos técnicos. En otras palabras, podemos decir que User Story es una forma simple de requisitos mientras que, en Casos de uso, los requisitos se escriben con precisión.

2.1 Ejemplo de caso de uso

User Story: Sitio web adaptable para una empresa de ventas. [19659003] Casos de uso:

  • Sitio web sensible
  • Características del registro de ventas para compra y venta
  • Calcular ingresos diarios, ganancias, pérdidas
  • Informe meta mensual
  • Registro de empleados, etc. [19659024] 2.2 Uso de actores

    Actor es un usuario o cualquier sistema que interactúa con el producto. El actor de caso de uso es un interesado en el producto pero no todos los interesados ​​son actores en el caso de uso.
    Dos tipos de actores se discuten en el libro de Alistair Cockburn "Escritura de casos de uso efectivo" .

    2.2.1 Actor principal

    "El principal actor de un caso de uso es el interesado que solicita al sistema que entregue uno de sus servicios. Tiene un objetivo con respecto al sistema, que se puede satisfacer con su funcionamiento. El actor principal es a menudo, pero no siempre, el actor que desencadena el caso de uso ".

    2.2.2 Actor de apoyo

    " Actor de apoyo en un caso de uso en un actor externo que brinda un servicio al sistema bajo diseño. Puede ser una impresora de alta velocidad, un servicio web o humanos que tienen que investigar y comunicarse con nosotros ".

    2.3 Ejemplo

    Nombre de caso de uso: Diagrama de flujo de trabajo
    Actor principal : Propietario del producto
    Actores secundarios: Software Development Company

    3. Epic

    Una historia de usuario perfecta debe ser lo suficientemente pequeña para que los desarrolladores puedan desarrollarla en una iteración. El beneficio de Agile User Stories es que están escritos en distintos niveles de detalle. Una historia de usuario puede cubrir una gran cantidad de funcionalidad. Cuando una historia de usuario es demasiado grande, se convierte en una épica.

    Una epopeya se puede definir como un trabajo, que no se puede completar en una semana, o cualquier trabajo que completará un sprint completo. 5-10 User Stories forman parte de una Epic en metodología ágil.

    Ejemplos:

    Estos son algunos ejemplos de ejemplos épicos
    User Stories.

    • Como usuario, quiero obtener una copia de seguridad de mi disco duro completo.
    • Como usuario, quiero escanear todo el disco duro para poder encontrar un archivo o carpeta específicos.
    • Como usuario, quiero una aplicación para poder guardar mi rutina diaria work.

    Una épica es demasiado grande para que un equipo ágil la complete en una iteración, por lo tanto, el equipo scrum divide las épicas en múltiples User Stories antes de trabajar en ella. Algunas épocas del tiempo se dividen en docenas o incluso cientos de Historias de usuarios.

    Historias de usuarios ágiles y acumulación de productos arreglados

    4. Cualidades de la historia de usuario

    Cualidades de las historias de los usuarios
    sintáctico
  • Bien formado
  • Automático
  • Mínimo
  • Semántico
  • Conceptualmente correcto
  • Problema orientado
  • No ambiguo
  • Libre de conflictos
  • Pragmático
  • Oración completa
  • estimable
  • Único
  • Uniforme
  • Independiente
  • Completo
  • Características de la historia de usuario en metodología de scrum ágil

    Cada historia de usuario tiene tres aspectos críticos. En Agile, este método se conoce como 3c de la historia de usuario. Que son:

    • Tarjeta
    • Conversación
    • Confirmación

    Ron Jeffries es el padre de la técnica 3c. Él es uno de los tres fundadores de la metodología de desarrollo de software XP (Extreme Programming) alrededor de 1996, junto con Kent Beck y Ward Cunningham.

    User Story Card (Una declaración de requisitos breves y simples desde la perspectiva del usuario)
  • Las historias de usuarios están escritas en tarjetas. Las tarjetas solo tienen texto, lo que ayuda al equipo de Agile a identificar el requisito, y ayudan al equipo a recordar cuál es la historia.
  • Estas tarjetas no contienen toda la información sobre los requisitos. Estas tarjetas de User Stories son como tokens que representan los requisitos.
  • Estas tarjetas son útiles para una planificación eficaz. Notas sobre los requisitos, las prioridades y los costos están escritos en él.
  • Estas tarjetas se entregan a los programadores cuando programan la implementación de la historia de usuario, y estas tarjetas también se devuelven a los clientes después de la finalización de la historia de usuario.
  • Conversación de la historia del usuario (Una historia es una invitación a la conversación)
  • La conversación es verbal en general, pero se puede documentar si es necesario. Los mejores aumentos son buenos ejemplos, y los mejores ejemplos son ejemplos ejecutables. Los ejemplos ejecutables también se llaman confirmación.
  • El requisito en sí es una comunicación entre el cliente y el desarrollador a través de una conversación con:
    • Intercambio de pensamientos
    • Sentimientos
    • Opiniones
  • Esta conversación de la historia de usuario se lleva a cabo entre el cliente y el programador cuando:
    • La historia se estima (principalmente durante la planificación de lanzamiento)
    • La historia está programada para implementación (En la reunión de planificación de iteración)
    Confirmación de historia de usuario (Cada historia debe tener criterios de aceptación)
  • Nunca estamos seguros del programa hasta que aprobamos la prueba de aceptación.
  • Cuando se completa la historia del usuario, los programadores también implementan la prueba de aceptación. Todos los equipos de Agile pueden procesar este paso de diferentes maneras. Algunos equipos tienen herramientas que permiten a los clientes probar el programa, mientras que algunos equipos tienen QA / Testers que hicieron este trabajo.
  • Se hace una prueba de aceptación, al final de una iteración, cuando la historia del usuario finaliza, los programadores muestran a los clientes que User Story está realizado y la prueba de aceptación se ejecuta correctamente.
  • La confirmación es una señal verde del cliente o del propietario del producto.
  • Muchas hojas de cálculo, diseños, bocetos e incluso muchos documentos de varias páginas se parece al método convencional, pero también es un método útil en algunos casos raros.
  • 5.1 Ron Jeffries dijo:

    Mirando hacia atrás con los años, casi nunca he encontrado que este tipo de documento sea ideal.

    Hoy en día ! Para un desarrollo ideal del programa, incluso para las situaciones complejas, el método 3c se considera mejor que cualquier otro método convencional. 3c es una técnica rápida que nunca ralentiza su proceso.

    6. Estimación de la historia del usuario

    Antes de comenzar su trabajo, el equipo de scrum debe saber qué tan grande es. La estimación de User Story es muy importante para scrum, facilita la producción de software, pero la estimación de User Story es realmente difícil. Hay pocas cosas que ayudan mucho en la estimación de la historia del usuario.

    Una medida registrada del esfuerzo necesario para completar una historia del usuario se denomina Estimación de la cuenta del usuario.

    Mantenga las estimaciones manejables: Haga su mejor esfuerzo para conservar la mayoría al menos las estimaciones más importantes dentro de un orden de magnitud (como 1 a 10). Por ejemplo, las cartas de póquer están entre 1 y 13, pero estimamos las cartas en un rango de secuencia de pozos. Lo que hace que la estimación sea fácil.
    Estimación en términos relativos: Estime su trabajo en términos relativos en lugar de términos absolutos. En lugar de decir que este trabajo tomará 10 días, diga que este trabajo tomará tiempo siempre y cuando el trabajo en el que trabajamos previamente en esa sesión. Con este método, el equipo no necesita pensar en subpasos de trabajo, solo encuentran un patrón similar y usan la misma estimación.
    Elementos de acumulación de depósitos por tamaño de historia: Es extremadamente difícil estimar las Historias de usuarios con precisión. El equipo de Scrum estima elementos de acumulación de depósitos por el tamaño de su historia, para este propósito el equipo puede elegir una estimación usando el método 1, 2, 4, 8 y 16 o secuencia de Fibonacci 1, 2, 3, 5, 8 y 13.

    7. User Story Mapping

    El desarrollo de software es un procedimiento complejo. Hay posibilidades de que un pequeño error pueda ocasionar fallas en el desarrollo del producto. Para obtener un mejor resultado en Agile, también nos centramos en User Stories para que nuestro procedimiento de desarrollo esté libre de errores. Para este propósito scrum master organiza User Stories en una secuencia útil para una mejor ejecución.

    Skills esenciales para cada Scrum Master

    User Story mapping es una técnica valiosa para organizar User Stories en un modelo útil para comprender la funcionalidad del sistema, identificar omisiones y grietas en la acumulación. User Story Mapeo es una forma visual de crear acumulación de producto.

    7.1 User Story Map Structure

    En el procedimiento de desarrollo Agile User Story mapeo no comienza desde una visión general.
    La visión se logra a partir de los objetivos. Las metas se logran al completar actividades. Las actividades se clasifican en Tareas y Tareas se transforman en historias de usuarios.

    Metas> Actividades> Tareas> Historias

    7.2 Ventajas de mapeo de historias

    • El mapeo de historias de usuarios nos ayuda a comprender la estructura de user story.
    • Explica cómo cada parte de User Story está relacionada con la otra.
    • Story mapping también ayuda a priorizar User Stories.
    • Acerca a todos los interesados ​​en la misma página con la presentación visual del producto backlog.
    • Story map se puede transformar en una herramienta de gestión de proyectos Agile como Mingle, Trello, Jira como Product Backlog.

    7.3 Related Guide Book

     Top_User_Story_Books_User_Story_Mapping_Discover_the_Whole_Story, _Build_the_Right_Product_By_Jeff_Patton _ & _ Peter_Economy Obtenga libro

    Jeff Patton tiene más de 20 años de experiencia en el diseño y desarrollo de productos. Él ayuda a las empresas a crear excelentes productos. Jeff es Entrenador de Scrum Certificado y ganador de Agile Alliance en 2007 del Gordon Pask Award por sus contribuciones al Desarrollo Ágil.

    7.3.1 Descripción

    Este libro explica cómo los mapas de historias cambiables permiten al equipo mantener mejores conversaciones. sobre el proyecto, a lo largo del proceso de desarrollo Ágil. Su equipo aprenderá cómo lograr una comprensión compartida de lo que está intentando construir y por qué.

    Libros principales para escribir buenas historias de usuarios en la metodología Agile Scrum


    El mapeo de historias de usuario es una herramienta valiosa para Agile desarrollo de software. Este perspicaz libro explica cómo esta técnica, a menudo mal comprendida, puede ayudar a su equipo a mantenerse enfocado en los usuarios y sus necesidades sin perderse en el entusiasmo por las características individuales del producto.

    8. DoD (Definición de Done)

    Cada equipo de scrum tiene una definición diferente de done. DoD describe la calidad del trabajo y ayuda en la evaluación de la finalización de la historia del usuario. DoD debe ser aplicado por scrum master durante el sprint, Scrum Master se asegura de que el equipo ponga el foco en la actividad correcta, y al final, producen el producto que es "enviable".

    Usando la definición de Done ( DoD) para garantizar el mejor scrum deliverables

    9. Criterios de aceptación de la historia del usuario

    Los criterios de aceptación y las condiciones de satisfacción se usan indistintamente. Cada historia de usuario se acepta cuando pasa los criterios de aceptación. Los criterios de aceptación son una lista de parámetros que definen la calidad de la historia del usuario.

    Criterios de aceptación proporciona un alcance detallado de requisitos que ayuda al equipo a comprender los requisitos y valores de la historia del usuario. Además, el equipo puede dividir fácilmente la historia del usuario.

    ¿Quién escribe Acceptance Criteria?

    El propietario del producto es la persona responsable de los criterios de aceptación. Él define los criterios de aceptación según su necesidad. Después del desarrollo del producto, el propietario del producto verifica la lista de criterios de aceptación para aceptar o rechazar el producto.

    Ejemplo de criterio de aceptación de historias de usuario

    Los criterios de aceptación pueden incluir:

    • Coloración y diseño de producto
    • La información se puede almacenar en la base de datos
    • Confirmación de correo electrónico
    • Límite de palabras (Mín. y Máx.)
    • Características requeridas en Historias de usuarios actuales

You Might Also Like

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

Powered by themekiller.com