Resumen The Scrum Guide

Hola a tod@s de nuevo,

En este post voy a hacer un resumen o esquema de la Guía de Scrum de Scrum.org. La guía es de lectura recomendada para aquellos que se quieran certificar en PSM I. Durante mi lectura de dicha guía realice un esqueleto que me permitiera poder repasar y recordar los principales conceptos del marco de trabajo Scrum. Este esquema lo realicé para mi y sin el objetivo de publicarlo. No obstante, lo he repasado a fin de publicarlo por si le puede servir a alguien de ayuda.

No me entretengo más...

AL LIO!!

Scrum es un marco de trabajo que se basa en los valores ágiles, de los cuales hablaré detenidamente en otro post. Dichos valores a grandes rasgos se centran en las personas, en la colaboración, en entregar productos que aporten y en tener la capacidad de adaptarse al cambio. Así Scrum crea una serie de elementos (llamados comúnmente artefactos) y eventos que permiten llevar estos valores a la práctica.

ARTEFACTOS

Los artefactos son los elementos entorno a los que se trabaja en Scrum. El objetivo de los artefactos es mostrar el valor del trabajo y proveer de transparencia. Existen tres artefactos en Scrum: Product Backlog, Sprint Backlog y los Incrementos.

Product Backlog
  • Es un listado ordenado de todo lo que el producto va a necesitar: características, funcionalidades, requerimientos, correcciones para los próximos incrementos.
  • Cada elemento se define por: descripción, orden, estimación y valor. Algunas veces también un conjunto de pruebas que deben superarse para dar por terminado el elemento.
  • Cada necesidad del cliente se plasma en forma de Historia de Usuario:
    • Codigo + Título (HU01 - Imagen del sistema).
    • Como: (Como: usuario del sistema).
    • Quiero: (Quiero: ver la web con la misma imagen que..).
    • Para: (Para: para que de la sensación de ser una web corporativa).
    • Estimación.
    • Condiciones: (Manera de validar que la Historia de usuario se ha ejecutado correctamente).
  • No es necesario describir en detalle todas las historias de usuario ni ordenarlas, sólo las más importantes.
  • Nunca acaba el Product Backlog, éste cambia según evoluciona el producto y su entorno (cambios en los requisitos de negocio, necesidades del mercado o tecnologías).
  • Un producto puede estar desarrollado por más de un Equipo Scrum. Todos comparten el Product Backlog, dado que éste define los siguientes trabajos en el producto.
  • Cualquier elemento que vaya a implementarse en el siguiente Sprint podrá ser redefinido a fin de que entre en el tiempo de un Sprint.
  • Una vez redefinidos los elementos para que se puedan hacer en un Sprint, están listos para ser elegidos en el Sprint Planning.
  • El Equipo de Desarrollo es el responsable de las estimaciones. El Product Owner puede guiarles a entender lo que se debe hacer a fin de obtener una mejor estimación, pero sólo guiarles.
Sprint Backlog
  • Hace visible todo el trabajo que el Equipo de Desarrollo estima necesario para alcanzar el objetivo del Sprint.
  • Para asegurar la mejora continua se debe incluir, al menos, una de las mejoras identificadas en la reunión de Restrospectiva.
  • El Equipo de Desarrollo puede modificar el objetivo o las tareas del Sprint si se encuentra una modificación en el esfuerzo necesario para llegar al objetivo del estimado.
  • El Sprint Backlog es una herramienta muy visible de lo que ha hecho o va a hacer el Equipo de Desarrollo. Éste sólo le pertenece al Equipo de Desarrollo.
Incremento
  • Es la suma de todos los elementos del Product Backlog terminados.
  • El valor del incremento es la suma de los valores de todos los elementos terminados.
  • Al acabar un Sprint, cada elemento que entre en el incremento debe ser marcado como "Terminado".
  • Cada incremento es un paso hacia la visión global.
  • Una Historia de Usuario marcada como "Terminado" debe estar lista para usarse.
  • Un incremento terminado no tiene por que liberarse obligatoriamente, es elección del Product Owner.

ROLES

Al igual que para la ejecución de un proyecto tradicional se dispone de diferentes perfiles o roles, en Scrum también existen. ¿Quién sino las personas puede ejecutar este marco de trabajo a fin de llevar a buen puerto los productos? En un proyecto tradicional disponemos de un jefe de proyecto y las personas que trabajan en el mismo. Dentro del grupo de personas que trabajan en el proyecto pueden existir distintos perfiles. Muchas veces, esos perfiles del grupo de trabajo no están únicamente asociados a dicho proyecto sino que pertenecen a otros departamentos con otros responsables.

