Subdirección de las Tecnologías de la Información y Comunicaciones

Área de Gobernanza y Calidad

Contenido

Resumen

Versión: v01r01
Fecha publicación: 30 de julio de 2021

Histórico de cambios

Los cambios en la documentación de apoyo vendrán acompañados de un registro de las modificaciones. De este modo se podrá realizar un seguimiento y consultar su evolución.

Versión	v01r01	Fecha publicación	30 de julio de 2021
Alcance
En esta página se hace una enumeración de las entrevistas más comunes en el plan de lanzamiento de un nuevo proyecto ágil: acuerdos internos, entrevistas con la OCA, con Arquitectura, con la OTI

Introducción

Esta página recoge un resumen del proceso de entrevistas y acuerdos más comunes dentro del Plan de lanzamiento en proyectos ágiles:

Entrevista a Proxy Product Owner (Jefe de Proyecto), Scrum Masters y Personal Funcional.
Entrevistas y acuerdos con la Oficina de Arquitectura de la STIC.
Entrevistas y acuerdos Oficina de Calidad (OCA) de la STIC.
Entrevistas y acuerdos Oficina Técnica Interoperabilidad (OTI) de la STIC.
Entrevistas y acuerdos con otros Stakeholders: Oficina de seguridad de la STIC, oficina de BI de la STIC, oficina de sistemas de la STIC,...

Para cada proyecto debe hacerse una valoración previa de qué entrevistas van a ser realmente útiles para el mismo. El sprint 0 suele estar cargado de reuniones y no tiene sentido convocar aún más si no se ven necesarias. Por ejemplo, alguna entrevista podría sustituirse por un correo en el que simplemente se informe al stakeholder correspondiente de que el desarrollo del proyecto va a iniciarse, para que esté al tanto. De cualquier manera, en caso de duda se recomienda mantener la sesión.

Entrevista preliminar del equipo

Asistentes

Agile Coach - Obligatorio
Proxy Product Owner (Jefe de Proyecto) - Obligatorio
Scrum Master - Obligatorio
Desarrolladores - Recomendado
Product Owner (Personal Funcional) - Recomendado

Agenda

Puede tomar forma de sesión o conversación en la que se traten entre el Proxy Product Owner (Jefe de Proyecto), el Scrum Master y el Product Owner (Personal Funcional) de manera preliminar y a expensas del feedback del resto del equipo los siguientes puntos:

ACUERDO

RESULTADO

INFORMACIÓN ADICIONAL

Introducción a la sesión

Todos los asistentes tiene claro el objetivo de la reunión.

Herramientas de comunicación

Escrita

Correo, Teams, Circuit, Simil,...

Videoconferencia

Teams, Circuit,...

Herramientas STIC

Confluence, ...

Incluir enlaces a Confluence

Jira, ...

Incluir enlaces a pizarra SCRUM para el equipo y a pizarra de Mejoras/Wishlist para el Personal Funcional

Fecha Resumen Transformación Ágil

Incluir fecha

Incluir si existe algún riesgo que comprometa dicha fecha

Fecha Inicio del sprint 1

Incluir fecha

Incluir si existe algún riesgo que comprometa dicha fecha

Eventos

SPRINT.

Cada sprint tendrá una duración de X semanas.
El primer sprint empezará un X día de la semana, intentando unificar los de fin/inicio de sprint durante la misma jornada.

DAILY MEETING.

Se realizará todos los días del sprint con la única excepción del día que se celebran Sprint Review/Sprint Retrospective/Sprint Planning de forma continuada.
Horario: X h
Lugar: X (p.ej. Físico y/o video conferencia)
Time-box: 15 minutos
Asistentes: Development Team (obligatorio) + Scrum Master (opcional) + Agile Coach STIC (opcional) + Proxy Product Owner (opcional).
DevTeam + Scrum Master se reunirán físicamente en del proveedor (si es posible) y el Agile Coach STIC asistirá por videollamada
El equipo tendrá la pizarra visible en todo momento.

