jueves, febrero 22, 2024

De Colección: Ejemplos de Historias de Usuario de la Fuente: Los Libros de Extreme Programming (XP)

Hola a todos,

Como sabemos las historias de usuario nacieron con Extreme Programming (XP) en 1999, para ilustrar el formato libre que estas tienen, quiero compartirles algunas historias de usuario que encontré en libros de la colección de XP:


Fuente:Planning Extreme Programming, Por Kent Beck, Martin Fowler

  • Encuentra la tarifa más baja.
  • Presentar al cliente las diez tarifas más bajas para una ruta en particular.
-
  • Mostrar vuelos disponibles.
  • Muestra posibles vuelos (con conexiones) entre dos planetas cualesquiera.
-
  • Ordene los vuelos disponibles según su conveniencia.
  • Cuando muestres los vuelos, ordénalos por conveniencia: tiempo de viaje, número de cambios, cercanía a la hora de salida y llegada deseada.
-

  • Compra de tiquete
  • Compra de billete con cargo a tarjeta de crédito. Verifique la validez de la tarjeta de crédito al hacer esto. Consulte también las normas generales de inmigración.
-

  • Realizar perfil de cliente.
  • Guarde los datos del cliente para una referencia rápida, por ejemplo, información de la tarjeta de crédito, domicilio, necesidades dietéticas y gravitacionales.
-
  • Revisar itinerarios.
  • Mostrar todos los itinerarios que tiene el cliente en el sistema.
-

  • Cancelar itinerario.
  • Si un cliente cancela un itinerario, cancele todos los vuelos, hoteles, etc.
-

  • Imprimir documentos de inmigración.
  • Imprima la documentación necesaria para salir y llegar a un planeta, solo para los planetas más fáciles.
-

  • Mostrar hoteles.
  • Mostrar hoteles cerca de un lugar.
-

  • Mostrar disponibilidad del hotel.
  • Mostrar hoteles que se encuentran disponibles para el período indicado en el itinerario.
-

  • Ofrecer búsqueda sofisticada de hoteles.
  • Permita al cliente buscar hoteles utilizando más que fechas y ubicaciones. Esto incluiría instalaciones, nivel de servicio, costos y recomendaciones.
-

  • Reserva un hotel.
  • Reservar un hotel. Cargue a la tarjeta de crédito y verifique la validez de la tarjeta de crédito.
-

  • Proporcionar programas de hotel/línea espacial.
  • Mostrar hoteles que tengan acuerdos de venta conjunta con la línea espacial que utiliza el cliente. Muestre los precios, incluidos los descuentos disponibles con estos programas, solo para líneas espaciales que colaboran activamente con nosotros en esta etapa.
-

  • Ofrecer alquiler de aviones.
  • Permitir al cliente alquilar un avión mientras se encuentra en un planeta. Vincula las fechas del vuelo espacial. Mejorar el perfil del cliente para incluir preferencias de avión (selección de seguro, manual versus automático, etc.)


Notas de Jorge Abad

  • No dudo que algunas de las anteriores sean épicas y requieran ser divididas. Con lo anterior, el punto a ilustrar quelos creadores de las historias de usuario usaban/usan un formato libre para ellas. 
  • Además, el formato de historia de Connextra popularizado por Mike Cohn (ver más acá - La historia de las historias de usuario, por Lucho Salazar)
    • Yo como    (rol)    
    • Quiero   funcionalidad   
    • Para   beneficio de negocio    
    • + Criterios de Aceptación, 
es valiosísimo, pero las historias de usuario no tienen por obligación que escribirse de una forma u otra, debe encontrarse el mejor esquema que sirva para la organización y su contexto.


