![\"\"](\"https:\/\/guides.visual-paradigm.com\/wp-content\/uploads\/2023\/09\/img_650875711142f.png\")
<\/p>\nEn el desarrollo \u00e1gil, la historia de usuario es un bloque fundamental para entregar valor al cliente. Estas descripciones concisas de la funcionalidad deseada capturan el ‘qui\u00e9n’, ‘qu\u00e9’ y ‘por qu\u00e9’ de una caracter\u00edstica o requisito. Sin embargo, para asegurar que las historias de usuario sean tanto accionables como verificables, los equipos \u00e1giles a menudo utilizan una t\u00e9cnica llamada ‘Give \/ When \/ Then’ (GWT) para los criterios de aceptaci\u00f3n. Este m\u00e9todo ayuda a definir el comportamiento esperado de una historia de usuario de manera clara y precisa.<\/p>\n
<\/p>\n
Los criterios de aceptaci\u00f3n son condiciones o reglas que una historia de usuario debe cumplir para considerarse completa. Act\u00faan como un puente entre la visi\u00f3n del propietario del producto y la implementaci\u00f3n del equipo de desarrollo. En esencia, definen los l\u00edmites y expectativas para cada historia de usuario. Sin criterios de aceptaci\u00f3n bien definidos, una historia de usuario puede ser susceptible a interpretaciones, lo que lleva a malentendidos y posibles re-trabajos.<\/p>\n
Give \/ When \/ Then es un formato para elaborar criterios de aceptaci\u00f3n que se ha tomado del Desarrollo Dirigido por Comportamiento (BDD). Fomenta una forma m\u00e1s estructurada y comprensible de expresar el comportamiento deseado de una historia de usuario. El formato consta de tres partes:<\/p>\n
Consideremos un ejemplo sencillo para un sitio web de comercio electr\u00f3nico:<\/p>\n
Historia de usuario<\/strong>: Como cliente, quiero poder agregar art\u00edculos a mi carrito de compras para poder comprarlos m\u00e1s tarde.<\/p>\n Criterios de aceptaci\u00f3n (GWT)<\/strong>:<\/p>\n En este ejemplo, los criterios de aceptaci\u00f3n proporcionan una comprensi\u00f3n clara de lo que se espera del cuento de usuario, lo que lo hace accionable y verificable.<\/p>\n Descripci\u00f3n del problema Estudio de caso:<\/strong><\/p>\n Consideremos un estudio de caso para una aplicaci\u00f3n popular de compartici\u00f3n de viajes como Uber. El problema actual es mejorar la experiencia del usuario al introducir una funci\u00f3n que permita a los pasajeros programar viajes con fechas y horas espec\u00edficas.<\/p>\n Cuentos de usuario con criterios de aceptaci\u00f3n GWT:<\/strong><\/p>\n Cuento de usuario 1: Programar un viaje con anticipaci\u00f3n<\/strong><\/p>\n Como pasajero<\/strong>, quiero poder programar un viaje para una fecha y hora espec\u00edficas con anticipaci\u00f3n, para que pueda planificar mejor mis viajes<\/strong>.<\/p>\n Criterios de aceptaci\u00f3n (GWT):<\/strong><\/p>\n Cuento de usuario 2: Editar o cancelar un viaje programado<\/strong><\/p>\n Como pasajero<\/strong>, quiero tener la opci\u00f3n de editar o cancelar un viaje programado, en caso de que cambien mis planes<\/strong>.<\/p>\n Criterios de aceptaci\u00f3n (GWT):<\/strong><\/p>\n Historia de usuario 3: Notificar a los conductores sobre los viajes programados<\/strong><\/p>\n Como conductor<\/strong>, quiero recibir notificaciones cuando un pasajero programa un viaje conmigo, para que pueda planificar mi disponibilidad<\/strong>.<\/p>\n Criterios de aceptaci\u00f3n (GWT):<\/strong><\/p>\n Historia de usuario 4: Proporcionar comentarios sobre los viajes programados<\/strong><\/p>\n Como pasajero<\/strong>, quiero poder proporcionar comentarios y calificar a los conductores para los viajes programados, para ayudar a mantener la calidad del servicio<\/strong>.<\/p>\n Criterios de aceptaci\u00f3n (GWT):<\/strong><\/p>\n Estas historias de usuario y sus criterios de aceptaci\u00f3n asociados Give \/ When \/ Then abordan el problema de introducir una funci\u00f3n de programaci\u00f3n de viajes en una aplicaci\u00f3n de compartici\u00f3n de viajes. Al seguir este enfoque estructurado, el equipo de desarrollo puede asegurar una comprensi\u00f3n clara de los requisitos y del comportamiento esperado de la nueva funci\u00f3n, lo que finalmente conduce a una mejor experiencia de usuario.<\/p>\n Los criterios de aceptaci\u00f3n Give \/ When \/ Then ofrecen un enfoque estructurado para definir el comportamiento esperado de las historias de usuario en el desarrollo \u00e1gil. Al dividir los criterios en tres secciones distintas \u2013 Dado, Cuando y Entonces \u2013 los equipos pueden lograr una mayor claridad, verificabilidad y alineaci\u00f3n, lo que finalmente conduce a un desarrollo de producto m\u00e1s exitoso. Incorporar este formato en tu proceso \u00e1gil puede ayudar a tu equipo a entregar software de alta calidad que cumpla con las expectativas del usuario.<\/p>\n","protected":false},"excerpt":{"rendered":" En el desarrollo \u00e1gil, la historia de usuario es un bloque fundamental para entregar valor al cliente. Estas descripciones concisas de la funcionalidad deseada capturan el ‘qui\u00e9n’, ‘qu\u00e9’ y ‘por qu\u00e9’ de una caracter\u00edstica o requisito. Sin embargo, para asegurar que las historias de usuario sean tanto accionables como verificables, los equipos \u00e1giles a menudo utilizan una t\u00e9cnica llamada ‘Give \/ When \/ Then’ (GWT) para los criterios de aceptaci\u00f3n. Este m\u00e9todo ayuda a definir el comportamiento esperado de una historia de usuario de manera clara y precisa. \u00bfQu\u00e9 son los criterios de aceptaci\u00f3n? Los criterios de aceptaci\u00f3n son condiciones o reglas que una historia de usuario debe cumplir para considerarse completa. Act\u00faan como un puente entre la visi\u00f3n del propietario del producto y la implementaci\u00f3n del equipo de desarrollo. En esencia, definen los l\u00edmites y expectativas para cada historia de usuario. Sin criterios de aceptaci\u00f3n bien definidos, una historia de usuario puede ser susceptible a interpretaciones, lo que lleva a malentendidos y posibles re-trabajos. La estructura de los criterios de aceptaci\u00f3n Give \/ When \/ Then Give \/ When \/ Then es un formato para elaborar criterios de aceptaci\u00f3n que se ha tomado del Desarrollo Dirigido por Comportamiento (BDD). Fomenta una forma m\u00e1s estructurada y comprensible de expresar el comportamiento deseado de una historia de usuario. El formato consta de tres partes: Dado: Esta secci\u00f3n describe el contexto inicial o estado del sistema. Establece el escenario para la situaci\u00f3n que est\u00e1s describiendo. En esencia, proporciona la informaci\u00f3n de fondo necesaria para comprender el escenario. Cuando: Esta secci\u00f3n representa la acci\u00f3n o evento que desencadena el comportamiento descrito en la historia de usuario. Es el evento espec\u00edfico que realiza el usuario o que ocurre dentro del sistema. Entonces: Esta secci\u00f3n describe el resultado o resultado esperado de la acci\u00f3n o evento descrito en la secci\u00f3n ‘Cuando’. Define lo que deber\u00eda suceder como consecuencia de la acci\u00f3n, a menudo en t\u00e9rminos de cambios observables en el sistema o aplicaci\u00f3n. Beneficios de los criterios de aceptaci\u00f3n Give \/ When \/ Then Claridad: El formato GWT ofrece una forma estructurada y f\u00e1cil de entender para expresar el comportamiento esperado de una historia de usuario. Esto reduce la ambig\u00fcedad y asegura que todos los miembros del equipo de desarrollo, incluidos desarrolladores, testers y propietarios del producto, tengan una comprensi\u00f3n clara de lo que debe hacerse. Verificabilidad: El formato se presta naturalmente a casos de prueba. Cada componente ‘Dado’, ‘Cuando’ y ‘Entonces’ puede traducirse en escenarios de prueba espec\u00edficos, lo que facilita comprobar que la historia de usuario se ha implementado correctamente. Alineaci\u00f3n: Los criterios de aceptaci\u00f3n GWT fomentan la colaboraci\u00f3n entre los miembros del equipo. Los propietarios del producto, desarrolladores y testers pueden trabajar juntos para definir y perfeccionar los criterios, asegurando que todos est\u00e9n alineados respecto al alcance y expectativas de la historia. Ejemplos de criterios de aceptaci\u00f3n Give \/ When \/ Then Consideremos un ejemplo sencillo para un sitio web de comercio electr\u00f3nico: Historia de usuario: Como cliente, quiero poder agregar art\u00edculos a mi carrito de compras para poder comprarlos m\u00e1s tarde. Criterios de aceptaci\u00f3n (GWT): Dado Estoy en la p\u00e1gina del producto Cuando Hago clic en el bot\u00f3n ‘Agregar al carrito’ para un producto Entonces El producto deber\u00eda agregarse a mi carrito de compras YEl \u00edcono del carrito en la barra de navegaci\u00f3n deber\u00eda mostrar el recuento actualizado de art\u00edculos YDeber\u00eda ver un mensaje de confirmaci\u00f3n que indique la adici\u00f3n del producto al carrito En este ejemplo, los criterios de aceptaci\u00f3n proporcionan una comprensi\u00f3n clara de lo que se espera del cuento de usuario, lo que lo hace accionable y verificable. Descripci\u00f3n del problema Estudio de caso: Consideremos un estudio de caso para una aplicaci\u00f3n popular de compartici\u00f3n de viajes como Uber. El problema actual es mejorar la experiencia del usuario al introducir una funci\u00f3n que permita a los pasajeros programar viajes con fechas y horas espec\u00edficas. Cuentos de usuario con criterios de aceptaci\u00f3n GWT: Cuento de usuario 1: Programar un viaje con anticipaci\u00f3n Como pasajero, quiero poder programar un viaje para una fecha y hora espec\u00edficas con anticipaci\u00f3n, para que pueda planificar mejor mis viajes. Criterios de aceptaci\u00f3n (GWT): Dado queTengo la aplicaci\u00f3n de compartici\u00f3n de viajes instalada y estoy conectado CuandoAbro la aplicaci\u00f3n e ingreso mi destino, fecha y hora para el viaje EntoncesLa aplicaci\u00f3n deber\u00eda mostrar los conductores disponibles para la fecha y hora seleccionadas YDeber\u00eda poder confirmar y programar el viaje YDeber\u00eda recibir una notificaci\u00f3n de confirmaci\u00f3n con los detalles del viaje programado Cuento de usuario 2: Editar o cancelar un viaje programado Como pasajero, quiero tener la opci\u00f3n de editar o cancelar un viaje programado, en caso de que cambien mis planes. Criterios de aceptaci\u00f3n (GWT): Dado queTengo un viaje programado CuandoAbro la aplicaci\u00f3n y navego hasta mis viajes programados EntoncesDeber\u00eda ver una lista de mis pr\u00f3ximos viajes programados YDeber\u00eda poder seleccionar un viaje para editar la fecha y hora o cancelarlo YSi edito el viaje, la aplicaci\u00f3n deber\u00eda mostrar los conductores disponibles para la fecha y hora actualizadas YDeber\u00eda recibir una notificaci\u00f3n de confirmaci\u00f3n por cualquier cambio realizado Historia de usuario 3: Notificar a los conductores sobre los viajes programados Como conductor, quiero recibir notificaciones cuando un pasajero programa un viaje conmigo, para que pueda planificar mi disponibilidad. Criterios de aceptaci\u00f3n (GWT): Dado queSoy un conductor activo con la aplicaci\u00f3n de compartici\u00f3n de viajes abierta Cuandoun pasajero programa un viaje conmigo para una fecha y hora espec\u00edficas EntoncesDeber\u00eda recibir una notificaci\u00f3n en tiempo real con los detalles del viaje programado YLa aplicaci\u00f3n deber\u00eda mostrar el viaje programado en mi panel de conductor YDeber\u00eda poder aceptar o rechazar el viaje programado dentro de un plazo razonable Historia de usuario 4: Proporcionar comentarios sobre los viajes programados Como pasajero, quiero poder proporcionar comentarios y calificar a los conductores para los viajes programados, para ayudar a mantener la calidad del servicio. Criterios de aceptaci\u00f3n (GWT): Dado quehe completado un viaje programado Cuandoabro la aplicaci\u00f3n despu\u00e9s de que finalice el viaje Entoncesdeber\u00eda tener la opci\u00f3n de calificar alCriterios de aceptaci\u00f3n Give \/ When \/ Then para historias de usuarios en el desarrollo \u00e1gil<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_yoast_wpseo_title":"","_yoast_wpseo_metadesc":"","_eb_attr":"","neve_meta_sidebar":"","neve_meta_container":"","neve_meta_enable_content_width":"","neve_meta_content_width":0,"neve_meta_title_alignment":"","neve_meta_author_avatar":"","neve_post_elements_order":"","neve_meta_disable_header":"","neve_meta_disable_footer":"","neve_meta_disable_title":"","fifu_image_url":"","fifu_image_alt":"","footnotes":""},"categories":[13,6],"tags":[],"class_list":["post-6479","post","type-post","status-publish","format-standard","hentry","category-agile-scrum","category-agile-development"],"yoast_head":"\n\n
\n
\n
\n
\n
Conclusi\u00f3n<\/strong><\/h3>\n