SPRINT PLANNING.

Marca el comienzo del sprint.
Se celebrará siempre un X día de la semana, de forma periódica, una vez al comienzo de cada Sprint.
Horario: X horas
Lugar: X (p.ej. STIC + enlace videoconferencia)
Time-box: X hora (referencia: 2 horas para Sprint de 3 semanas)
Asistentes: Scrum Team al completo + referente OCA STIC (a confirmar con OCA). Resto de participantes opcionales.
Se podrá trabajar únicamente con las Historias de Usuario que cumplan el DoR.

SPRINT REFINEMENT.

Se proponen X refinamientos por sprint, una sesión por semana, teniendo estas lugar los X días de la semana.
Horario: X horas.
Lugar: X (p.ej. Oficinas proveedor + enlace videoconferencia)
Time-box: X hora (referencia: 2 horas/semana para Sprint de 3 semanas)
Asistentes: Development Team + Scrum Master + Product Owner + Proxy PO + OCA + OTI + ARQ.
Se realiza la estimación de las Historias de Usuario en Story Points.

SPRINT RETROSPECTIVE.

Marca el final del sprint.
Se celebrará siempre un X día de la semana, de forma periódica, una vez al final de cada Sprint.
Horario: X horas.
Lugar: X (p.ej. STIC + enlace videoconferencia)
Time-box: X hora (referencia: 1 hora para Sprint de 3 semanas)
Asistentes: Development Team + Scrum Master + referente OCA (a confirmar con OCA).

SPRINT REVIEW.

Se celebrará siempre un X día de la semana, de forma periódica, una vez al final de cada Sprint.
Horario: X horas
Lugar: X (p.ej. STIC + enlace videoconferencia)
Time-box: X hora (referencia: 2 horas para Sprint de 3 semanas)
Asistentes: Scrum Team al completo + referente OCA (a confirmar con OCA) + stakeholders opcionales.
Las Historias de Usuario deben cumplir el DoD.

GENERACIÓN DE VERSIONES.

La generación de versiones, y su consecuente despliegue en producción, deberá intentar mantenerse en periodos de tiempo recurrentes y estables de X meses.
La generación de cada versión tendrá lugar siempre un X día de la semana a las X horas, debiendo informar con suficiente tiempo de antelación a X persona/departamento en caso de necesidad urgente de posponerlo.
La siguiente versión estará disponible el X día de la semana a las X horas.
Se considerará dentro de una versión, en el momento de su generación, toda Historia de Usuario que cumpla X requisitos.

PLANIFICACIÓN DE VERSIONES.

Se celebrará siempre un X día de la semana, de forma periódica, una vez al comienzo de cada Sprint.
Horario: X horas
Lugar: X (p.ej. STIC + enlace videoconferencia)
Time-box: X hora (referencia: 1 hora para Sprint de 3 semanas)
Asistentes: Product Owner + Proxy Product Owner.
Para la sesión el personal funcional se debe tener en mente una actualización de la visión del negocio así como la foto de versiones actualmente en desarrollo.

GESTIÓN NECESIDADES DEL NEGOCIO.

Se celebrará siempre un X día de la semana, de forma periódica, una vez al final de cada Sprint.
Horario: X horas
Lugar: X (p.ej. STIC + enlace videoconferencia)
Time-box: X hora (referencia: 2 horas para Sprint de 3 semanas)
Asistentes: Scrum Team al completo.
Para la sesión el personal funcional debe preparar una agenda con expectativas y decisiones a tomar.

CONCEPTUALIZACIÓN DE MEJORAS.

Se celebrará siempre una sesión independiente por cada mejora Ad-Hoc, conforme se identifiquen nuevas mejoras, priorizando los X día de la semana.
Horario: X horas
Lugar: X (p.ej. STIC + enlace videoconferencia)
Time-box: X hora (referencia: 1,5 horas por cada mejora)
Asistentes: Scrum Team al completo + referente OCA (a confirmar con OCA) + stakeholders opcionales.
Para la sesión el personal funcional debe definir previamente una descripción de alto nivel de la Mejora.

