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

Área de Gobernanza y Calidad

Resumen
  • Versión: v01r01
  • Fecha publicación: 30 de Julio de 2021
  • Entrada en vigor desde: 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 2021Fecha entrada en vigor30 de Julio de 2021
  • Primera versión de métricas, orientada al seguimiento de: a) el valor entregado a través del contenido funcional, b) de la mejora continua a través de la vigilancia de la reserva para contenido no planificable, de la predictibilidad y de la variación de la velocidad trimestral c) satisfacción del Sprint a través de la satisfacción del Product Owner, desarrolladores y de otros interesados de la STIC  d) de la calidad a través de la cobertura de pruebas unitarias y de pruebas automáticas.



Introducción

  • En este documento se hace una revisión de las métricas de desarrollo aplicables a proyectos ágiles.
  • El Scrum Master hará seguimiento de las anteriores métricas (descargar documento de referencia adjunto más arriba) cíclicamente en cada SPRINT.
  • Estas métricas pretenden servir de guía en relación a la consecución de los siguientes objetivos:
      1. Valor entregado - Maximización del valor entregado a usuarios.
      2. Mejora continua - Reducir el alcance no planificado de un Sprint, mantener un creciente pero sostenible ritmo de trabajo y mejorar la predictibilidad de los equipos.
      3. Satisfacción - Aumento de la satisfacción de Product Owners, Equipo y Stakeholders.
      4. Calidad - Aumento de la calidad a través del % de cobertura y otras pruebas automáticas.
Documentos asociados

¿Cómo leer los resultados del Sprint? - Glosario de KPIs

Valor Entregado

  • Objetivo: Con esta sección se pretende poner foco en la configuración del alcance de cada Sprint, teniéndose como objetivo el de Maximizar el alcance de nuevo contenido funcional (Contenido funcional >60%).
  • Descripción: Esta sección se compone de una sola métrica obtenida a través de las filas "BA" y "BB", pretendiéndose medir la cantidad de puntos planificados en el Sprint para el desarrollo de nuevo contenido funcional. De aquí se excluyen bugs de desarrollo y otro contenido relacionado con el mantenimiento.

  • Para complementar el seguimiento del valor entregado, puede apoyarse en la gráfica de evolución del contenido planificado del Sprint prestando atención a la evolución del %Puntos Funcionales que componen el backlog de cada Sprint.

Mejora Continua

  • Objetivo: Este set de métricas persigue mantener un creciente pero sostenible ritmo de trabajo y mejorar la predictibilidad de los equipos, incluyendo la reducción del alcance no planificado de los Sprints.
  • Descripción: Esta sección está compuesta por un set de 3 métricas:
    1. Reserva no planificable: En aquellos Sprints en los que de antemano se conoce la posibilidad de tener que abordar cierto contenido no planificable, es recomendable anticipar este hecho con una reserva de la capacidad del equipo para así reducir el impacto sobre el contenido planificado durante la Sprint planning. Esta reserva suele ser del 5%-10%, desaconsejándose reservas superiores al 20%.
    2. Predictibilidad: De cara a impulsar la confianza de los Product Owners y del resto de stakeholders sobre las planificaciones, es importante mantener unos valores altos de predictibilidad, entendiéndose esta como el porcentaje de puntos entregados respecto a la capacidad esperada del Sprint.
    3.  ∆Velocidad (trimestral): La velocidad trimestral compara la diferencia de velocidad entre un set de 4 Sprints (3 meses aprox) y la velocidad del set de 4 Sprints anteriores. Un aumento de la velocidad trimestral pone de manifiesto el aumento de capacidad de ejecución de elementos del backlog por parte del equipo. Esta métrica es especialmente relevante cuando, a igualdad de condiciones, la velocidad trimestral del equipo disminuye  consistentemente (∆Velocidad (trimestral)<0), siendo especialmente recomendable investigar junto con el equipo las posibles causas raíz. De igual manera, se ha de estar atenta/o, cuando a igualdad de condiciones, se produzcan incrementos bruscos (∆Velocidad (trimestral)>50%) en equipos consolidados (+8 Sprints ejecutados), ya que este hecho puede evidenciar un ritmo insostenible para el equipo.

Para complementar el seguimiento de la mejora continua, puede apoyarse en las siguientes gráficas:

    • GRÁFICA EVOLUCIÓN DE PUNTOS QUEMADOS DE LOS SPRINTS

