Saltar al contenido principal

Manejo de Defectos y Nuevos Requerimientos en Brace

Este documento establece el proceso formal para el manejo de defectos y la gestión de nuevos requerimientos dentro del ciclo de desarrollo de Brace. Su objetivo es garantizar trazabilidad, respuesta oportuna y control de calidad tanto sobre errores detectados como sobre solicitudes de mejora o nuevas funcionalidades, provenientes del equipo interno o de los clientes.

1. Registro de Defectos y Nuevos Requerimientos​

1.1 Generación de tickets:

  • Todo nuevo requerimiento funcional o corrección debe estar respaldado por un ticket en el sistema.
  • Estos tickets pueden clasificarse como User Story (US) o como Defecto. 1.2 Trazabilidad obligatoria:
  • Cada trabajo realizado debe tener un ticket específico.
  • Si se trabaja sobre una US sin un ticket independiente, se corre el riesgo de perder trazabilidad, pruebas y validación, lo que puede derivar en errores o entregas incorrectas.
  • El desarrollador y el PO son responsables de garantizar este proceso. 1.3 Excepciones:
  • Requerimientos pequeños o ajustes que sustituyan otros ya documentados pueden ser tratados como parte del ticket original, siempre que se documente claramente el cambio.

2. Creación de Defectos desde el Cliente​

2.1 Flujo de reporte:

  • Se debe establecer un mecanismo para que los clientes reporten directamente defectos encontrados en la plataforma.
  • Estos reportes deben registrarse automáticamente en el backlog y ser revisados por el PO. 2.2 Clasificación y conversación:
  • El PO revisará y priorizará junto con el cliente cada defecto reportado.
  • Este flujo permite ahorrar tiempo en la generación de tickets y mantener una relación colaborativa con el cliente.

3. Niveles de Urgencia para Defectos​

Los defectos se clasificarán en tres niveles de urgencia, lo cual facilitará su priorización y tratamiento dentro del equipo. 3.1 Urgente:

  • Debe ser abordado de inmediato.
  • Aplica si:
    • Afecta directamente las operaciones del cliente.
    • Impide recibir pagos o realizar entregas clave.
  • El defecto debe incluirse en el sprint actual y desplazar otra historia si es necesario.
    • La historia desplazada no se contará como rollover si fue debido a este caso crítico. 3.2 Prioritario:
  • No requiere atención inmediata, pero debe planearse en los próximos sprints.
  • Ejemplo: un campo no se guarda correctamente en el perfil de usuario. 3.3 Bajo:
  • Son errores de bajo impacto, visuales o de comportamiento menor que deben ser corregidos pero no afectan directamente la operación.

4. Asociación y Análisis de Defectos​

4.1 Relación con el desarrollo original:

  • Todo ticket de defecto debe estar relacionado con el ticket de la historia o tarea de desarrollo que falló.
  • Esto permite identificar la raíz del error y mejorar el proceso. 4.2 Métricas de calidad:
  • La relación entre defectos y tickets originales permite calcular:
    • Número de defectos por historia.
    • Número de defectos por persona.
    • Tiempos de respuesta por nivel de urgencia. 4.3 Evaluación del impacto:
  • Se puede medir el impacto de los errores en los proyectos.
  • Esta información alimenta las métricas generales de calidad y sirve para identificar oportunidades de mejora en desarrollo, pruebas y revisión.

Este proceso de manejo de defectos busca mantener un alto estándar de calidad, una trazabilidad clara y una respuesta efectiva ante problemas, promoviendo la mejora continua en todos los niveles del desarrollo de productos en Brace.