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

Área de Gobernanza y Calidad

Contenido


Resumen
  • Versión: v01r02
  • Fecha publicación: 30 de Julio de 2021
  • Entrada en vigor desde: 30 de Julio de 2021

Histórico de cambios

Los cambios en los estándares 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ón29 de Octubre de 2020Fecha entrada en vigor29 de Octubre de 2020
Alcance
  • Daily Stand-up: Objetivo, contenido, agenda típica, responsabilidades, preparación de la sesión y buenas prácticas
Versiónv01r02Fecha publicación30 de Julio de 2021Fecha entrada en vigor30 de Julio de 2021
Alcance
  • Se alinea la nomenclatura utilizada con la Scrum Guide del 20 de Noviembre de 2020; sustituyéndose el término "rol" por el de "responsabilidades" y el de "equipo de desarrollo" por "desarrolladores"
  • Se elimina la estructura rígida de la Daily, dando flexibilidad a la misma por parte del equipo y priorizando el objetivo de que se centre en el progreso hacia el objetivo de Sprint y produzca un plan accionable para el siguiente día de trabajo, de acuerdo a la guía SCRUM del 20 de Noviembre de 2020

Introducción

Esta página pretende esclarecer los aspectos fundamentales de la daily stand-up.



Objetivo

En su mayor expresión, un equipo ágil consigue mediante un "daily stand-up": 

  • Coordinación de tareas a bajo nivel (detalles): Los desarrolladores intercambian conversaciones rápidas y enfocadas, para conocer cuándo y cómo pueden contar los unos con los otros (p.ej. resolución de interdependencias, pedir ayuda a otros miembros, identificar potenciales colaboraciones, etc) para evitar tiempos de espera o bloqueos innecesarios.
  • Mantener el foco en completar tareas y reducir el "Work-in-progress": Los equipos ágiles se enfocan en completar tareas, lo que significa que velan porque las tareas no permanezcan demasiado en "Work-in-progress" (normalmente, no más de 3 - 5 días). Además, un equipo ágil sabe que siempre es mejor completar 5 tareas que dejar 15 a medias y por tanto se enfoca en reducir/limitar el "Work-in-progress".
  • Identificar posibles bloqueos: La daily proporciona un momento dorado para que cada desarrollador reflexione acerca de si hay algo que lo esté bloqueando o frenando
  • Compromiso diario: cada miembro realiza un compromiso diario con el resto del equipo, de manera que cada miembro sabe qué esperar del resto del equipo y cómo mantener a cada miembro responsable de los objetivos diarios.
  • Presión de grupo: Los equipos ágiles más experimentados perciben la presión del resto del grupo puesto que todos los miembros del equipo se han comprometido a completar el trabajo del sprint juntos, lo cual propicia que el trabajo (y las personas) sean interdependientes y responsables los unos de los otros


Contenido y Agenda típica

Los desarrolladores pueden seleccionar cualquier estructura y técnicas que deseen, siempre y cuando su Scrum diario se centre en el progreso hacia el objetivo de Sprint y produzca un plan accionable para el siguiente día de trabajo. Esto crea enfoque y mejora la autogestión.

Aunque la agenda convencional consiste en que cada desarrollador responde durante 2-5 mins las siguientes cuestiones:

  • ¿Qué hice ayer para avanzar en los objetivos del Sprint?
  • ¿Qué haré hoy para avanzar en los objetivos del Sprint?
  • ¿Hay algún bloqueo que impida al equipo cumplir los objetivos del Sprint?




Responsabilidades


Responsabilidad SCRUMDescripción
Scrum Master
  • Gestión de la convocatoria.
  • Facilitación de la sesión.
  • Identificar (y comunicar si fuese necesario) cuáles son los posibles bloqueos que puedan estar poniendo en riesgo los objetivos del SPRINT.
Desarrolladores
  • Asistencia y participación activa y abierta de cada desarrollador.
  • Compartir riesgos/bloqueos y propuesta de soluciones correctivas.
Product Owner
  • Asistencia Opcional

  • En caso de asistir, su participación no debe coartar la comunicación transparente y abierta del equipo

Proxy Product Owner
  • Asistencia Opcional

  • En caso de asistir, su participación no debe coartar la comunicación transparente y abierta del equipo



Preparación de la sesión

Revisión de tareas desarrolladas el día anterior por parte de los desarrolladores.



Buenas Prácticas

  • Realizar la sesión a la misma hora diariamente, pactada con el equipo (preferiblemente a primera hora de la mañana).

  • Conseguir sentimiento de propiedad colectiva de los objetivos del Sprint.

  • Animar al equipo a señalar tan pronto como lo identifiquen si algún objetivo del SPRINT se ve en riesgo.

  • Asegurar que cada miembro puede expresarse sin interrupciones.

  • Asegurar que cada miembro enlaza el trabajo que ha desarrollado/va a desarrollar con los objetivos del SPRINT.

  • Prestar atención a comunicación no verbal de los desarrolladores para identificar posibles puntos de bloqueo.

Anti-patrones

  • Miembros externos a los desarrolladores intervienen en la sesión.

  • No se mantienen las sesiones con regularidad.

  • Pobre colaboración entre los miembros del equipo (trabajo en silos).

  • Falta de sentimiento de propiedad colectiva del código y de los objetivos del Sprint.

  • Infrecuentes verificaciones/integraciones del trabajo desarrollado (p.ej. “estamos trabajando en algo y creemos que estará bien”).

  • Conflictos perpetuos/sin resolver dentro del equipo.

  • Sin etiquetas