Saltar al contenido principal

Definition of Ready y Definition of Done — Finnova

Este documento define cuándo un Requisito Funcional (RF) está listo para entrar a desarrollo (Ready) y cuándo su implementación se considera terminada (Done). Aplica al desarrollo de RFs que ya cuentan con su documento de especificación en requisitos/ — no a la fase de descubrimiento o división del trabajo, que ocurre antes.

✅ Definición de Ready​

El RF debe:

  • Contar con diagrama de secuencia cuando el flujo involucra más de un componente (API, módulo, base de datos, servicios externos). Si el flujo es trivial (un solo componente, sin interacción externa), es opcional.
  • Estar definida claramente y ser entendida por todo el equipo, contando con los siguientes elementos en su documento:
    • Título
    • Descripción (quién, qué, para qué — formato historia de usuario)
    • Reglas de negocio, numeradas y sin ambigüedad
    • Validaciones de entrada, con su mensaje de error correspondiente
    • Criterios de aceptación (Given-When-Then; ver la Definición de Done más abajo)
    • Notas adicionales (consideraciones, riesgos o decisiones relevantes que no encajan en otra sección)
  • Ser conocido por todos los miembros del equipo que vayan a trabajarlo.
  • Contar con su wireframe o mockup de interfaz, si el RF tiene una pantalla o componente visual asociado.
  • No estar bloqueado por una dependencia o por otro RF que no se haya completado aún (ver tabla "Requisitos relacionados" del documento).

✅ Definición de Done​

Un RF se considerará completo cuando se cumplan todos los siguientes criterios:

Pruebas​

  • Las pruebas deben ser realizadas por un miembro distinto al que desarrolló la funcionalidad y deben arrojar los resultados esperados.
  • Se han ejecutado las pruebas necesarias (unitarias, de integración y de componentes UI) según corresponda, conforme a las Convenciones de Testing.
  • Todos los escenarios de aceptación del RF (Given-When-Then) están cubiertos por al menos una prueba.

Código​

  • El código cumple con las Convenciones de Código del proyecto.
  • Lint y formato pasan sin errores ni warnings (ESLint + Prettier).
  • Se ha realizado una revisión por pares (peer review) por parte de otro miembro del equipo antes de hacer merge. Cualquier observación relevante ha sido atendida.

Documentación​

  • Toda la información técnica y funcional relacionada (código, decisiones de diseño y resultado de las pruebas) ha sido documentada y agregada en la sección correspondiente del RF en la Wiki.
  • Si la implementación final difiere del diseño documentado en Ready (p. ej. el diagrama de secuencia), el documento del RF se actualiza para reflejar la versión real.

Trazabilidad​

  • El RF está correctamente enlazado a su documentación, código fuente y pruebas, manteniendo trazabilidad bidireccional (del RF al código y del código al RF).

Seguridad y validaciones​

Interfaz de usuario​

  • La interfaz relacionada con el RF cumple con los criterios de aceptación establecidos en su documento de Requisitos.

Criterios no funcionales​

  • Se han validado los criterios no funcionales aplicables (rendimiento, seguridad, escalabilidad, entre otros) según lo establecido en el RF y en los Requisitos No Funcionales (RNF) transversales que le correspondan.

Control de configuración​

  • Todos los cambios relevantes (código, configuración, documentación) han sido versionados y almacenados en el repositorio correspondiente, siguiendo el Estándar de ramas (EST01).

Pull Request​

  • El Pull Request incluye descripción del cambio, cómo probarlo y referencia al RF correspondiente, conforme al flujo de PR del proyecto.
  • El CI está en verde (lint + tests + auditoría de seguridad) antes de hacer merge.

📎 Recursos relacionados​