Qué es la historia del Usuario y los criterios de aceptación (ejemplos)

Una guía perfecta para los criterios de aceptación de la historia del usuario con escenarios de la vida real:

en la industria del desarrollo de Software, la palabra «requisito» define cuál es nuestro objetivo, qué necesitan exactamente los clientes y qué hará que nuestra empresa aumente su negocio.

ya sea una empresa de productos que fabrica productos de software o una empresa de servicios que ofrece servicios en varios campos de software, la base principal para todos ellos es el requisito y el éxito se define por lo bien que se cumplen los requisitos.,

el término ‘requisito’ tiene diferentes nombres en diferentes metodologías de proyecto.

en Waterfall, se le conoce como ‘documento de requisitos / especificaciones’, en Agile o SCRUM se le conoce como’ Epic’,’historia de usuario’.

en el modelo de Cascada, los documentos de requisitos son enormes documentos de 200 o más páginas, ya que todo el producto se implementa en una fase. Pero este no es el caso de Agile / SCRUM porque en estas metodologías se dan los requisitos para pequeñas funcionalidades o características a medida que el producto se prepara paso a paso.,

en este artículo, he hecho todo lo posible para compartir todos mis 4 años de experiencia trabajando con historias de usuarios y sus criterios de aceptación relacionados, junto con escenarios fáciles y simples de la vida real para su mejor comprensión.

volvamos a visitar los fundamentos primero.

¿qué es una historia de usuario?

Una historia de usuario es un requisito para cualquier funcionalidad o característica que se escriba en una o dos líneas y un máximo de 5 líneas. Una historia de usuario suele ser el requisito más simple posible y se trata de una y solo una funcionalidad (o una característica).,

el más comúnmente utilizado El formato estándar para un Usuario creación de la Historia que se indica a continuación:

Como <función de usuario/cliente, Quiero < meta a alcanzar> así que puedo <motivo de la meta de>.

ejemplo:

como usuario de WhatsApp, quiero un icono de cámara en el cuadro de escritura de chat para capturar y enviar fotos para que pueda hacer clic y compartir mis fotos simultáneamente con todos mis amigos.

¿Qué es un criterio de aceptación?,

un criterio de aceptación es un conjunto de condiciones aceptadas o reglas de negocio que la funcionalidad o característica debe satisfacer y cumplir, con el fin de ser aceptado por el propietario del Producto/Partes Interesadas.

Esta es una parte muy importante de la finalización de la historia del usuario y debe ser estudiada por el propietario del producto y analista de negocios muy meticulosamente porque perder un solo criterio puede costar mucho. Esta es una lista simple numerada o con viñetas.

su formato es el siguiente:

«dada alguna condición previa cuando hago alguna acción, espero el resultado».

Ejemplo (w.r.,t a la historia de usuario anterior):

• consideremos que estoy chateando con un amigo y debería ser capaz de capturar una imagen.
• Cuando hago clic en una imagen, debería poder agregar un título a la imagen antes de enviarla.
• si hay algún problema con el inicio de la cámara de mi teléfono, un mensaje de error como ‘Camera could not be started’. sucesivamente., debe mostrarse en consecuencia.

por lo tanto, la historia de usuario define el requisito para cualquier funcionalidad o característica, mientras que los criterios de aceptación definen la ‘definición de hecho’ para la historia de usuario o el requisito.,

como QA es muy importante entender la historia del usuario y sus criterios de aceptación profundamente sin que quede ni una sola duda al ‘inicio de las pruebas’. Vamos a entender por qué es extremadamente importante profundizar en las historias de usuario y los criterios de aceptación.

profundizando en las historias de usuario

para empezar, primero entendamos la importancia de un estudio «en profundidad» de una cosa básica y fundamental, es decir, las historias de usuario.

Los siguientes casos son mis propias experiencias reales.,

Caso #1:

antes de 3 años, estaba trabajando en un proyecto de aplicación móvil y el producto era una aplicación que estaba diseñada para las personas de entrega.

