Crea una cuenta o inicia sesión

¡Continúa aprendiendo sin ningún costo! Únete y comienza a potenciar tu carrera

¿Por qué fracasan los esfuerzos de implementar Historias de Usuario?

3/11
Recursos

¿Por qué fracasan los esfuerzos de implementar historias de usuario?

Aprender sobre la implementación de las historias de usuario puede ser abrumador. Aunque la teoría parece simple, ¿por qué todavía encontramos obstáculos en su aplicación práctica? Exploremos las principales razones por las que fallan los esfuerzos al implementar historias de usuario, y qué podemos hacer al respecto.

¿Cómo la simplicidad puede ser nuestra enemiga?

Uno de los errores comunes al implementar historias de usuario es la falta de simplicidad. A menudo, describimos estas historias en un lenguaje de bajo nivel, centrándonos en las funcionalidades.

  • Épicas vs. historias de usuario: Cuando integramos múltiples funcionalidades bajo una historia, lo que realmente estamos creando son "épicas", narrativas que describen un módulo más completo y no una sola funcionalidad.
  • De lo general a lo específico: Trabajar del lenguaje de negocio hacia abajo puede llevarnos a mezclar funcionalidades, perdiendo de vista nuestro objetivo principal: ayudar al desarrollador para que pueda abstraerse desde lo simple hasta las líneas de código.

Practicar con historias de usuario simples que describen funcionalidades individuales es clave para el éxito.

¿Por qué es vital conocer el "para quién" y el "para qué"?

La subestimación de la importancia del destinatario y el propósito de una funcionalidad es otro motivo frecuente de las fallas.

  • Conociendo al usuario: Ignorar la pregunta "¿para quién?" puede llevarnos a descubrir demasiado tarde un nuevo tipo de usuario. Técnicas como el "buyer persona" ayudan a definir para quién realmente estamos trabajando.
  • Entendiendo el objetivo: No basta con que el equipo de negocio conozca el propósito. El equipo de desarrollo también necesita entender el "¿para qué?", pues esto ofrece contexto y dirección al proceso de diseño.

Mantener una línea directa entre el desarrollo y los beneficios finales asegura que el equipo no pierda de vista el verdadero valor que se está buscando.

¿Las historias de usuario son la única forma de especificar?

Caer en la creencia de que las historias de usuario son el único método de especificación limita nuestra agilidad y efectividad.

  • Más allá de Scrum: La agilidad no se define únicamente por el uso de historias de usuario. Aunque son fundamentales, es crucial conectar y complementar con otras formas de especificación, adaptando los métodos de trabajo a las necesidades del equipo.
  • El Backlog en el marco Scrum: Este elemento esencial de planificación se construye sobre “elementos de trabajo”, los cuales pueden incluir historias de usuario, pero no se limitan a ellas. Dimensiones y contexto adicionales mejoran la capacidad del equipo para abordar proyectos complejos.

Ampliar nuestra herramienta de especificación más allá de las historias de usuario nos ayuda a entender mejor y a dimensionar el proyecto en su totalidad.

¿Cómo asegurar un entendimiento común sin documentación excesiva?

En un entorno ágil, una confusión generalizada es que no se debe documentar. No obstante, el entendimiento y la documentación son cruciales para el éxito del proyecto.

  • Documentación funcional: En lugar de abundante documentación, el enfoque debería ser "documentar para entender". Este tipo de documentación comienza con el backlog y fluye a través de todas las etapas del proceso ágil.
  • Medición del progreso: Una de las prioridades del manifiesto ágil es valorar el software funcional sobre documentación extensa. La correcta dimensión y entendimiento puede lograrse sin caer en la trampa de la documentación excesiva.

Adoptar una mentalidad de documentación práctica permite al equipo alinearse de manera más efectiva sobre los objetivos, asegurando la entrega del valor esperado.

Anímate a practicar estas ideas y participa activamente en el diseño de tus historias de usuario. La experimentación y el aprendizaje constante son los mejores aliados para mejorar nuestras habilidades en este campo. ¡No olvides aportar tus dudas para seguir aprendiendo juntos!

Aportes 60

Preguntas 20

Ordenar por:

¿Quieres ver más aportes, preguntas y respuestas de la comunidad?

En resumen las historias fracasan porque:

  • Subestimamos el para quién
  • No tenemos claro para que hacemos lo que hacemos
  • Scrum no son sólo historias de usuario

Mis HU

En mi experiencia, lo que mas hace fallar una historia de usuasrio es que no esten escritas a nivel de funciones sino a nivel de modulos.

Esto hace que la estimacion a su vez sea a alto nivel, mas abstracta, y no a un bajo nivel, mas concreta, de tal manera que nos de mayor confianza en el estimado.

Me encanto esta parte

Esta es mi historia de usuario:

¿Por qué fracasan los esfuerzos de implementar Historias de Usuario?

