Procedimiento Integral de Trabajo
Marco Agile + BDD + UAT#
Versión: 1.0
Propósito: Establecer un procedimiento claro, estandarizado y auditable para la gestión, desarrollo, validación y aceptación de iniciativas digitales bajo un enfoque Agile, integrando BDD y UAT de forma continua.1. Objetivo del procedimiento#
Definir qué es cada elemento, cómo opera y quién es responsable dentro del flujo Agile + BDD + UAT, con el fin de:Alinear negocio, sistemas y tecnología.
Reducir riesgos de interpretación y retrabajo.
Garantizar entregables con valor validado.
Facilitar la toma de decisiones en comités.
Establecer un lenguaje común para PM, desarrolladores, QA y UAT.
2. Alcance#
Este procedimiento aplica a:Usuarios Aceptadores (UAT / UA)
Comité de Sistemas / Comité Ejecutivo de TI
Mejora de procesos digitales
3. Definiciones clave#
3.1 Agile#
Qué es: Un marco de trabajo iterativo e incremental que prioriza la entrega continua de valor, la adaptación al cambio y la colaboración constante con el negocio.El trabajo se divide en ciclos cortos (sprints).
Se entrega funcionalidad usable en cada ciclo.
Se aprende y ajusta continuamente.
PM / Scrum Master: facilitar el proceso.
Product Owner: priorizar valor.
Equipo de desarrollo: construir el incremento.
3.2 Historia de Usuario#
Qué es: Una descripción breve de una necesidad desde el punto de vista del usuario, enfocada en el valor que se desea obtener.Como [tipo de usuario] quiero [funcionalidad] para [beneficio]Representa la unidad mínima de valor.
Se prioriza en el backlog.
Se desarrolla y valida dentro de un sprint.
Negocio / Usuario clave: define la necesidad.
Product Owner: valida claridad y prioridad.
3.3 BDD (Behavior-Driven Development)#
Qué es: Una práctica que define el desarrollo a partir del comportamiento esperado del sistema, descrito en lenguaje claro y verificable.Antes de desarrollar, se acuerdan escenarios de comportamiento.
Los escenarios guían el desarrollo y las pruebas.
El comportamiento esperado se convierte en criterio de aceptación.
Negocio / UAT: define expectativas.
QA: estructura escenarios.
Desarrollo: implementa el comportamiento.
3.4 Escenarios Gherkin#
Qué son: Escenarios escritos en lenguaje estructurado que describen condiciones, acciones y resultados esperados.Entonces: resultado esperado.
Funcionan como contrato funcional.
Se usan para validar desarrollo y aceptación.
QA: redacción técnica-funcional.
Negocio / UAT: validación del escenario.
3.5 Sprint#
Qué es: Un ciclo corto de trabajo donde se construye un incremento funcional.Desarrollo guiado por historias y escenarios.
PM / Scrum Master: facilita el sprint.
3.6 UAT (User Acceptance Testing)#
Qué es: La validación del negocio para confirmar que la funcionalidad cumple lo esperado.Se ejecuta de forma incremental.
Se realiza contra escenarios BDD.
Usuarios aceptadores (UA).
3.7 Definition of Done (DoD)#
Qué es: Un conjunto de criterios obligatorios que determinan cuándo una historia o incremento está realmente terminado.Cómo opera: Un entregable está “Done” solo si:Cumple criterios de aceptación.
No tiene defectos críticos.
Aprobación final del Product Owner.
4. Flujo operativo del procedimiento#
Paso 1. Identificación de necesidad#
Origen: negocio, operación, comité, regulación.
Se documenta el objetivo.
Paso 2. Creación de historias de usuario#
Se traduce la necesidad en historias.
Se valida claridad y valor.
Paso 3. Definición de escenarios BDD#
Se redactan escenarios Gherkin.
Se validan con negocio y UAT.
Paso 4. Planeación de sprint#
Se seleccionan historias.
Se verifica que estén listas para desarrollo.
Paso 5. Desarrollo y pruebas#
Desarrollo guiado por escenarios.
Paso 6. UAT incremental#
El usuario valida contra escenarios.
Se acepta o se generan ajustes.
Paso 7. Aceptación (DoD)#
Se confirma cumplimiento total.
Se declara la historia como Done.
Paso 8. Release / Piloto#
Responsables: Sistemas + Operación.5. Matriz de responsabilidades (RACI simplificada)#
R – Responsible (Responsable) Ejecuta la actividad. Hace el trabajo.#
A – Accountable (Aprobador / Dueño) Tiene la responsabilidad final. Toma la decisión y responde por el resultado. Debe haber solo uno.#
C – Consulted (Consultado) Aporta opinión o conocimiento antes de ejecutar.#
| Actividad | Negocio | PO | PM | Dev | QA | UAT | Comité |
|---|
| Definir necesidad | R | A | I | I | I | I | C |
| Historia de usuario | C | R | I | I | I | I | I |
| Escenarios BDD | C | A | I | C | R | C | I |
| Desarrollo | I | I | A | R | C | I | I |
| UAT | C | A | I | I | C | R | I |
| Aceptación final | I | R | I | I | I | C | I |
6. Principios rectores#
La aceptación del usuario es continua.
Nada está terminado sin validación.
El comportamiento esperado se define antes de desarrollar.
La calidad es responsabilidad de todos.
7. Mensaje clave del procedimiento#
Lo que se construye es lo que el negocio necesita.
El riesgo se controla desde el inicio.
La toma de decisiones es informada y transparente.
Modificado en 2026-01-23 04:27:56