Fuente: Extreme Programming Installed  Ron Jeffries, Ann Anderson, Chet Hendrickson


  • Las cuotas sindicales varían según el sindicato y se cobran únicamente en el primer período de pago del mes. El sistema calcula la deducción automáticamente. El importe se muestra en la tabla adjunta.

  • Cuando una transacción causa que la cuenta de un cliente entre en sobregiro, transfiera dinero desde la cuenta de protección contra sobregiros, si corresponde.
  • Cuando una transacción hace que la cuenta de un cliente entre en sobregiro, envíe un correo electrónico mostrando la transacción y el saldo al cliente. Si la protección contra sobregiros está vigente, muestre la transacción de sobregiro y los saldos de cuenta resultantes en el correo electrónico.

  • Para cada cuenta, calcule el saldo sumando todos los depósitos y restando todas las deducciones.

  • Produzca un estado de cuenta para cada cuenta, que muestre la fecha de la transacción, el número, el beneficiario y el monto. Se adjunta una declaración de muestra: haga que el informe se parezca aproximadamente a la muestra.
----
  • Cuando el GPS tiene contacto con dos o menos satélites durante más de 60 segundos, debe mostrar el mensaje "Pobre contacto de satélite", y esperar la confirmación del usuario. Si el contacto mejora antes de la confirmación, borre el mensaje automáticamente.
  • Si la estación que se reproduce actualmente contiene información digital, la información se muestra en la pantalla LCD de la radio. Si no hay información digital disponible, muestre la frecuencia de la estación.
  • Permitir al usuario agregar nuevos tipos de servicios a la lista inicial del sistema. Por ejemplo, es posible que desee agregar una entrada especial para lavar el automóvil en el lavado "gratuito" de la escuela secundaria. Incluya el monto y la fecha de los campos estándar, además permita al usuario agregar texto adicional o campos numéricos. Los informes deben sumar automáticamente los campos numéricos. (Nota del programador: es necesario dividir la historia. Separe los campos numéricos y de texto en dos historias, más una para la suma).
    • (Partición 1) Permita que el usuario agregue nuevos tipos de servicios, incluidos los campos estándar más cualquier campo de texto adicional que desee.
    • (Partición 2) Permitir al usuario agregar campos numéricos a los tipos de servicios definidos por el usuario.
    • (Partición 3) En todos los informes, muestre los totales de todos los campos numéricos, no solo los campos estándar de galones y cantidades en dólares.


Fuente: La Programación Extrema en la Práctica. James Newkirk, Robert C. Martin

  • La cabecera del sitio (esto es, en todas las páginas) deberá indicar si el usuario no ha entrado y ofrecerle un botón para entrar (similar a un carro de compras). Muestra el nombre o el e-mail si pulsa.
  • Cuando se dispara la entrada, y el sitio no puede detectar que el usuario es un miembro, el usuario es transferido a una página de entrada, y le pide su nombre de usuario y la contraseña y explica la filosofía y proceso de entrada del sítío.
  • La página de entrada debería al usuario permitirle saltarse el login y entrar como invitado.
  • Cuando el usuarío seleccione registrar, cargará la página de registro, solicitándole la dirección e-mail, nombre, apellido, afiliación y si desea o no ser informado sobre las novedades del sitio. Una vez enviado, el sistema genera una contraseña y la envía por e-mail al usuario. El campo e-mail no puede quedar en blanco.
  • Proporcionar una utilidad que permita a los usuarios invitar a otras personas a hacerse miembros (enviándoles un formulario HTML). Una vez que se reciba la contestación el sistema los registrará y les enviará un e-mail de confirmación con su contraseña.
  • Los usuarios usuarios deben ser capaces de cambiar su perfil (dirección de e-mail, contraseña, nombre, apellido, afiliación). Poner dos campos de contraseña para pedir confirmación.

  • Listado de historias de usuario para el proceso de estimación   (Nota Jorge Abad: Aunque no está el detalle de cada una, es interesante observar la granuralidad de las mismas) 
    • Historia de Usuario 4.1. Disparar el Mecanismo de Entrada
    • Historia de Usuario 4.2. No Desplegar Ventanas
    • Historia de Usuario 4.3. Dirección de E-mail como Nombre de Usuario
    • Historia de Usuario 4.4. Restricción de Portabilidad
    • Historia de Usuario 4.5. Cabecera Elegante del Sitio
    • Historia de Usuario 4.6. Historia de Entrar
    • Historia de Usuario 4.7. Cookies (Nota Jorge Abad: Esta historia es entre funcional y técnica) 
    • Historia de Usuario 4.8. Entrar como Invitado
    • Historia de Usuario 4.9. Entrada Transparente
    • Historia de Usuario 4.10. Registrar Usuario
    • Historia de Usuario 4.11. Miembro
    • Historia de Usuario 4.12. Contraseña Olvidada
    • Historia de Usuario 4.13. Migrar Datos de Access (Nota Jorge Abad: Esta historia es netamente técnica, por definción no debería ser una historia de usuario, pero indiscutiblemente es trabajo a realizar)
    • Historia de Usuario 4.14. Direcciones de E-mail Heredadas
    • Historia de Usuario 4.15. Notificación vía E-mail
    • Historia de Usuario 4.16. Especialización de la Notificación
    • Historia de Usuario 4.17. Anchura de la Página
    • Historia de Usuario 4.18. Invitación de los Miembros
    • Historia de Usuario 4.19. Cambiar el Perfil de Usuario


