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ónv01r01Fecha publicación30 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:


ACUERDORESULTADOINFORMACIÓN ADICIONAL
Introducción a la sesiónTodos los asistentes tiene claro el objetivo de la reunión.
Herramientas de comunicación

Escrita

Correo, Teams, Circuit, Simil,...


VideoconferenciaTeams, 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 proyectoPack 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


AGENDAINFORMACIÓN ADICIONALNOTAS DE LA SESIÓN
Introducción a la sesiónTodos los asistentes deben tener claro el objetivo de la reunión.
Revisión Requisitos No Funcionales y otra normativa aplicablePreparación por parte de equipo de arquitectura.
Revisión acuerdos generalesTras 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


AGENDAINFORMACIÓN ADICIONALNOTAS DE LA SESIÓN
Introducción a la sesiónTodos los asistentes deben tener claro el objetivo de la reunión.
Revisión acuerdos generales

Revisión DoD y DoRSe utilizará como punto de partida el DoR/ DoD estándar de la STIC.
Alinear actividades de la OCA en el proyectoSe 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 .featureIdentificar 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


AGENDAINFORMACIÓN ADICIONALNOTAS DE LA SESIÓN
Introducción a la sesiónTodos los asistentes deben tener claro el objetivo de la reunión.
Revisión acuerdos generalesTras 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 procesoA cargo deNotas
1Identificació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
  • ...
2Comunicación de nuevas necesidades o cambio de prioridades a OTI.Equipo proyecto Ágil XPor defecto, estas comunicaciones se harán como mínimo con 1 sprint de antelación a cuándo se haya identificado la necesidad
3Reunión con responsable/representante funcional para revisar necesidades a partir de las cuales evaluar los requisitos.OTI / Equipo proyecto Ágil X
4Comunicació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.

5Validació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.

  • Sin etiquetas