En Scrum no existe un jefe como tal, la idea fundamental es que todos somos personas por igual con diferentes roles, o dicho de otra manera con diferentes responsabilidades, empujando con el mismo objetivo. Existen tres roles: Product Owner (o propietario de producto), Scrum Master y Development Team (o Equipo de Desarrollo).

Product Owner:
  • Define las tareas del Backlog.
  • Ordena las tareas del Backlog.
  • Asegura que el Backlog es visible, transparente y que se entiende.
  • Asegura de que el equipo entiende cada tareas.

Equipo de Desarrollo (No menos de 3 ni más de 9 personas)
  • Auto-organizado: ni el Scrum Master ni el Product Owner le puede decir como organizarse.
  • Conocimientos globales: cualquier miembro del Equipo de Desarrollo debe saber de todas las tecnologías utilizadas, es decir, debe ser capaz de realizar cualquier tarea.
  • Son todos por igual, no hay títulos con independencia del trabajo que se realice.
  • No existen sub-equipos
  • Independientemente de la especialidad de cada uno la responsabilidad es de todo el equipo.

Scrum Master
  • Está entre el Product Owner y el equipo de desarrollo.
  • Con el Product Owner:
    • Asegurarse de que todo el mundo entiende el proyecto.
    • Buscar la manera de tener una gestión eficiente.
    • Ayudar a organizar el Backlog para maximizar el valor.
    • Ayudar a entender y aplicar Agile.
    • Ayudar a que se cumplan los eventos Scrum.
  • Con el Equipo de Desarrollo:
    • Motivar al equipo para su auto-organización y desarrollo completo.
    • Ayudar a crear productos de calidad.
    • Ayudar a superar los problemas.
    • Ayudar a que se cumplan los eventos Scrum.
  • Con la organización:
    • Motivar a la empresa a adoptar Scrum.
    • Planificar la implementación de Scrum.
    • Ayudar a los empleados y clientes a entender Scrum.
    • Trabajar con otros Scrum Master para mejorar la implantación.

EVENTOS

Los eventos van a ser el hilo conductor de Scrum. Con ellos va a ser posible llevar a cabo todas las labores que permiten poner en práctica los valores de Scrum. Los eventos de Scrum son: Sprint, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective y la Cancelación.

Como puede verse los eventos giran entorno al Sprint. Un Sprint es un evento que se repite de manera periódica y con un tiempo establecido durante todo el proyecto. Este evento va a determinar cada cuanto tiempo revisamos el producto, planificamos los siguientes avances del producto y obtenemos un incremento. Por lo tanto, con este evento hacemos girar la rueda para poner en práctica la comunicación entre todos los miembros involucrados en la creación del producto y somos capaces de adaptarnos al cambio de manera regular y de forma natural.

El Sprint
  • No debe durar más de 1 mes trabajando 8 horas diarias.
  • Tras la finalización de un Sprint hay un entregable.
  • Durante el Sprint no se debe bajar la calidad:
    • Si el trabajo resulta ser más difícil de lo esperado se renegocia con el Product Owner el alcance del Sprint Backlog.
  • Objetivo del Sprint:
    • El objetivo del Sprint debe ser entendido por el equipo de desarrollo con el fin de poner una menta común para que trabajen todos juntos, en equipo, en vez de iniciativas individuales.
Cancelación
  • Se puede cancelar en cualquier momento.
  • No es bueno ya que puede ser traumático.
  • No es usual.
  • Las partes que pueden ser puestas en producción suelen ser aceptadas por el Product Owner.
  • El motivo más común es que el objetivo de Sprint se haya quedado obsoleto.