Recomiendo usar la siguiente definición de historia de usuario: (clic aquí) https://www.lecciones-aprendidas.info/2024/02/una-buena-definicion-de-historia-de-usuario.html

miércoles, febrero 21, 2024

De Colección: Una buena definición de Historia de Usuario

 Una buena definición de historia de usuario que me ha sido útil compartir es:


"Una Historia de usuario es una pequeña porción de valor cuyo tiempo de análisis, desarrollo, pruebas, corrección y despliegue, puede estar entre unas cuantas horas hasta máximo 36 aproximadamente."*


Otra definición que también pueden funcionar es:


"Una Historia de usuario es una pequeña porción funcional de valor cuyo tiempo de análisis, desarrollo, pruebas, corrección y despliegue; puede estar entre unas cuantas horas hasta máximo 36 aproximadamente, que le permite al equipo de desarrollo de forma tangible y rápida mostrar progreso al negocio"

*Nota: antes usaba la expresión de días pero generaba confusión, y se terminaba creyendo que eran muchas personas trabando durante esos días, por eso preferí poner el tiempo total requerido.

sábado, febrero 10, 2024

El email de Jeff Bezos - que dió origen a la nube, a la apificación y a los microservicios - El correo electrónico que cambió la historia de la tecnología

 Dejo este post como como referencia inicial, prometo escribir sobre este en el futuro

--

En 2002, según la leyenda tecnológica, el fundador de Amazon, Jeff Bezos, emitió un mandato. Este mandato, también conocido como “Mandato API de Bezos” o “Mandato API de Amazon”, serviría para formar la columna vertebral de Amazon en el espacio web moderno, informando tanto el paradigma de desarrollo de API en la mentalidad corporativa como un enfoque general mejorado para la externalización, fue un mail que en su momento envió a sus 150 empleados en Amazon

--

  1. De ahora en adelante, todos los equipos expondrán sus datos y funcionalidades a través de interfaces de servicio.
  2. Los equipos deben comunicarse entre sí a través de estas interfaces.\
  3. No se permitirá ninguna otra forma de comunicación entre procesos: ni enlaces directos, ni lecturas directas del almacén de datos de otro equipo, ni modelo de memoria compartida, ni puertas traseras de ningún tipo. La única comunicación permitida es a través de llamadas de interfaz de servicio a través de la red.\
  4. No importa qué tecnología utilicen. HTTP, Corba, Pubsub, protocolos personalizados, no importa. A Bezos no le importa.
  5. Todas las interfaces de servicio, sin excepción, deben diseñarse desde cero para que sean externalizables. Es decir, el equipo debe planificar y diseñar para poder exponer la interfaz a desarrolladores en el mundo exterior. Sin excepciones.\
  6. Quien no haga esto será despedido.\
  7. Gracias; ¡que tenga un lindo día!

---
El original en inglés

  1. All teams will henceforth expose their data and functionality through service interfaces.\
  2. Teams must communicate with each other through these interfaces.\
  3. There will be no other form of interprocess communication allowed: no direct linking, no direct reads of another team’s data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network.\
  4. It doesn’t matter what technology they use. HTTP, Corba, Pubsub, custom protocols — doesn’t matter. Bezos doesn’t care.\
  5. All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions.\
  6. Anyone who doesn’t do this will be fired.\
  7. Thank you; have a nice day!