Porque falla la simplicidad

  • Tener en claro diferencia entre una épica y una historia de usuario.

Porque subestimamos la simplicidad

  • No subestimar para quién se está trabajando. Utilizar el Buyer persona es una excelente opción. Saber el para qué nos da el contexto para su funcionalidad.

Porque no solo de historias vive scrum

Una Historia de Usuario fracasa cuando no cumple con el invest reduciendo la complejidad y esfuerzo.
Independiente - Negociable - Valor - Estimable - Small - Testeable

Envío mis historias de usuario. Mi herramienta preferida es Jira, aunque éstas las hice en Trello

MI historia de usuario:

Clave – Registro de ingresos mensuales

Quién Yo como <asesor comercial>
Qué lo que quiero es <registrar los ingresos mensuales del cliente>
Para qué Para lograr / con el objetivo de / para obtener el beneficio de <que el sistema calcule si es apto para credito >
Criterios de aceptación
1 Que el valor ingresado sea positivo
2 Que el valor este en COP
3 Que el valor ingresado sea un numero entero
4 Debe existir solo 1 valor por cada cliente
N Condición n

Hola tengo una duda, supongamos un típico programa con diversos tipos de usuarios: admin, editor, gestor, user, invitado... por decir algunos. Al escribir la historia de usuario donde se indica por ejemplo la funcionalidad de borrar publicaciones teniendo en cuenta que admin, editor y gestor pueden y los otros 2 no. Deberíamos escribir una historia de usuario por cada tipo de usuario. Es decir: Como admin quiero borrar publicaciones para poder controlar que se publica en el programa. Como gestor quiero borrar publicaciones para poder controlar que se publica en el programa. Como editor quiero borrar publicaciones para poder controlar que se publica en el programa. Serían 3 historias de usuario que son casi repetidas, imaginate un programa muy grande con diversos tipos de usuario. Cada funcionalidad se debe crear una historia de usuario para cada tipo de usuario? o se realizaría de otro modo.
Debe describir una sola funcionalidad y no un modulo completo Se subestima la funcionalidad de para que y para quien Técnica del buyer persona, podrían servir para definir el para quien. Se debe dejar claro el para que, el contexto Documentar para podernos entender
  • Como usuario del sistema lo que quiero es ser capaz de realizar mi prueba de vida para poder validar que estoy yendo a entregar mi documentación voluntariamente.
    Criterios: Permitir grabar un video en vivo del rostro del usuario. | Almacenar el video para su posterior validación.

Simil con un libro y las matrioskas
Historias del usuario=Descripcion simple (Prologo)
Epicas=Capitulos

  1. Descargar la aplicación: Yo como vendedor lo que quiero es un APK para lograr instar la aplicación.

Criterios de aceptación:
*Recepción por Intranet del archivo APK de descarga.
*APK para Android 7 o superior.

  1. Yo como vendedor lo que quiero es iniciar sesión mediante usuario y contraseña secreta para lograr ingresar a la aplicación.

Criterios de aceptación:
*Usuario debe ser el número de identificación del vendedor.
*Contraseña mayor a 8 caracteres incluyendo, al menos, 2 números.
*Permitir visualización de usuario y contraseña mientras se digitan.

  1. Yo como vendedor lo que quiero es una pantalla con las solicitudes para lograr visualizar el estatus de cada una.

Criterios de aceptación:
*Listado de solicitudes organizado por código interno.
*Esta pantalla será la inicial al ejecutar la aplicación.
*Mostrar en la lista únicamente las solicitudes que han sido procesadas por el ejecutivo de cuenta que se loguea.
*Colocar un botón que direccione al alta de una nueva solicitud.

  1. Yo como vendedor lo que quiero es poder seleccionar el identificador interno de cada solicitud para lograr revisar su estatus.

Criterios de aceptación:
*Poder dar clic sobre el identificador.
*Identificador enlazado con ventana que informe el status de esa solicitud.

  1. Yo como vendedor lo que quiero es ingresar una nueva solicitud desde la pantalla de inicio para iniciar un nuevo proceso de verificación.

Criterios de aceptación:
*Asignar un identificador interno a la nueva solicitud.
*Direccionar a una nueva pantalla con el formato para ingresar los datos correspondientes.
*Acceder mediante el botón “nueva solicitud” ubicado en la página principal.
*Al finalizar el ingreso de la nueva solicitud, debe consolidarse en la lista de solicitudes de la pantalla principal.