usted habría visto a una persona de entrega que viene a su lugar para la entrega. Y tienen un teléfono móvil en el que le piden que dé su firma después de la entrega. Esta firma se refleja en el portal de los proveedores de servicios de mensajería como DTDC, FedEx, etc.

imaginemos que la aplicación móvil acaba de lanzarse y sus portales ya existen y están en marcha.,

problema: para un Sprint, el propietario del producto tiene una historia de usuario para esta aplicación móvil que «como administrador del Portal, debería poder ver la firma tomada por la persona de entrega en el momento de la entrega». Aquí el portal (aplicación web) se cambia y actualiza en consecuencia para reflejar la firma.

como QA, debe verificar si la firma capturada en la aplicación móvil se refleja como se espera en el portal.,

si nos fijamos en esta historia de usuario, parece simple, pero hay un requisito oculto aquí que «para las entregas históricas, no había funcionalidad de reflexión de firma, así que ¿qué debería suceder si los chicos del portal ven las entregas históricas?»¿Deberían eliminarse los datos históricos? ¿Debemos permitir bloqueos o errores para dichos datos?

Por supuesto que no, esto debe manejarse con amabilidad.,

solución: cuando las respectivas tablas de BD se actualizan para agregar una nueva columna para la ubicación de la firma, los datos antiguos deben tener un valor NULL o 0 que se debe verificar y se debe mostrar un mensaje que indica que No existe firma.

esto se puede llamar como una falta del propietario del producto o analista de negocios, pero esto tiene que hacerse. Implementar una característica con éxito, pero romper algo junto con ella no es deseable por los clientes. Esto debe hacerse junto con la misma historia de usuario y en el mismo sprint.,

Case #2

hace 6 años, estaba trabajando en una aplicación de planificación financiera para la jubilación (sin BA) que era una aplicación global donde la gente de Finanzas como CA, Asesores Financieros podían usarla para diferentes monedas para proyectar los planes de inversión, ahorros, etc., durante un gran período a sus clientes.

problema: el propietario del producto le da una historia de usuario que «como Asesor, quiero ver el informe de mi cliente basado en los detalles financieros proporcionados».,

aquí había 2 Requisitos ocultos y yo lo llamaría como una historia incompleta porque:

a] los informes deben considerar la tasa de conversión de moneda diaria y no la histórica como en el último informe visto y

b] si la moneda se cambia después de proporcionar los detalles financieros del cliente, los informes deben mostrar en la moneda cambiada.

solución: planteé esta preocupación directamente con nuestro propietario del producto y le hice saber que ambos tenían que hacerse lo antes posible. Estuvo de acuerdo conmigo y creó 2 historias diferentes para los próximos sprints con prioridad.,

Take Away: estos fueron capturados porque todos éramos muy conscientes de los productos, su diseño, estructura, etc. Este conocimiento solo se puede lograr mediante la comprensión completa del producto, mediante la comprensión de la interoperabilidad de los módulos y mediante el estudio de la historia del Usuario a fondo, incluso si se trata de un 2 liner.

Tome notas para hacer las cosas más fáciles y discuta con los BA y los desarrolladores acerca de su forma de pensar.,

ver en profundidad los criterios de aceptación

comprender los criterios de aceptación y todas las demás condiciones& reglas exhaustivas es incluso más importante que subestimar una historia de usuario. Porque si un requisito es incompleto o vago, se puede tomar en el siguiente sprint, pero si se pierde un criterio de aceptación, entonces la historia del usuario en sí no se puede publicar.

supongo que todos habríamos utilizado Net banking en algún momento y la mayoría de nosotros lo usamos todos los días Y DESCARGO mis declaraciones históricas mucho., Si lo observa cuidadosamente, hay ciertas opciones específicas disponibles para descargarlos.

Hay una opción para seleccionar el tipo de archivo para descargar su estado de cuenta. Hay una opción para elegir si desea descargar solo los créditos / débito / ambos.

Ahora imagine que el propietario del producto le da esta historia de usuario «como cliente, quiero descargar mi estado de cuenta para que pueda ver todas mis transacciones realizadas durante un período específico».,

con los siguientes criterios de aceptación:

• Teniendo en cuenta que estoy en la página descargar Declaración histórica, debo seleccionar el período Para el que quiero descargar la declaración.
• Teniendo en cuenta que estoy en la página descargar Declaración histórica, debo seleccionar la cuenta para la que quiero descargar la declaración.
• Teniendo en cuenta que estoy en la página de Descarga de la Declaración histórica, no se me debe permitir descargar la declaración para una fecha futura «hasta».,
• Teniendo en cuenta que estoy en la página de Declaración histórica de descarga, no se me debe permitir seleccionar la fecha ‘de’ 10 años más allá en el pasado.
• Teniendo en cuenta que descargo mi declaración, debería poder ver el archivo descargado.
• Teniendo en cuenta que estoy en la página de descargar Declaración histórica, debería poder descargar mi declaración en formatos doc, excel y pdf.

si pasas por esta aceptación, hay 3 cosas que faltan aquí:

• Nombre y formato del nombre del archivo que se descargará.,
• Qué información (nombres de columna) se mostrará en el archivo.
• La lista de opciones para seleccionar qué tipo de transacción desea el cliente, es decir, solo débitos o solo créditos o ambos.

estos casos pueden ocurrir de vez en cuando, sin embargo, todavía estudiar bien acerca de cada criterio de aceptación y tratar de visualizarlo con referencia a la historia del usuario. Cuanto más profundice en las condiciones y reglas de negocio, más será su conocimiento sobre la característica.

Los errores encontrados en la etapa inicial no cuestan nada en comparación con lo que puede costar en la etapa ‘testing’.,

importancia de encontrar discrepancias en la historia del Usuario/criterios de aceptación

siempre es importante hacer una inmersión profunda en las historias del usuario y los criterios de aceptación en una etapa temprana, incluso antes de que comience el desarrollo o las pruebas.

porque implica:

#1) desperdicio de tiempo:

si las discrepancias o errores en la historia del usuario/criterios de aceptación se encuentran cuando se está desarrollando o se está probando, entonces puede ser necesario realizar una gran cantidad de trabajo en el tiempo de sprint restante.,

no sucede que incluso si el propietario del producto se perdió algunas cosas, moverá la historia del usuario al próximo sprint. El 95% de las posibilidades es que pidan al equipo que haga la implementación necesaria y la libere en el mismo sprint.

Por lo tanto, se convierte en una pesadilla para el equipo, ya que tienen que pasar tiempo extra, venir los fines de semana o trabajar hasta tarde por la noche. Esto se puede evitar estudiando y discutiendo la historia del usuario / criterios de aceptación en la etapa más temprana posible.

#2) desperdicio de esfuerzos:

los desarrolladores y QA tienen que revisar el código implementado y los casos de prueba de nuevo., Actualizar, agregar y eliminar como requisito no es una tarea fácil. Se vuelve demasiado doloroso ya que ya hay una presión para entregar a tiempo.

en tal situación, hay posibilidades de errores en la etapa de desarrollo o prueba. Si te encuentras con tal situación, ve por ‘Devqa Pairing’. Como guinda del pastel, es posible que no obtenga una compensación por el trabajo adicional.

conclusión

la comprensión profunda de la historia del Usuario y los criterios de aceptación solo se pueden lograr dedicando un tiempo inmenso a estudiarla.,

no hay ninguna herramienta o curso específico disponible en el mercado para hacer esto por usted, ya que se trata de pensamiento lógico, experiencia y conocimiento sobre el producto.

participar activamente en la reunión previa al plan, hablar con BA, estudiar por su cuenta solo puede ayudarlo a lograr esto. Cuantos más esfuerzos pongas, más aprenderás y crecerás.

ya sea el QA o los desarrolladores, todo el mundo tiene que estar en la misma página sobre las historias de usuario y sus criterios de aceptación, solo entonces las expectativas del cliente se pueden lograr con éxito.,

¿Tiene algo nuevo que compartir con nosotros sobre sus experiencias al trabajar con historias de usuarios? Por favor, expresar sus pensamientos a continuación!!