De esta gráfica pueden obtenerse las siguientes lecturas:

      1. Deuda técnica: El área roja representa la cantidad de deuda arrastrada de Sprints anteriores o deuda técnica. La deuda técnica se obtiene como la suma de los Puntos no entregados del contenido planificado (cumplimiento del 100% DoD) en el Sprint más Puntos de Historia de Bugs No Resueltos. La presencia sostenida o recurrente en el tiempo de este área roja puede suponer con alta probabilidad un freno para el avance funcional del aplicativo. 
      2. Velocidad normalizada: La velocidad normalizada es la velocidad del equipo (puntos quemados en un Sprint), normalizado a un Sprint equivalente de 15 días con una disponibilidad del equipo del 100%. Una fluctuación excesiva de la velocidad normalizada puede evidenciar un ritmo del equipo insostenible (al igual que ∆Velocidad trimestral). Ejemplo de cálculo: Si en un sprint se han conseguido 40 puntos de historia del contenido planificado, el sprint dura tres semanas pero tiene dos días festivos por lo que hay 13 días hábiles, y el equipo ha tenido una disponibilidad del 90% para el contenido planificado del sprint. Con todo ello, la velocidad normalizada del equipo será → 40 puntos · 15 días / 13 día · 1/90% días = 51
      3. Puntos quemados No Planificables, Puntos quemados Fuera de Backlog y Puntos Planificables: La proporción de debería ser mayoritaria en la mayor parte de los Sprints. La recurrencia de una presencia significativa de  y especialmente de  pone en serio peligro la predictibilidad de los Sprints, la efectividad del equipo y de la gestión ordenada del proyecto.


    • GRÁFICA DE EVOLUCIÓN DE DESVIACIÓN DE PUNTOS ENTREGADOS FRENTE A LAS EXPECTATIVAS DEL SPRINT

De esta gráfica pueden obtenerse las siguientes lecturas:

      1. Si las Desviaciones (bien de contenido planificable, no planificable o totales) se mueve recurrentemente (+3 Sprints) en valores positivos  es posible que, entre otras, la estimación de la capacidad del sprint sea excesivamente conservadora y sea recomendable aumentar la velocidad de referencia para el equipo.
      2. Si las Desviaciones (bien de contenido planificable, no planificable o totales) se mueven en recurrentemente (+3 Sprints) en valores negativos es posible que, entre otras, la estimaciones de la capacidad del sprint sea excesivamente optimista y sea recomendable comprometerse con una cantidad de items del Product Backlog durante la Sprint Planning.

Satisfacción

  • Objetivo: Este set de métricas pone el foco en la satisfacción de Product Owners, de los desarrolladores y de otros interesados de la STIC
  • Descripción: Esta sección, se alimenta del feedback dado por los diferentes interesados al final del Sprint durante la Sprint Review y clasifica el feedback en 3 intervalos: satisfacción alta en color verde (≥7), satisfacción media en color amarillo (5<satisfacción<7) y satisfacción baja en color rojo (satisfacción≤5). Se pretende el sostenimiento en el tiempo de una satisfacción alta de todos los interesados dentro del proyecto.



Calidad

  • Objetivo: En esta sección se pretende visibilizar el sostenimiento de la calidad, poniendo el foco en la cobertura de test unitarios y la automatización de otras pruebas (componentes, integración, API, GUI, etc)
  • Descripción:
    1. Pruebas automáticas: A través de una variable dicotómica (SI/NO), se pretende visualizar los esfuerzos invertidos en el proyecto para impulsar una cultura robusta de pruebas automáticas.
    2. Cobertura: La métrica mostrada pretende visualizar el cálculo de cobertura de pruebas unitarias promedio del código del Sprint obtenida a través de Sonar, siendo la cobertura de referencia para proyectos ágiles ≥65% de acuerdo al DoD estándar de la STIC.





¿Cómo rellenar la hoja de métricas?

La propia hoja de cálculo contiene las explicaciones de los campos que han de rellenarse, para rellenarlo se han de seguir los siguientes pasos:

  1. Cálculo de la capacidad del equipo disponible para el Sprint, como ayuda se ha incluido la pestaña "Capacidad del Sprint" a estos efectos
  2. Rellenar datos asociados a la planificación del Sprint tras la Sprint Planning. La cabecera de estas celdas se identifican con el siguiente color →
  3. Rellenar los datos asociados a la entrega como resultado de la Sprint Review. La cabecera de estas celdas se identifican con el siguiente color → 

Las celdas identificadas con color azul son celdas calculadas automáticamente.

PASO 1 - Capacidad del Sprint