Se especifica día, hora, lugar, asistentes y time-box de todas las sesiones.

Métricas del proyecto

Pack de métricas a recopilar durante cada Sprint por el Scrum Master y mostrar al equipo al principio de cada Sprint Retrospective.

Métricas desarrollo

Duración

El tiempo de referencia para esta sesión son 2 horas.

Entrevista y acuerdos con la Oficina de Arquitectura de la STIC

Asistentes

Agile Coach - Obligatorio
Proxy Product Owner (Jefe de Proyecto) - Obligatorio
Representante Oficina de Arquitectura - Obligatorio
Scrum Master - Obligatorio
Arquitecto software (proveedor) - Obligatorio
Desarrolladores - Recomendado

Agenda

AGENDA	INFORMACIÓN ADICIONAL	NOTAS DE LA SESIÓN
Introducción a la sesión	Todos los asistentes deben tener claro el objetivo de la reunión.
Revisión Requisitos No Funcionales y otra normativa aplicable	Preparación por parte de equipo de arquitectura.
Revisión acuerdos generales	Tras la sesión de alineamiento interna, el Scrum Master mostraría los acuerdos generales.
Planificación de Taller de normativa Gitflow en el SAS, atendiendo a las particularidades de gestión del código para proyectos ágiles.	Preparación por parte de equipo de arquitectura.

Duración

El tiempo de referencia para esta sesión es 1 hora.

Entrevista y acuerdos con la Oficina de Calidad de la STIC

Asistentes

Agile Coach - Obligatorio
Proxy Product Owner (Jefe de Proyecto) - Obligatorio
Representante Oficina de Calidad - Obligatorio
Scrum Master - Obligatorio
Desarrolladores - Obligatorio
Product Owner (Personal Funcional) - Opcional

Agenda

AGENDA

INFORMACIÓN ADICIONAL

NOTAS DE LA SESIÓN

Introducción a la sesión

Todos los asistentes deben tener claro el objetivo de la reunión.

Revisión acuerdos generales

Revisión DoD y DoR

Se utilizará como punto de partida el DoR/ DoD estándar de la STIC.

Alinear actividades de la OCA en el proyecto

Se utilizará como punto de partida la descripción de las actividades de la OCA incluida en Responsabilidades en proyectos ágiles

Revisión de Requisitos No Funcionales y otra normativa aplicable (si aplica)

Preparación por parte de equipo de calidad.

Revisión de flujo de tareas durante un Sprint

Pasos de un flujo estándar:

Día 1 y 2 del sprint: Los desarrolladores se encargarán de crear todas las ramas de mejoras del sprint y subirlas al GIT del SAS. También se encargará de la creación de las ramas de todas las historias de usuario. Como apunte adicional, cuando se coja alguna historia del Backlog, la primera tarea será la creación de las ramas y subida al SAS
Día 7 del sprint: Los desarrolladores revisarán todos los features del sprint en curso internamente
Día 7 del sprint: se notificará a la OCA del primer pack de historias de usuario finalizadas y subidas a GIT para revisar Sonar (si no hay nada subido, se avisará que no hay nada aún y se notificará la subida en los días posteriores).
Día 8 del sprint: se enviará a la OCA el pack con todos los features del sprint para que pueda realizar la primera revisión
Día 10 del sprint: segunda notificación a la OCA de subida de historias de usuario finalizadas a GIT y Sonar.
Día 11 del sprint: Los desarrolladores recibirán el feedback de la OCA sobre los features.
Día 13 del sprint: se realizará la segunda entrega de los features tras la primera revisión de la OCA, así como del fichero con las pruebas automáticas ejecutadas y el resultado de las mismas.
Día 14 del sprint: se comienza la preparación de la demo

Notas adicionales:

Las fechas indicadas son orientativas y no es obligado el cumplimiento aunque se intentarán cumplir en la medida de lo posible.
Si se van liberando los archivos .feature o historias de usuario antes de las fechas, se irán adelantando las notificaciones sin ser necesario esperar a los días fijados
Durante la última semana del sprint, se irá informando diariamente de las subidas de código a GIT y Sonar.

Planificación del taller práctico de entrega de planes de prueba mediante archivos .feature

Identificar si es necesaria la preparación por parte de equipo de calidad.

Duración

El tiempo de referencia para esta sesión son 3 horas.

Entrevista y acuerdos con la Oficina de Técnica de Interoperabilidad (OTI) de la STIC

Asistentes

Agile Coach - Obligatorio
Proxy Product Owner (Jefe de Proyecto) - Obligatorio
Representante Oficina Técnica de Interoperabilidad - Obligatorio
Scrum Master - Obligatorio
Desarrolladores - Obligatorio (al menos representación back-end)

Agenda

AGENDA

INFORMACIÓN ADICIONAL

NOTAS DE LA SESIÓN

Introducción a la sesión

Todos los asistentes deben tener claro el objetivo de la reunión.

Revisión acuerdos generales

Tras la sesión de alineamiento interna, el Scrum Master mostraría los acuerdos generales.

Alinear forma de trabajo con la OTI

Comunicación continua y flexibilidad como principios colaborativos: Durante la gestión ágil del Proyecto Ágil X, la coordinación entre el equipo y la OTI se basará fundamentalmente en el principio de mantener una comunicación continua y fluida, así como en la flexibilidad de todo el equipo (OTI + equipo).

Asistencia de la OTI a ceremonias/reuniones:

Aunque por defecto no se establezca como obligatoria la asistencia de personal de la OTI a las reuniones/ceremonias ágiles de Proyecto Ágil X, siempre estarán invitados a cualquiera de ellas.
La asistencia de la OTI a las ceremonias ágiles, así como la propuesta de otras reuniones fuera del flujo de trabajo ágil, se evaluará "ad-hoc" en base a las necesidades del proyecto y siempre intentando guardar un balance entre las prioridades del proyecto y la disponibilidad del personal de la OTI asociado al proyecto.

Flujo de trabajo: Para facilitar la interacción se seguirá un flujo de trabajo similar al abajo descrito:

#	Fase proceso	A cargo de	Notas
1	Identificación y priorización de necesidades de servicios en el roadmap del proyecto.	Equipo proyecto Ágil X	Ejemplos en los que es necesaria la definición de requisitos por parte de OTI: Comunicación inter aplicativos ...
2	Comunicación de nuevas necesidades o cambio de prioridades a OTI.	Equipo proyecto Ágil X	Por defecto, estas comunicaciones se harán como mínimo con 1 sprint de antelación a cuándo se haya identificado la necesidad
3	Reunión con responsable/representante funcional para revisar necesidades a partir de las cuales evaluar los requisitos.	OTI / Equipo proyecto Ágil X
4	Comunicación de requisitos definidos y exigibles a los servicios.	OTI	Los requisitos pueden ser de servicios nuevos o ya existentes. Los requisitos definidos para el servicio en cuestión se comunicarán con anterioridad a la planificación del desarrollo relacionado.
5	Validación integración de las comunicaciones en PRE.	OTI

Revisión Requisitos No Funcionales y otra normativa aplicable (si aplica)

Preparación por parte de equipo de OTI

Duración

El tiempo de referencia para esta sesión es 1 hora.

Entrevista y acuerdos con otros interesados del proyecto

Si durante el Taller Concepción de Producto (u otra sesión) se identificase la necesidad de integrar las necesidades, requisitos y/o normativa de otro interesado de la STIC (Seguridad, BI, Sistemas, otros proyectos...), se propondrá una sesión de entrevistas y acuerdos de acuerdo a las necesidades del proyecto.