Unidad 5. Introducción al modelo SCRUM - dpuenteramirez/GESPRO_Teoria_2021 GitHub Wiki

Introducción

Scrum es una metodología ágil además de simple (requiere una adaptación continua a las circunstancias y evolución del proyecto Al ser ágil, comparte los principios del desarrollo ágil:

  • Parte de un concepto o visión: El cliente tiene una idea general o visión del proyecto a obtener. El equipo de proyecto se reúne con el cliente e intenta transformar esa visión a unos requisitos formales.
  • Una construcción incremental del producto . En scrum las interacciones se denominan sprints y duran entre 2 y 4 semanas . Estos sprints tienen una fase de desarrollo y, una vez finalizados , tienen una fase de revisión en la que se comprueba que los objetivos del sprint han sido realizados
  • Cierre del producto

Como método ágil: es un modo de desarrollo adaptable (se va adaptando a los cambios) , orientado a las personas (prioridad a los clientes, equipo de desarrollo) , y que emplea el modelo de construcción basado en iteraciones y revisiones

Reglas de Scrum

Roles

Todas las personas implicadas con el proyecto tienen, según sus roles, diferentes niveles de compromiso y responsabilidad.

Propietario del producto

El propietario del producto, o product owner, es quien toma las decisiones del cliente. En los desarrollos internos para la propia empresa, suele asumir este rol responsable de marketing, mientras que, en desarrollos para clientes externos, el responsable del proceso de adquisición del cliente. Sus responsabilidades son el desarrollo y administración de la pila del producto, y la exposición de la visión e historias de usuario, y participación en la reunión de planificación de cada sprint. Es quien está a cargo de la pila del producto. Esto quiere decir que es quien decide en última instancia cómo será el producto final. Como representante del cliente, también se responsabiliza de cumplir con los plazos de entrega previstos de las versiones del producto.

Desarrolladores

Lo forman el grupo de profesionales que realizan el incremento de cada sprint. Se recomienda que el equipo de desarrolladores tenga entre 3 y 9 personas, ya que más allá de 9 resulta difícil mantener la comunicación directa. Es un equipo multifuncional, en el que todos los miembros trabajan de forma solidaria con responsabilidad compartida, aunque algunos miembros sean especialistas en áreas concretas. Un equipo tiene espíritu de colaboración y un propósito común: conseguir el mayor valor posible para la visión del cliente. Un equipo scrum responde en su conjunto. Trabaja de forma cohesionada y autogestionada. No hay un gestor para delimitar, asignar y coordinar las tareas. Son los propios miembros los que se coordinan.

Scrum master

Es el responsable del cumplimiento de las reglas del marco de scrum. Se asegura de que éstas son entendidas por la organización y de que se trabaja conforme a ellas. Asesora y da la formación necesaria al propietario del producto y al equipo, y configura, diseña y mejora de forma continua las prácticas ágiles de la organización. El fin es que equipo y cliente sean capaces de organizarse y trabajar con autonomía. También es responsabilidad suya moderar las reuniones de scrum diarias, gestionar las dificultades de dinámica de grupo que puedan surgir en el equipo, y solucionarlos impedimentos detectados durante el scrum diario para que el sprint siga avanzando.  

Artefactos (elementos)

Los artefactos de scrum son sus herramientas, sus bloques de construcción elementales. Ayudan a los roles durante los eventos.

Pila del producto

La pila del producto es el inventario de funcionalidades, mejoras, tecnología y corrección de errores que deben incorporarse al producto a través de los sucesivos sprints. Su objetivo es describir el estado que tendrá el producto en el futuro y que dibuja la visión compartida por el equipo para planificar. Representa todo aquello que esperan cliente, usuarios y demás partes interesadas. Lo más común es referirse a las entradas de esta pila como historias de usuario. La característica esencial de este artefacto es que contiene información en continua evolución, y que más que un documento de requisitos es una herramienta que facilita la comunicación de información al equipo. Este carácter dinámico permite que el producto se adapte a circunstancias cambiantes.

Pila del sprint

La pila del sprint o sprint backlog es la lista de todas las tareas necesarias para construir las historias de usuario que se van a realizar en un sprint, y debe definir y estar alineada con el objetivo del sprint. En ella las historias de usuario se descomponen en unidades de tamaño adecuado para monitorizar el avance a diario, así como para identificar riesgos y problemas sin procesos de gestión complejos. La pila del sprint es territorio del equipo, que colabora en su confección, durante la reunión de planificación del sprint, indicando para cada tarea el esfuerzo previsto para realizarla. Debe incluir sólo la información necesaria, como la lista de tareas y, por cada una de ellas, la persona responsable, el estado en que se encuentra y el esfuerzo que falta para completarla.

Incremento

El incremento es la parte de producto producida en un sprint y que se encuentra en condiciones de ser entregada al cliente, es decir, terminada, probada y operativa. El objetivo del incremento es cumplir con las medidas de calidad que requiere el producto. La “definición de hecho”, debe ser conocida y compartida por todo el equipo, y el incremento no se considera terminado hasta que no se alcanza el criterio de “hecho”.  

Eventos (reuniones)

En este apartado se detallan las prácticas y actividades que constituyen la rutina de trabajo en scrum.

Sprint

Es el evento clave de scrum para mantener un ritmo de avance continuo. Es un periodo de tiempo acotado, cuya duración se recomienda que no exceda de 4 semanas, durante el que se construye un incremento del producto. Marca el ritmo de avance diario y permite visualizarlo y compartirlo en las reuniones de pie.

Reunión de planificación del sprint

Esta reunión marca el inicio de cada sprint. En ella se toman como base las prioridades y necesidades de negocio del cliente y se determinan cuáles y cómo van a ser las funcionalidades que se incorporarán al producto al terminar el sprint. Se trata de una reunión conducida por el scrum master (o, en su ausencia, un desarrollador) a la que deben asistir el propietario del producto y los desarrolladores, y en la que también pueden estar presentes otros implicados en el proyecto. Puede durar hasta una jornada de trabajo completa, según el volumen o complejidad de los elementos de la pila del producto (historias de usuario) que se desean incluir en el próximo incremento. La reunión debe tratar cuál sería el incremento de valor con el resultado del sprint, los elementos de la pila del producto a realizar y las tareas en las que se va a dividir.

Scrum diario

Reunión diaria breve, de no más de 15 minutos, de comunicación entre el equipo, en la que los desarrolladores sincronizan el trabajo y establecen el plan para las 24 horas siguientes. Pueden asistir también otras personas relacionadas con el proyecto o la organización, aunque éstas no intervienen. Cada miembro del equipo de desarrollo explica lo que ha logrado desde el anterior scrum diario, lo que va a hacer hasta el siguiente, y si está teniendo algún problema o si prevé que puede encontrar algún impedimento. Se actualiza sobre la pila del sprint el esfuerzo que estima pendiente en las tareas que tiene asignadas, ose marcan como finalizadas las ya completadas. Al final de la reunión el equipo refresca el gráfico de avance del sprint las estimaciones actualizadas.

Revisión del sprint

Reunión realizada al final del sprint para comprobar el incremento. Lo habitual es que dure una o dos horas. En caso de incrementos de especial relevancia o complejidad, puede extenderse hasta 4 como máximo. Asiste todo el equipo scrum y todas las personas implicadas en el proyecto que lo deseen. Esta reunión marca, a intervalos regulares, el ritmo de construcción, y la trayectoria que va tomando la visión del producto. Al ver y probar el incremento, el propietario del producto y el equipo en general obtienen feedback relevante para revisar la pila del producto. Se identifican las historias de usuario que se pueden considerar hechas y las que no. Después, el propietario del producto tratará las posibles modificaciones que surjan.

Retrospectiva del sprint

Reunión que se realiza tras la revisión de cada sprint, antes de la reunión de planificación del siguiente. La duración recomendada es de una a tres horas. En ella, el equipo scrum reflexiona sobre su forma de trabajar. Se identifican fortalezas y puntos débiles, para afianzar las primeras y planificar acciones de mejora sobre los segundos. Se diferencia de la revisión del sprint en que esta analiza qué se está construyendo, mientras que en la retrospectiva se analiza el cómo. En la retrospectiva del sprint participa todo el equipo scrum. Es importante que el propietario de producto se considere “equipo” más que “cliente”. Que la persona que desempeña el rol sea participativa y conocedora de los principios y valores de scrum. Si esto no fuera así, el scrum master debe actuar como facilitador para lograr su compromiso y participación o, si la situación lo requiere, no incluirlo en la retrospectiva.

CONTROL DE LA EVOLUCIÓN DEL PROYECTO.

Prácticas o tácticas en SCRUM para controlar la evolución:

Revisión tras cada sprint

Una revisión de Sprint bien ejecutada, aunque parezca poco espectacular, tiene un efecto muy profundo:

  • El equipo obtiene reconocimiento por sus logros.
  • Otras personas se enteran de lo que está haciendo el equipo.
  • La revisión consigue feedback vital de los interesados.
  • Las revisiones son un evento social donde diferentes equipos pueden interactuar unos con otros y discutir su trabajo.
  • Hacer una revisión fuerza al equipo a acabar realmente las cosas y entregarlas (incluso aunque sea sólo en entorno de pruebas).

Desarrollo incremental

Esto significa mantener el diseño simple desde el principio y mejorarlo continuamente, en lugar de conseguir que todo funcione desde el principio y entonces congelarlo. Se emplea una cantidad razonable de tiempo refactorizando y mejorando los diseños existentes, y rara vez se emplea tiempo haciendo grandes diseños desde el principio.

Desarrollo evolutivo (solapamiento de fases)

Intentar predecir en las fases iniciales como será el producto final y sobre dicha predicción desarrollar el diseño y la arquitectura del producto no es realista porque las circunstancias obligarán a remodelarlo muchas veces. El desarrollo Scrum va generando el diseño y la arquitectura final de forma evolutiva durante todo el proyecto. No lo considera como productos que deban realizarse en la primera fase del proyecto

Auto-organización

Para que la auto-organización sea un éxito, el equipo debe tener unos objetivos, marco y reglas claros, así como las habilidades e información necesarias para poder realizar ese trabajo de manera efectiva. Para ello será importante seleccionar en el inicio las personas, equipos y áreas adecuadas, ya que quizás no todo el mundo esté desde el principio receptivo a estos nuevos paradigmas de gestión basados en autonomía y responsabilidad.

Colaboración

Scrum sistematiza la colaboración entre el cliente y el equipo: *El equipo participa con el cliente en la creación de la lista de objetivos/requisitos priorizada del producto o proyecto, en las reuniones de replanificación del producto o proyecto *En el inicio de cada iteración, en la reunión de planificación de la iteración el equipo pregunta al cliente los detalles que pueda necesitar de los requisitos para poder dimensionar mejor el contenido de la iteración. *Al finalizar cada iteración el equipo realiza una demostración al cliente de los requisitos completados.

Scrum sistematiza la colaboración dentro del equipo mediante las siguientes actividades: *Reunión de planificación de la iteración *Reunión diaria de sincronización del equipo *Retrospectiva