CHK-BDT-012 Verificación de Reporte de Estado

v 1.0

Propósito

Este checklist de Verificación de Reporte de Estado proporciona una guía estructurada para revisar y asegurar la calidad y completitud de los reportes de estado del proyecto. Su objetivo es ayudar a los equipos a identificar y corregir errores comunes, garantizar la coherencia de la información y presentar datos de manera clara y profesional.

Notas introductorias

Este checklist debe ser utilizado por todo el equipo antes de la presentación del reporte de estado para asegurar que todos los aspectos clave se han cubierto y revisado. La revisión debe de ser manual por parte de dos miembros del equipo. Cualquier corrección o mejora identificada durante la revisión debe ser implementada antes de la aprobación final del reporte.

Involucrados

• Los responsables de presentar el reporte de estado.
• Los responsables de desarrollar el contenido del reporte de estado.
• Los responsables de realizar la verificación del reporte de estado.

Criterios de Aceptación

General:

1. Ortografía y Gramática
• No existen errores de ortografía y gramática.
2. Claridad y Concisión del Lenguaje Escrito
• No existen muletillas ni redundancias en el guión del presentandaro (en caso de que haya un guión).
• El lenguaje es claro y profesional.
• El lenguaje es comprensible para todos los stakeholders.

Preguntas Específicas:

1. ¿Dónde estoy?
• Se muestra el CPI y SPI actualizados de iteración y de proyecto.
• Se observa la tendencia del SPI y CPI respecto al reporte de estado anterior.
• Se muestra la tendencia del SPI y CPI respecto al objetivo.
• Se muestra con imágenes en donde se encuentra el proyecto respecto al objetivo.
2. ¿Dónde debería estar?
• Se muestra el total de ítems terminados respecto a los planeados.
• Se muestra el total de horas trabajadas respecto a las planeadas.
• Se muestra el roadmap indicando claramente en qué fase se encuentra el proyecto, la fase siguiente y cuándo se espera cumplir.
3. ¿Cuánto me ha costado?
• Distribución de horas en las fases o áreas del proyecto.
• Se muestra la cantidad de horas invertidas respecto a la iteración o el reporte de estado anterior.
• Se indica cuánto ha trabajado en promedio cada integrante del equipo (horas/día).
• Se compara el valor anterior con el presupuesto planeado de la iteración.
4. ¿Por qué estoy donde estoy?
• Se incluye el diagrama de ishikawa de los tres proyectos.
• La causa raíz es solo una práctica del CMMI.
• Las causas están mapeadas a prácticas correctas.
5. ¿Cómo está la calidad?
• Se muestra y explica de manera clara el yield de defectos de los proyectos.
• Se muestra la cantidad de defectos y sus categorías respecto al reporte o iteración pasado.
• Se muestra la tendencia de los riesgos usando el burndown chart.
• Los riesgos están ordenados correctamente según su clasificación.
• Se muestran los problemas existentes con su plan de resolución.
• Se muestra la tendencia de los patrones.
• Se muestra la tendencia de los anti patrones.
6. ¿Cómo puedo mejorar?
• Existe una propuesta de mejora para cada una de las causas raíz del diagrama de Ishikawa.
• Las propuestas de mejora tienen forma de evaluarse.
• Se establece a qué principio de mejora continua pertenece cada una de las propuestas.

Gráficas y Visualizaciones:

1. Etiquetas y Legibilidad
• Todas las gráficas tienen etiquetas en los ejes y títulos claros.
• Las leyendas de las gráficas son claras y comprensibles.
2. Actualización
• Todas las gráficas están actualizadas con los datos más recientes.
• Los datos representados son precisos y están completos.
3. Orden y Estructura
• Las gráficas están ordenadas de manera lógica y coherente según la narrativa del reporte.
• La información de cada gráfica es presentada en el orden correcto.

Revisión Final:

• El reporte de estado fue ensayado en frente del equipo y este mismo dio su aprobación.
• El ensayo del reporte de estado dura 40 minutos o menos.
• En caso de que hubiera, se llevaron a cabo las correcciones y se vuelve a validar el contenido.

Control de Cambios

Versión	Cambio realizado	Análisis	Autor	Revisor(es)	Fecha de Cambio
v 1.0	Creación del checklist	Primera versión de la checklist usado para el un experimento	Sebastian Flores	Diego Perdomo	31/05/2024