Dentro de la pestaña "Capacidad Sprint", con anterioridad a la Sprint Planning, se han de introducir los siguientes datos:

  1. Días del nuevo Sprint (celda D2): aquí deberían introducirse los días hábiles del próximo Sprint. Por defecto serán 15 días.
  2. Velocidad normalizada de referencia (celda D3): aquí debería introducirse la velocidad normalizada de referencia para el equipo en Sprints pasados. Este dato puede extraerse de las celdas G20:AP20 de la pestaña "KPIs"
  3. Días de NO disponibilidad del equipo (celdas D8:R15): aquí han de incluirse las fracciones de día no disponible dentro del Sprint para cada desarrollador. Así pues, si un desarrollador ha tenido 3 horas de formación un día normal de trabajo de 8 horas, el cálculo sería 3/8=0,375. Si en cambio, se tiene jornada reducida de 35 horas, el cálculo de indisponibilidad de los días de esa semana sería (40-35/40)=0,125. Nota: en caso de que en el Sprint haya un festivo y ya se haya contado en la celda D2 como un día menos (p.ej. 14 días en lugar de 15), se ha de prestar especial cuidado con no incluirlo en este cuadro de nuevo → en el ejemplo se han contado 15 días para el Sprint, pero luego se ha contado el día 13 del Sprint como festivo para todo el mundo.
  4. Días de Disponibilidad media del equipo de desarrollo (celdas U8:U15): Este sería el dato que se calcularía automáticamente y que introduciríamos en la columna "Disponibilidad media del equipo" (columna AU) de la página KPIs para el Sprint correspondiente
  5. Velocidad esperada del Sprint (celdas W8:W15): Este sería el dato que se calcularía automáticamente y que introduciríamos en la columna "Velocidad esperada del Sprint" (columna AV) de la página KPIs

PASO 2 - Rellenar datos de la planificación (tras Sprint Planning)

Dentro de la pestaña "KPIs", justo tras la Sprint Planning, se rellenarán las celdas de las cabeceras amarillas →

  1. Disponibilidad media del equipo (columna AU): se obtiene de la celda U8 de la pestaña "Capacidad del Sprint"

  2. Velocidad esperada del Sprint (columna AV): se obtiene de la celda W8 de la pestaña "Capacidad del Sprint"

  3. Puntos planificados (columna AW): estos son los puntos planificados finalmente en el Sprint, excluyendo la reserva para contenido no planificable (si la hubiera). Puede extraerse de JIRA del cómputo total de puntos incluidos en el Sprint
  4. Puntos reservados para contenido no planificado (columna AX): Si de antemano se supiese que en el Sprint ocurrirá algún evento que forzará a ampliar el alcance del mismo puesto que el desarrollo asociado no sea prorrogable a otro Sprint por extrema urgencia, puede dejarse una reserva dentro de la capacidad del Sprint que no es aconsejable que sea superior al 10%.
  5. Puntos Funcionales, Bugs/Deuda Técnica, Incidencia, Operación, Otros (columnas BA:BE): En estas columnas se pretende discernir el contenido planificado para el Sprint en función del tipo de Historia de Usuario: Puntos Funcionales, Puntos Bugs y Deuda Técnica, Puntos Incidencia, Puntos Operación, Puntos Otros

PASO 3 - Rellenar datos de la entrega (tras Sprint Review)

  • Dentro de la pestaña "KPIs", justo tras la Sprint Review, se rellenarán las celdas de las cabeceras verdes →

    1. Puntos quemados planificados (columna BN): son los puntos quemados (desarrollados, testeados y aceptados por Product Owner) de los originalmente planificados. Nota: el seguimiento de los mismos puede extraerse o bien mediante comparativa o bien a través de los informes de JIRA como se muestra en el siguiente ejemplo:

      Las HUs quemadas durante el Sprint que NO fueron inicialmente planificadas aparecen con un * (en el ejemplo la ECU-360), mientras que las que sí que lo fueron no tienen ninguna marca:


    2. Puntos quemados fuera de backlog (columna BO): Son aquellos puntos que se han incorporado al Sprint por mayor capacidad de la esperada para el Sprint. Para su cálculo, puede recurrirse a los informes de JIRA (ver ejemplo anterior)

    3. Puntos quemados no planificables (columna BP): Son aquellos puntos que se han incorporado al Sprint por mayor capacidad de la esperada para el Sprint. Para su cálculo, es recomendable identificarlos mediante una etiqueta y recurrirse a los informes de JIRA (ver ejemplo anterior)
    4. % de Cobertura (columna BW): Es la media de la cobertura Sonar de las HU del Sprint.
    5. Pruebas automáticas (columna BX): Es una variable dicotómica (SI / NO), siendo esta positiva cuándo se han automatizado pruebas en el Sprint distintas a las pruebas unitarias de código.
    6. Puntos bugs pendientes (columna BY): Puntos de aquellos Bugs que no han podido ser resueltos durante el Sprint. Cada vez que un Bug aparezca en el transcurso de un sprint éste se debe recoger en JIRA en el momento en el que se identifique.
    7. Satisfacción del Sprint (columnas BZ:CB): En una escala del 1 al 10, se recogen a la finalización del Sprint (recomendable en la Sprint Review) la satisfacción de los diferentes interesados con el Sprint
    8. Cambio miembros (columna CF): En caso de que haya habido alguna sustitución de miembros del equipo en el trascurso del Sprint, este parámetro tomará el valor correspondiente a dicha sustitución (p.ej. si en un Sprint se han sustituido 2 miembros por otros 2, este parámetro tomaría valor 2)