Planificación de Sprint
  • La planificación se hace con todo el Equipo de Scrum (Product Owner, Scrum Master y Equipo de Desarrollo).
  • El Scrum Master debe asegurarse de que en el planing quedan reflejados los eventos y que se entiende su uso.
  • La planificación no debe durar más de 8 horas para un Sprint de 1 mes (si el Sprint es menor se deberá ajustar proporcionalmente la duración del evento de planificación).
  • Se hace la Redefinición del Product Backlog:
    • Es el trabajo de definir con más detalle cada elemento del Producto Backlog. 
    • Después se estima el coste de cada Historia de Usuario (ej: Planing Pocket).
    • Este trabajo se realiza entre el Product Owner y el Equipo de Trabajo.
    • El Product Owner y el Equipo de Trabajo deciden cuando es suficiente la definición de cada elemento. 
    • No deberá consumir más del 10% de las capacidades del Equipo de Trabajo.
  • Una vez redefinido el Product Backlog, se debe contestar a las siguientes preguntas:
    • ¿Qué se puede hacer en el Sprint?
      • Entrada: el Backlog, el último incremento y la proyección de las capacidades del equipo.
      • Se selecciona el número de elementos del Backlog que se pueden desarrollar (Equipo de Trabajo):
        • Se eligen las Historias de Usuario a realizar en función de la velocidad del equipo y la valoración de alto nivel que se realiza de cada Historia de Usuario.
      • El Equipo de Desarrollo también establece un objetivo para el Sprint
    • ¿Cómo se va a hacer el trabajo elegido?
      • El Equipo de Desarrollo delibera cómo va a realizar los items elegidos y establecen un plan.
        • Cada Historia de Usuario se divide en tareas o actividades y las estima en 2, 4, 6 u 8 horas.
      • Elementos elegidos + plan para desarrollarlos = Sprint Backlog.
      • En la planificación del Sprint se deben fijar tareas de 1 día o menos.
      • Si tras la planificación se ve que es mucho o poco trabajo se pueden renegociar los elementos del Sprint con el Product Owner
      • Se puede pedir a otras personas expertas que participen en la reunión
    • Se realiza una planificación de los RRHH, se debe fijar el tiempo de trabajo, menos las ausencias ya programadas (actividades de Scrum /reunión diaria, review, retrospective/, vacaciones, permisos de 1 día, etc) y horas que estén trabajando en otros proyectos u otras tareas externas al proyecto. Después se le supone una capacidad del 80% a cada integrante a fin de tener margen para imprevistos (se pone malo alguno, algo es más difícil de lo que parece, etc)
    • Una vez estimadas las horas totales de todo el equipo y las horas de todas las tareas, se comparan. Si horas actividades <= horas equipo entonces la planificación pinta bien.
    • Para terminar el Equipo de Desarrollo deberá explicar al Product Owner y al Scrum Master como van a realizar el trabajo (como se van a auto-organizar) para conseguir un incremento anticipado.
Daily Scrum
  • Duración 15 minutos máximo.
  • El objetivo es planificar el trabajo del día.
  • Esta reunión mejora la colaboración entre los miembros del equipo.
  • Se lleva a cabo siempre a la misma hora y lugar a fin de minimizar complejidades (si siempre es igual es una cosa menos de la que tener que preocuparse).
  • Preguntas recomendadas:
    • ¿Qué hiciste ayer para conseguir el objetivo del Sprint?
    • ¿Qué vas a hacer hoy para conseguir el objetivo del Sprint?
    • ¿Ves algún impedimento o problema que pueda impedir llegar al objetivo del Sprint?
  • El Equipo de Desarrollo se suele reunir después de la Daily Scrum para revisar la planificación y readaptarla.
  • El Scrum Master se asegura de que la reunión tenga lugar y de que efectivamente dura 15 minutos.
  • Si hay otros asistentes el Scrum Master debe asegurarse de que no interrumpen.
  • Se consigue: evitar otras reuniones, mejora la comunicación, identifica impedimentos, se toman decisiones rápidas y mejora el nivel de conocimiento del equipo.
Sprint Review
  • Es una reunión informal.
  • Se reúne el Equipo de Scrum con los interesados.
  • Para un Sprint de 1 mes, el Sprint Review no debe durar más de 4 horas (si el Sprint es menor ésta reunión también).
  • El Scrum Master debe enseñar el objetivo de la reunión y a saber quedarnos dentro de esos tiempos.
  • Antes de empezar se debe revisar que Historias de Usuario han cumplido con la definición de "Terminado". Sólo estas Historias de Usuario pasaran a formar parte de la reunión. El resto volverán al Product Backlog.
  • Incluye:
    • El Equipo Scrum y las personas clave del cliente invitados por el Product Owner.
    • El Product Owner indica que elementos del Product Backlog han sido hechos y cuales no.
    • El Equipo de Desarrollo explica cuales se han desarrollado con normalidad, en cuales han tenido problemas y cómo los han resuelto.
    • El Equipo de Desarrollo demuestra que el trabajo ha sido realizado (se enseña el software funcionando y no diapositivas o imágenes) y contestan a las preguntas que se les haga acerca de esta actualización.
    • Si es necesario el Product Owner explica como vamos con el proyecto y como ve la progresión del proyecto en base a la velocidad de avance actual (si camia algunas fechas a menos tiempo o a más):
      • La velocidad de avance del Equipo de Desarrollo es la suma de las estimaciones de Historias de Usuario que han realizado en un Sprint. Inicialmente un equipo irá aumentando mucho su velocidad de Sprint en Sprint, pero llegará un punto en que la velocidad se estabilice. El número de las estimaciones no deben ser horas, por ejemplo con Planing Pocket no se tiene horas sino esfuerzo necesario en relación al resto de Historias de Usuario.
    • Partiendo de la información de la reunión se debe hablar de que es lo que se desea hacer a continuación.
    • Se revisa la línea de tiempo, el presupuesto y las capacidades potenciales con el mercado para estimar que debería ir en la próxima entrega.
  • El resultado es una revisión del estado del Product Backlog, definiendo los elementos para el siguiente incremento. Además, el Product Backlog puede ser ajustado en función de nuevas oportunidades que se hayan visto.