![](https://static.platzi.com/media/user_upload/image-bc933073-a0dd-493f-bc27-77af39b12560.jpg)
Mis HU ![](https://static.platzi.com/media/user_upload/hc2-fb1bb1dd-a206-4cb5-9f9f-73460390480d.jpg)![](https://static.platzi.com/media/user_upload/hc3-8d754046-c702-45d1-b2e7-9fe322979f85.jpg)
![](https://static.platzi.com/media/user_upload/hc1-46d703dc-8e25-423e-83e6-e4e6a4feef16.jpg)
Hola, comparto mi ejercicio, según comprendí que debía realizarse. ![](https://static.platzi.com/media/user_upload/Captura%20de%20pantalla%202024-09-17%20a%20la%28s%29%201.20.39p.m.-3034e69c-6fa1-4f63-b5aa-dc46590ac53f.jpg)![]()![]()![](<Captura de pantalla 2024-09-17 a la(s) 1.20.39 p.m.>)
![](https://static.platzi.com/media/user_upload/HU-f440fbde-58c2-4697-ab56-674550a71528.jpg):)
Ponerse en los zapatos del usuario es importante, indagar en el ¿**Para qué**? Ayudará a descubrir lo que realmente hace falta. Una vez identificada la necesidad, recién ahí prospectar soluciones.
**Falta de comunicación entre el equipo de desarrollo y el cliente:** Es importante que haya una comunicación fluida entre el equipo de desarrollo y el cliente para garantizar que todos estén en la misma página. Si no hay una buena comunicación, las historias de usuario pueden malinterpretarse y el producto final no cumplir con las expectativas del cliente.
Mis H.U![](https://static.platzi.com/media/user_upload/Cards%20Historia%20de%20Usuario-0ffe003e-d62f-48f3-8f05-18d452ac0e3f.jpg)
aquí mis historias de usuario ![](https://static.platzi.com/media/user_upload/image-4b5a2de4-b1da-4106-a038-7e73aacadb0c.jpg)
Adjunto remito mis HU: ![](https://static.platzi.com/media/user_upload/image-da494169-0c99-458e-8b58-2a59fbafa0d4.jpg) ![](https://static.platzi.com/media/user_upload/image-2f14beef-89d5-4bf9-ac54-2241def09f08.jpg) ![](https://static.platzi.com/media/user_upload/image-00c75fa6-f895-4a32-b0f4-99e02aa1ef14.jpg) ![](https://static.platzi.com/media/user_upload/image-d113f6b4-f794-4b17-82b8-81278e866ee8.jpg) ![](https://static.platzi.com/media/user_upload/image-e2c2bde7-9154-49ac-a81d-7c9d6342347b.jpg)
totalmente de acuerdo que sybestimamos la simplifidad y terminando haciendo épicas
User Persona, importantisimo!
![](https://static.platzi.com/media/user_upload/image-3aeb46b3-a39a-4693-8fd7-47f426442245.jpg)
Sebastián Aguinaga: Adjunto mis historias de ![]()u![](https://static.platzi.com/media/user_upload/hu-tarea-d4b25a6e-8999-4f58-b96f-20439bd95902.jpg)suario del caso ![]() Acceso a app por personal de ventas **Quién** Yo como ejecutivo de ventas **Qué** deseo utilizar mi usuario y contraseña **Para qué** Para acceder al aplicativo de aprobación de créditos. **Criterios de aceptación** 1 El usuario debe ser el correo corporativo del agente de ventas de Car for Now 2 La contraseña debe de tener al menos 8 caracteres, 1 letra mayúscula, 1 letra minúscula, 1 número y un signo. 3 El correo del usuario se deberá validar con los servicios de Active Directory para autenticar el acceso de los ejecutivos de ventas. 4 Si el usuario, la contraseña o ambos no corresponden o son inválidos, debe de salir un mensaje de error en rojo indicando la razón por la cuál no se pudo acceder al aplicativo. Digitalización de Documentos **Quién** Yo como ejecutivo de ventas **Qué** deseo utilizar la cámara de la Phablet **Para qué** para digitalizar el INE y extraer los datos del comprador y poder validarlos con el buró de crédito. **Criterios de aceptación** 1 Selector de tipo de documento para determinar cuantos escanéos se debe realizar: INE (2), Pasaporte (1), 2 Escaneo del documento con encuadre automático a través de la cámara de la Phablet 3 Puesta en foco y disparo automático de la cámara dentro de la app. 4 Cuando el escanéo es de INE, repetir la acción para la parte posterior del carné. 5 Devolver a la base de datos un pdf con con reconocimiento de texto (Full Text Search). 6 Envío de imagen en formato pdf a la base de datos para OCR. Validar información de documentos con buró de crédito **Quién** Yo programador **Qué** deseo realizar la extracción de caracteres OCR **Para qué** para extraer los datos del comprador y poder hacer que el sistema los envíe a validar con el buró de crédito. **Criterios de aceptación** 1 Recepción de imágenes en formato pdf con reconocimiento de texto (Full Text Search) 2 Separar los datos a enviar a buró de crédito para consulta de situación crediticia. 3 Conexión API con Buró de crédito. 4 Segmentación de datos a buscar Parámetro – Datos informativos para los siguientes parámetros \- Nombre: \- Apellido: \- NUT: 5 Envío información necesaria para buscar en buró de crédito. 6 Recepción de respuesta de buró de crédito: Positiva: Recibe información de la persona con Nombre, Apellido, NUT similar al enviado y su historial crediticio. Negativa: Error que no se encontró a tal persona. Validación de documentos escaneados **Quién** Yo como ejecutivo de ventas **Qué** deseo escanear mediante la aplicación las huellas de los prospectos **Para qué** para validarlos con las de la identificación. **Criterios de aceptación** 1 Escaneo de las huellas a través de la pantalla del teléfono. 2 Determinación de la nomenclatura de dichas huellas. 3 Comparación de nomenclatura de huellas con la de la documentación presentada. 4 Aceptación o rechazo de las huellas. En caso de rechazo, se debe volver a realizar el proceso de escaneo de huellas. Prueba de vida **Quién** Yo como ejecutivo de ventas **Qué** deseo comparar una foto en tiempo real con la de la identificación del prospecto **Para qué** para validar que la persona está yendo a entregar su documentación voluntariamente. **Criterios de aceptación** 1 Tomar una foto dentro de la app, debe especificarse que la misma debe ser sin lentes y sin gorras o sombreros. 2 Guardar las características principales. 3 Comparar la foto con de la identificación escaneada previamente. 4 Aceptar la comparación. Finalizar proceso de verificación de datos inciales. Negativa la comparación. Volver a tomar la fotografía.
Mis historias de usuario: **<u>HISTORIAS DE USUARIO</u>** 1. **<u>HU</u>** Como usuario de la aplicación Quisiera acceder al aplicativo con mi usuario y contraseña actual Para no tener que manejar diferentes credenciales **<u>AC</u>** * Validar que usuario exista. * Validar que contraseña sea correcta. * Mostrar mensaje de error si hay contraseña y/o usuario incorrecto. 1. **<u>HU</u>** Como usuario de la aplicación Quisiera tener un botón para generar una nueva solicitud Para poder agregar de forma rápida y dinámica nuevas solicitudes. **<u>AC</u>** * Botón en la parte superior del home page. * Botón de acuerdo a la paleta de colores y diseño del home page. 1. **<u>HU</u>** Como usuario de la aplicación Quisiera usar mi propia camara de mi celular Para poder generar la captura de documentos **<u>AC</u>** * El aplicativo tendrá una opción para activar la cámara. * El aplicativo deberá pedir autorización para el acceso a la cámara. * Mostrar opción de aceptar o rechazar imagen. * Mostrar marco guía en color llamativo. * El aplicativo realiza automáticamente la foto sin necesidad de presionar algún botón. 1. **<u>HU</u>** Como usuario de la aplicación Quisiera capturar en una sola imagen el pasaporte Para poder tener la totalidad de datos del cliente **<u>AC</u>** * Capturar Nombre y Apellido * Capturar número de pasaporte. * La captura debe ser una sola imagen. 1. **<u>HU</u>** Como usuario de la aplicación Quisiera mantener la seguridad de las imágenes capturadas Para evitar cualquier uso indebido de los datos del cliente **<u>AC</u>** * No permitir opción de compartir imágenes * No permitir guardar fotos tomadas en galería del celular * No guardar de forma automática ninguna foto * Evitar la captura de pantalla cuando se usa el aplicativo
![](https://static.platzi.com/media/user_upload/image-ae3f1031-3d26-4f11-89d8-07409cb508cd.jpg) Vanessa podrías ayudarme por favor dejándome saber si esta es una buena HU para una de las funcionalidades de *Acceso al Aplicativo Andorid* del caso de estudio. Gracias
Hola Vanessa, en alguno de tus comentarios dices que "Las Historias de usuario son para funcionalidades necesitadas por un usuario. Las especificaciones para procesos internos no es necesario hacerlas en formato de historia, los requisitos técnicos los puedes especificar de otra manera", Quería preguntarte con base en tu experiencia, cuáles son esas otras maneras de especificar las necesidades técnicas y con cuál de esas otras maneras has tenido éxito? Sé que se sale un poco del contexto de este curso, pero no me gustaría quedarme con la curiosidad. De antenamo muchas gracias

Comparto mis apuntes:

¿Por qué fracasan los esfuerzos de implementar Historias de Usuario?

Porque falla la simplicidad
• Tener en claro diferencia entre una épica y una historia de usuario. Una épica es la descripción de todas las funcionalidades que contiene un módulo. Las historias de usuario se deben separar por función específica para que el equipo desarrollador tenga clara la idea particular de la función a desarrollar.

Porque subestimamos la simplicidad
• No subestimar para quién se está trabajando. Utilizar el Buyer persona es una excelente opción. Saber el para qué nos da el contexto para su funcionalidad. Tener siempre en cuenta al usuario al momento de describir la función.

• Porque no solo de historias vive scrum
La agilidad no solo vive de scrum y este no solo vive de HU. Es decir, las historias de usuario no son la única manera de especificar una función. NOTA: En mi experiencia la DGTI abusa de las historias de usuario para la documentación.

En el caso del marco de SCRUM el back log o “pila de producto”, que son todos los elementos que identificamos como elementos de trabajo por hacer, estos pueden componerse de historias de usuario" o de otras formas para “entender” estos elementos.

Entender, dimensionar y contextualizar, esto es importante ya que debemos considerar que un equipo de trabajo se conforma de diferentes disciplinas, por lo que utilizar diferentes formas de exponer las especificaciones ayuda a un mejor entendimiento. Para ello se pueden utilizar, esquemas, diagramas, y otras herramientas de comunicación.

Generación de resultado
Quien El asesor comercial
Que Según la vihabilidad del cliente indicar si es o no vihable
Para que Entrega de definición cliente
Criterios de aceptación
1 Indicar con la palabra NEGADO, si no fue aprobada la solicitud
2 Indicar con la palabra APROBADO, si fue aprobada la solicitud
3 Si fue aprobado, generar automaticamente la tasa de interes y el tiempo de credito según nnivel de vihabilidad.
4 Catalogar tres niveles de bihabilidada
5 “Validar, si en Nivel 1, abrobacion de la taza mas baja y dividir en 72 cuotas el valor
Si en nivel 2, Taza mediana y dividir valor en 60 cuotas
Si es nivel 3, Taza Alta de interes y dividir en 48 cuotas”

Consulta en centrales
Quien El asesor comercial
Que Al dar clic en la opción buscar se conecte automaticamente a las centrales de riesgo y valide la información de estudio de vihabilidad de credito
Para que Validación de la informacion consultada
Criterios de aceptación
1 Hacer un boton de busqueda para hacer la accion de ir a buscar los datos a la central
2 Metodo de conexión con la api de central de riesgo
3 envio de información para estudio de datos
4 recibir los datos que envie la consulta hecha en centrales
5 exponer en un campo alfanumerico la bihabilidad emitida por la central campo de maximo 30 caracteres
6 exponer en otro campo alfanumerico de dos carcteres la categoria recibida de la consulta hecha a la central.

Ingreso de datos del cliente
Quien El asesor comercial
Que Necesita una herramienta ágil para ingresar los datos básicos del cliente, Tipo y número de documento nombres, fecha de nacimiento y fecha de expedición del documento,
Para que Captura de datos
Criterios de aceptación
1 Combo desplegable con tipos de documento estándar
2 Campo alfanumérico para ingreso de datos de número de ID
3 Campo de fecha de nacimiento que exija que mínimo tenga 18 años cumplidos de la fecha actual hacia atrás
4 Cuatro campos Que ajustes siempre en mayúsculas y mínimos requeridos el de primer nombre y primer apellido
5 Campo de fecha de expedición del documento que no permita fechas posteriores a la actual

Estas es unas de mis historisa de Usuario![](https://static.platzi.com/media/user_upload/image-f1d5afe0-dd11-4583-bd5e-9b647af4321c.jpg)

- PORQUE NO SOLO DE HU VIVE SCRUM La agilidad no solo vive de scrum y este no solo vive de HU.

- PORQUE SUBESTIMAMOS LA SIMPLICIDAD DEL PARA QUIEN Y PARA QUE Si no definimos para quien nadie lo va a usar. Si no definimos el para que, si el equipo de desarrollo no sabe el beneficio , no haremos un buen diseño, fallaremos en la funcionalidad

Se fracasa porque subestimamos las H.U, y mo tenemos una idea clara de lo que se quiere

Una HU puede llegar a fracasar cuando no se toma en cuenta las dependencias, pre requisitos, etc, ya que para comenzar una HU se debe contar con todo lo que se necesita para llevar a cabo dicha HU.

HU1
Como Ejecutivo comercial
Quiero Crear solicitudes de creditos
Para poder generar nuevas solicitudes y poder ver el listado de solicitudes generadas.
Criterios de aceptación
1 permitir guardar solicitudes creadas
2 permitir generar identificador unico para cada solicitud
3 permitir ver listado de todas las solicitudes creada por el ejecutivo
4 permitir seleccionar una sola solicitud a la vez
5 permitir ver el estatus de esa solicitud

HU2
Como Ejecutivo comercial
Quiero Capturar los documentos de las solicitudes con la camara
Para poder digitalizar los documentos de los clientes
Criterios de aceptación
1 Permitir marco guia en color amarillo para enfoque.
2 Permitir capturar automaticamente, sin boton.
3 Permitir captura con camara anverso.
4 permitir aceptar/cancelar imagen tomada.
5 permitir elegir el tipo de identificacion a capturar
6 permitir formato jpg
7 permitir formato pdf

HU3
Como Ejecutivo comercial
Quiero Enviar informacion de solicitudes al departamento de ventas.
Para para procesar los creditos mas rapidos.
Criterios de aceptación
1 permitir enviar c/u de las solicitudes registradas al dpto. de ventas
2 permitir notificacion al dpto.ventas
3 permitir el envio de imagenes automaticas al sistema DS-IS
4 Verificar solicitud antes de enviarlas.

HU4
Como Ejecutivo comercial
Quiero Configurar las huellas digitales del cliente
Para poder validarlas con la identificaciones
Criterios de aceptación
1 Permitir configuracion de la huella
2 Debe permitir guardar de 2 a 5 huellas digitales
3 Comparacion de huellas con identificacion existente
4 Recordatorio de configuracion de huella mediante pin de 4 digitos

HU5
Como Ejecutivo comercial
Quiero Instalar la App
Para Poder crear solicitudes de credito
Criterios de aceptación
1 Se podra instalar desde la version 10 en adelante
2 El aplicativo debe estar disponible en la intranet solo para los ejecutivos
3 la app se podra instalar en la Phablet por medio de un archivo APK

mis HU:

HU ACCESO A APLICATIVO ANDROID
QUIEN
Yo como vendedor

QUE
Tengo que iniciar sesión con mis credenciales

PARA QUE
Para acceder a las funcionalidades de la aplicación

Campos Adicionales
Campos obligatorios - nombre usuario y contraseña
Contraseña: Minimo 6 caracteres, incluir una mayuscula y un simbolo

CRITERIOS DE ACEPTACIÓN

Al pulsar “ingresar” se debe verificar que los campos estan completados correctamente
Si la información es correcta, se entra a la aplicación principal
Si un campo no esta bien resaltado, se debe avisar al usuario para que lo corrija

HU EDITAR UNA SOLICITUD EXISTENTE
QUIEN
Como vendedor

QUE
Necesito editar solicitudes previamente creadas

PARA QUE
Para actualizar la información de algún cliente en un determinado momento

Campos Adicionales
Boton de Actualizar al final de la forma

CRITERIOS DE ACEPTACIÓN

Al pulsar el boton de "actualizar, verificamos que los campos esten completos y correctos
Si algún dato es incompleto, se señalará en el formulario
Estando todo correcto, se mostrará mensaje que se actualizo todo correctamente.

HU CREAR UNA NUEVA SOLICITUD
QUIEN
Como vendedor

QUE
Deseo poder crear solicitudes

PARA QUE
Para que mis clientes que desean solicitar crédito sepan
con antelación si pueden o no acceder a uno y cuales
son las condiciones de dicho crédito.
Campos Adicionales
Campos Obligatorios: boton de creación de solicitud nueva
Datos del cliente

CRITERIOS DE ACEPTACIÓN

Al pulsar el boton “crear” verificar que los campos llenados esten correctos
Si la información es correcta se notifica que la operación es un éxito
Si no es correcta la información, destaco los datos incorrectos
Si se creo una solicitud del mismo cliente previamente, se debe avisar al cliente para no duplicar

HU VISUALIZAR LISTA DE SOLICITUDES
QUIEN
Como vendedor

QUE
Deseo visualizar la lista de solicitudes que he creado

PARA QUE
Para acceder a la información de un cliente en caso de que se creo previamente o sino para crearlo

Campos Adicionales
Listar solicitudes con estado y validación
Boton de abrir

CRITERIOS DE ACEPTACIÓN

Mostrar solicitudes previamente creadas en un listado ascendente, mas arriba, mas reciente
Poder acceder a la edición de una solicitud facilmente de una solicitud requerida con boton abrir
Poder borrar alguna solicitud que no se requiera más, mostrando advertencia con confirmación
de eliminación integrada

Resumen de la clase:
CLASE #3. ¿Por qué fracasan los esfuerzos de implementar Historias de Usuario?
• Falla la simplicidad
o Diferencia una épica de una historia de usuario. Las épicas son historias complejas que generalmente describen módulos de usuario. Las historias de usuario son requerimientos más sencillos que describen específicamente lo que el usuario necesita, debe describir algo simple como una sola funcionalidad.
• Subestimación de la simplicidad
o ¿Para quién? La historia debe describir para quién está trabajando.
o ¿Para qué? Se debe conocer claramente el beneficio de lo que estamos haciendo, no dar por sobreentendido que el equipo de desarrollo sabe el para qué está desarrollando algo.
• Porque no solo de historias de usuario vive Scrum.

o El backlog es la pila de producto. Todos los elementos que debemos hacer y están pendientes de realizar. Se compone de elementos de trabajo, entre ellos las historias de usuario, aunque no es lo único. Hay que buscar entenderse, como dimensionamos el trabajo y cuál es el contexto de todas las perspectivas del proyecto. Hay que buscar anexos, esquemas y todo lo que complemente el desarrollo del proyecto. Comprender que nuestra medida de avance es el sw funcionando y no la documentación extensiva, pero si debe documentarse para podernos entender.

yo como ejecutivo de cuentas, quiero poder ingresar a una app desde mi celular, para poder capturar y digitalizar toda la información necesaria para que un consumidor pueda solicitar un crédito
yo como ejecutivo de cuentas, quiero poder ingresar mi usuario y contraseña dentro de la app, para poder ingresar a su respectivo perfil
yo como ejecutivo de cuentas, quiero poder guardar la huella del cliente, para poder comprobar y validar la huella vs la identificación que se presenta
yo como ejecutivo de cuentas, quiero poder generar una nueva solicitud, para poder ingresar cualquier nuevo caso que se presente
yo como ejecutivo de cuentas, quiero poder observar un historial de créditos a probados, para poder llevar una trazabilidad del trabajo

Mis historias:

Historias de Usuario:

1. captura de documentos
Quien: Ejecutivo de ventas
Qué: Almacenar documentacion
Para qué: Posterior evaluacion del cliente
Criterios de aceptacion:
1. El app permitira el uso de la camara para captura de imagen
2. Opcion de tipo de dcumento de identidad a guardar
3. El app permite dos imagenes en el item de documentacion 
4. El app permite registro de pasaporte
5. El app valida las huellas vs las del documeto presentado
6. El app valida prueba de vida mediante video de movimiento de gestos en rostro

2. Envio de informacion:
Quien: ejecutivo de ventas
Que: envia datos recopilados
Para qué: Poserior evaluacion del cliente
Criterios de aceptacion:
1. La app debera mostrar la opcion de envio del paquete de informacion por usuario
toda vez se termine la recoleccion de  datos.
2. Las imagenes son de uso dexclusivo de la app

3. Extraccion de informacion
Quien: Ejecutivo de venta
Que: Validacion de documentaccion ingresada
Para que: filtrado de informacion
Criterios de aceptacion:
1. La app valida que los metadatos tengan relacion
2. La app clasifica las imagennes de la documentacion

4. Gestion
Quien: Ejecutivo de ventas
Que: acciones con solicitudes
Para qué: Dar gestion a las solicitudes de los clients
Criterios de aceptacion:
1. La app permite crear nuevas solicitudes
2. La app permite seleccionar solicitudes existente
3. La app genera un identificador unico para cada seleccion

5. consultas
Quien: Ejectivo de ventas
Que: Consiltar solicitudes
Para qué: Consultar diferentes expedientes 
Criterios de aceptacion:
1. La ap debera permitir la consulta de solicitudes realizadas
2. La app debera permitir consultar docmetos adjuntos a las solicitudes

POR FAVOR UN FEEDBACK PLEASE!!!

(

Estas son mis historias de usuario, me gustaria obtener un feedback

Mis HU:

HU 1: Como ejecutivo de cuenta quiero poder loguearme con mi usuario y contraseña para poder gestionar mi cartera de clientes

Criterios de aceptación:
° Se deberá respetar diferencia entre mayúsculas y minúsculas en la contraseña como en el usuario.
° La contraseña deberá ser alfanumérica, no exceder los 8 caracteres y contener al menos una letra mayúscula.
° El login requiere una conexión estable a internet.

HU2: Como ejecutivo de cuenta quiero crear una nueva solicitud de crédito para poder convertirla en una venta

Criterios de aceptación:
° Se podrán cargar documentos desde la cámara del dispositivo Android y desde la carpeta de archivos.
° Todos los campos son obligatorios
° La información capturada deberá ser convertida a mayúsculas en su totalidad para un mejor manejo de los datos

HU3: Como ejecutivo de cuenta quiero consultar el estatus de una solicitud para poder aprovechar o declinar una oportunidad.

Criterios de aceptación:
° El ejecutivo podrá consultar únicamente las solicitudes registradas por el mismo
° La consulta de estatus estará disponible 5 minutos posteriores a su registro

HU4: Como ejecutivo de cuenta quiero agregar mis huellas digitales para poder loguearme de una manera rápida.

Criterios de aceptación:
° Se podrán registrar un maximo de 4 huellas digitales
° No se podrá registrar mas de 1 vez la misma huella
° Se podrán traer las huellas previamente registradas en el dispositivo Android.

HU5: Como ejecutivo de cuenta quiero subir una prueba de vida para completar una solicitud de crédito.

Criterios de aceptación
° El video únicamente se podrá cargar desde la grabadora de la cámara.
° El video deberá tener luz suficiente para distinguir al prospecto y sus movimientos.

Buenas tardes Comunidad.

Comparto mis HU’s. cualquier tipo de Feedback es bienvenido 😃

USER STORY No1:

Como Ejecutivo Comercial
Quiero ingresar a la APK “Car For Now” a mi Phablet
Para poder capturar y digitalizar todo lo necesario para que los consumidores soliciten un crédito y en pocos minutos saber si son sujetos de crédito o no.

CRITERIOS DE ACEPTACION:
-Dado que mi celular es Android versión 7 Cuando intento descargarla Entonces lo logro con éxito porque funciona para esa versión y posteriores.
-Dado que soy un empleado activo cuando intento ingresar con mi usuario y contraseña del servicio de directorios en operación actual dentro de ABF entonces puedo ingresar a la aplicación con éxito.
-Dado que no soy un empleado activo cuando intento ingresar entonces soy rechazado por estar dado de baja.

DEFINICION DE COMPLETO:

-Pasa las pruebas
-Cumple con los criterios de aceptación.
-Product Owner Acepta la tarea.

USER STORY No2:

Como Ejecutivo Comercial
Quiero que la primera pantalla muestre las solicitudes(identificador interno) que han sido procesadas y el status.
**Para ** visualizar el estatus de su validación.

CRITERIO DE ACEPTACION:
-Dado que quiero ver las solicitudes procesadas cuando ingreso a la aplicacion entonces puedo visualizarlas en forma de lista.
-Dado que la opción que elijo es una solicitud existente cuando ingreso a ella de la lista entonces la app me muestra el status de la solicitud.
Dado que hay una solicitud que no reconozco cuando veo la lista de solicitud existente luego no deberia existir porque unicamente son procesadas por el ejecutivo de cuenta.

DEFINICION DE COMPLETO:

-Pasa las pruebas
-Cumple con los criterios de aceptación.
-Product Owner Acepta la tarea.

USER STORY 3

Como Ejecutivo comercial
Quiero generar una nueva solicitud
Para registrar un nuevo registro de solicitud.

CRITERIOS DE ACEPTACION:
Dado que quiero registrar una solicitud cuando ingreso inmediatamente a la app entonces hay un botón de “Nueva Solicitud” en la pantalla principal.
Dado que es una nueva solicitud cuando acceso a “Nueva Solicitud” entonces se debe generar un identificador único para dicha transacción.
Dado que se genero un identificador único cuando cree una nueva solicitud entonces El aplicativo muestra un mensaje de confirmación del ID asignado.

DEFINICION DE COMPLETO:

-Pasa las pruebas
-Cumple con los criterios de aceptación.
-Product Owner Acepta la tarea.

Estas son mis Historias de usuario para “Car for Now”:

  1. Yo como usuario interno de la empresa quiero poder descargar el aplicativo en mi dispositivo móvil para poder realizar los procesos de solicitud de análisis crediticio para la compra de automóvil
    **Criterios de aceptación: **
  • Se debe poder descargar la aplicación únicamente por el link de la APK
  1. Yo como Ejecutivo Comercial quiero crear una nueva solicitud de análisis de estudio crediticio para un potencial solicitante para así empezar el proceso de solicitud del crédito y hacerle el seguimiento correspondiente a dicho cliente con el fin de convertirlo en un posible negocio o lead.
    **Criterios de aceptación: **
  • Se debe mostrar en la pantalla de inicio un botón para crear la nueva solicitud
  • Cuando una solicitud es creada se debe mostrar una lista de las solicitudes con un identificador único
  1. Yo como Ejecutivo Comercial quiero poner escanear y tomar registro de los documentos del solicitante para poder empezar a realizar el proceso de validación de dichos documentos.

**Criterios de aceptación: **

  • Se debe tener un botón que abra la cámara posterior de la Phablet con el fin de poder capturar los documentos que el potencial cliente facilita.
  • Al abrir la cámara se debe mostrar el encuadre del documento de manera automática
  1. Yo como Ejecutivo Comercial quiero poder seleccionar el tipo de documento de identificación del solicitante para que el proceso sea claro a la hora de validar y hacer su estudio crediticio.
    **Criterios de aceptación:
    **
  • Se debe mostrar un listado mostrando todos los tipos de identificación del solicitante.
  • Se debe poder seleccionar un único tipo de documento de solicitud.
  1. Yo como Ejecutivo Comercial quiero poder visualizar el status de una solicitud realizada para así saber si dicha solicitud esta lista para validación.

_Criterios de aceptación: _

  • Se debe poder seleccionar las solicitudes en curso y ver su status
  • Las solicitudes que esten listas se pueden pasar a validación.

Backlog = Pila de producto

HU 1. Como Usuario vendedor, requiero un módulo de gestión de solicitudes, para lograr iniciar y revisar solicitudes de prospectos.
Criterios:

  • Poder iniciar solicitudes
  • Poder revisar solicitudes
  • Poder identificar automaticamente si el prospecto ya tiene una solicitud abierta a través de su nombre

HU 2. Como usuario vendedor, requiero poder subir los documentos desde mi dispositivo o tomar una foto a los documentos, para lograr subir, guardar y revisar los documentos de los prospectos
Criterios:

  • Poder tomar fotos de los documentos
  • Poder abrir el sistema de archivos del celular y seleccionar el elemento a subir
  • Poder borrar un documento subido y volver a subirlo