8. Estimar historias de usuario

 

Entradas:

Priorizadas por el PO Anderson Alonso en el Product Backlog, con criterios de aceptación claros.

Historia de usuarios definidas

Conocimiento Técnico del Equipo

El conocimiento técnico del equipo es un insumo fundamental para realizar estimaciones realistas y efectivas. Cada miembro del equipo aporta desde su especialidad y experiencia previa, lo que permite tener una visión completa y multifuncional del esfuerzo requerido por cada historia de usuario.

¿Qué incluye este conocimiento?

• Experiencia previa en proyectos similares: Los desarrolladores, testers y diseñadores pueden prever cuánto tiempo y qué recursos se necesitan, basados en tareas anteriores similares.
• Conocimiento de la arquitectura del sistema actual: Esto permite anticipar problemas de integración, dependencias con otros módulos, posibles refactorizaciones o limitaciones tecnológicas.
• Nivel de dominio sobre las herramientas y tecnologías utilizadas: Un equipo familiarizado con las tecnologías requerido podrá estimar con mayor precisión que uno que debe investigar o aprender durante la implementación.

Experiencia Relevante y Aportes 

Se consideró:

• Proyectos anteriores similares.

• Arquitectura planteada basada en microservicios.

• Herramientas conocidas: React, Node.js, MongoDB, AWS, Jenkins.

• Nivel de dominio de frameworks y servicios utilizados.

Plan de liberación

Basado en la estimación de puntos de historia, se estableció un primer Release Plan provisional:
Sprints de 2 semanas.
Capacidad media del equipo: 20 puntos por sprint.
Fecha tentativa de liberación inicial: 3 meses.

Herramientas:

Planning Poker

Es una técnica de estimación colaborativa utilizada en equipos ágiles para asignar esfuerzo o complejidad a historias de usuario. Cada miembro del equipo selecciona de forma individual una carta con un número (usualmente de la secuencia de Fibonacci) que representa su estimación de esfuerzo.

Después de que todos revelan sus cartas al mismo tiempo, se discuten las diferencias más significativas, permitiendo entender las razones detrás de cada estimación. El objetivo es lograr consenso mediante la discusión, generando estimaciones más precisas y compartidas por todo el equipo

Se utilizó Planning Poker para realizar estimaciones colaborativas:

• Cada miembro eligió una carta de la secuencia Fibonacci.

• Se discutieron las diferencias más marcadas hasta lograr consenso.

• Se fomentó el entendimiento común de la complejidad y los riesgos.

Procedimiento General:

1. Presentación de la Historia de Usuario:
   Anderson (PO) explicó la historia, su objetivo, el valor para el negocio y los criterios de aceptación.

2. Primera Votación:
   Cada desarrollador seleccionó su carta en secreto (sin influir en los demás).

3. Revelación de Votaciones:
   Todos mostraron sus cartas al mismo tiempo.

4. Discusión de Diferencias:
   Si había discrepancias importantes (por ejemplo, uno puso 3 y otro puso 8), los desarrolladores discutían sus razones.

5. Nueva Votación:
   Después de discutir, se realizaba otra ronda rápida de votación para llegar a consenso.

6. Registro de Estimación Final:
   Se anotaba el valor acordado en la tabla de backlog.

Ejemplo Detallado de Historias:

HU01: "Como administrador, gestiono usuarios (registro, edición, eliminación)."

• Explicación del PO:
  CRUD de usuarios con validaciones, asignación de roles y control de errores.

• Primera votación:

  • Terry: 8

  • Jheremy: 5

  • Edison: 8

• Discusión:
  Terry y Edison argumentaron que la gestión de permisos y roles implica riesgos de seguridad y pruebas exhaustivas. Jheremy pensaba en un CRUD simple, pero al escuchar a sus compañeros reconoció la complejidad añadida.

• Segunda votación:
  Todos votaron 8.

• Estimación Final:
  8 puntos.

HU02: "Como usuario, accedo al sistema con credenciales válidas."

• Explicación del PO:
  Implementar login con autenticación segura, hashing de contraseñas y manejo de sesiones.

• Primera votación:

  • Terry: 5

  • Jheremy: 3

  • Edison: 5

• Discusión:
  Jheremy consideró que un login básico es sencillo, pero Edison explicó que asegurar el sistema (hashing, tokens, manejo de errores) es crítico.

• Segunda votación:
  Jheremy subió su estimación.

• Estimación Final:
  5 puntos.

Salidas:

Historias de usuario con estimación asignada

ID	Historia de Usuario	Estimación (Puntos)	Justificación
HU01	Como administrador, gestiono usuarios (registro, edición, eliminación).	8	CRUD completo con validaciones, gestión de roles, control de errores.
HU02	Como usuario, accedo al sistema con credenciales válidas.	5	Autenticación segura, uso de hashing, manejo de errores.
HU03	Como usuario, soy desconectado tras inactividad.	3	Middleware o temporizador de sesión, bajo riesgo.
HU04	Como administrador, quiero registrar los datos de mis clientes para mantener un historial organizado.	8	CRUD con validaciones específicas, campos normativos como RUC.
HU05	Como administrador, quiero buscar clientes por RUC, nombre o giro.	5	Búsqueda dinámica con filtros, requiere lógica de backend y diseño de UI.
HU06	Como administrador, registro nuevos productos.	5	CRUD con validaciones de stock, categorías, precios.
HU07	Como administrador, quiero generar proformas para clientes.	3	Selección de productos, cálculo de totales, generación de PDF.
HU08	Como administrador, quiero generar contratos para clientes.	5	Selección de productos, cálculo de totales, generación de PDF.
HU09	Como usuario, convierto proformas en contratos.	5	Conversión de datos, validación de condiciones, almacenamiento.
HU10	Como administrador, quiero visualizar alertas de vencimiento	3	Panel con filtros y colores; requiere lógica condicional.
HU11	Como administrador, quiero recibir recordatorios previos.	3	Envío de notificaciones programadas por correo o sistema.
HU12	Como administrador, quiero generar certificados individuales.	5	Generación automática desde datos cargados; requiere formato exportable.
HU13	Como administrador, quiero imprimir certificados en masa.	3	Descarga en lote con filtros por contrato, sede, etc.