Sprint Retrospective
  • Sirve para estimar los problemas que pueden surgir en el próximo Sprint y trazar un plan para solventarlos.
  • Esta reunión se produce después del Sprint Review y antes de la reunión de Sprint Planning.
  • Duración: Sprint de 1 mes --> Sprint Retrospective de 3 horas máximo
  • Objetivos:
    • Ver como ha ido el último Sprint en referencia a la relación con las personas, procesos y herramientas.
    • Identificar lo que fue bien y proponer mejoras.
    • Crear un plan para poner en marcha esas mejoras.
  • El Scrum Master debe tratar de mejorar el rendimiento del equipo con estas reuniones.
  • Al acabar la reunión el equipo debe tener claras algunas mejoras y como implementarlas.
  • Será cosa del equipo llevarlas a cabo. Las mejoras se pueden aplicar en cualquier momento esta reunión es sólo para fijar, de manera formal, un momento en el que pararse a pensar en ellas.

REVISIÓN DEL PROGRESO

Uno de las herramientas que nos permite mantener un ambiente colaborativo y de confianza, básico para esta manera de trabajar, es la transparencia. Por ello en Scrum se plantea la necesidad de poder mostrar, en cualquier momento, el estado y la velocidad de progreso del proyecto.

Tenemos dos elementos principales en el proyecto, el primero es el producto (definido por el Product Backlog) y el segundo es el trabajo a realizar (definido por el Sprint Backlog). Por lo tanto, para poder tener una visión transparente y accesible a todo el mundo del progreso del proyecto se debe facilitar el avanze de estos artefactos.

Para revisar el progreso del Sprint existen herramientas como los gráficos Burns-Down. Estos gráficos permiten mostrar de una manera muy visual el tiempo que falta, por día, para terminar cada una de las tareas del Sprint Backlog. Así se puede ver claramente si vamos mejor o peor que la estimación ideal. Es muy importante tener en cuenta que en estos gráficos no se muestra el tiempo que se ha estado trabajando en una tareas. En estos gráficos se representa, cada día, el tiempo que FALTA para terminar la tarea, con independencia del tiempo que le hayamos dedicado. Esto es así, por que es falso que si estimas 5 horas para una tarea y empleas 3 te queden, siempre, 2 horas para terminar la tarea. Según avanzas en una tarea puedes encontrarte elementos con los que no contabas que te pueden alargar o acortar el tiempo necesario para su implementación.

Para revisar el progreso del producto se pueden usar herramientas como los gráficos Burns-Up. En estos gráficos mostraremos la velocidad de cada Sprint, es decir, la cantidad de estimación que se ha terminado en cada Sprint. Así, teniendo el historial de velocidades, la estimación de las futuras Historias de Usuario y la estimación de esfuerzo necesario para la consecución de algunas necesidades del producto, se puede saber si el proyecto avanza más o menos como esperábamos, más rápido o más despacio.

Hasta ahora hemos visto los artefactos, una manera de llevar a buen puerto los valores ágiles mediante los eventos y maneras de monitorear que todo va según lo estimado. Sin embargo, hay un elemento básico que podríamos decir que es el pegamento de todas estas piezas. Este elemento es el que va a definir que una Historia de Usuario está terminada (Done).

Definición de "Terminado" (Done):
  •  Todo el mundo debe tener claro que significa "Terminado" para que cuando se diga que elemento se marque como "Terminado" todo el mundo sepa lo que es. Así se fomenta la transparencia.
  •  Si la definición de "Terminado" se recoge de la definición en un estándar, guías o desde la organización se deberá coger esta definición como un mínimo.
  •  Si la definición de "Terminado" no parte de ningún sitio, el Equipo de Scrum deberá establecer una definición de "Terminado" apropiada para el producto. Si hay varios Equipos de Desarrollo o Equipos Scrum, la definición deberá ser consensuada entre todos los equipos.
  •  Cualquier producto o sistema debe tener una definición de "Terminado" que es un estándar para cualquier trabajo realizado en él.
Con este resumen espero haber esquematizado suficientemente bien el contenido de la Guía de Scrum  y, lo que es más importante, que le sirva a alguien de ayuda para su estudio.

Un abrazo a tod@s :D

Comentarios

  1. ¡Gran resumen! Muy buena síntesis. Anima a profundizar tras una lectura liviana y muy amena. Gracias.

    ResponderEliminar

Publicar un comentario

Entradas populares