Pero… ¿Qué es Scrum?
- Scrum es el método ágil de desarrollo de Software más utilizado del mundo. Se presentó en 1995 y hoy en día, más del 70% de los equipos de desarrollo de Software en el mundo lo usan.
- Scrum es simple pero no es fácil.
- Las compañías que consiguen implementarlo, consigue mejoras de 4 a 10 veces en productividad, time-to-market y competitividad.
DevOps y Scrum, una unidad.
Scrum ha evolucionado significativamente para adaptarse a nuevos retos e ideas durante los últimos 20 años. A pesar de todo, muy pocas compañías consiguen vencer sus propias resistencias para conseguir todos los beneficios de Scrum.
El movimiento de Scrum surge de la mano del Movimiento Ágile, con la publicación del Agile Manifesto por líderes de la industria en el 2001. La realidad del mercado entonces era lamentable.
Los proyectos de desarrollo de Software se planificaban durante años antes de escribir una sola línea de código, llevando a catástrofes como la del proyecto Sentinel del FBI, en el que después de invertir más de 60 millones de dólares, hubo que rehacer todo el Software de nuevo.
Los orígenes de Scrum
Seis años antes, Jeff Sutherland y Ken Schwaber habían presentado Scrum en una conferencia de desarrollo de software. Utilizando un paper publicado en 1986, llamado “The new new Product Development Game”, en el que se analizaban las formas de trabajo de equipos de éxito, destilaron sus reglas para ponerlas al servicio del mundo.
Así nació el que hoy en día se considera el estándar para la gestión de iniciativas complejas de desarrollo de producto.
Los profesionales que lo utilizaban no dispusieron de una guía oficial hasta bien entrado el nuevo milenio.
Cuando en 2011, Ken Schwaber y Jeff Sutherland decidieron publicar la guía oficial de Scrum, lo hicieron atendiendo a un problema cada vez mayor: cada profesional veía Scrum de una manera distinta y, lo que en su momento eran una serie de reglas, se convirtió en algo que quedaba a las más pura interpretación del profesional que lo implantaba.
¿No pasa con DevOps lo mismo? Cuando hablamos de DevOps, ¿no tenemos todos en mayor o menor medida, una distorsión?
Ha evolucionado con el tiempo para recoger la forma en que se utiliza en la práctica. Desde 2011 ha habido dos grandes cambios en la guía de Scrum, en 2013 y 2016.
Primero, se eliminaron algunas cosas, como los diagramas de burndown. Se reforzó el énfasis en el Daily Scrum como elemento de planificación - y no solamente sincronización - y tambien se cambió el nombre de la reunión de grooming a refinement. Todos estos conceptos los veremos más adelante.
En 2016 se añadieron los valores de Scrum, aquellos que hacen que el marco funcione en una organización, además de algunos cambios menores.
Una de las cuestiones importantes que trajo la guía de Scrum es que dejó de llamarse SCRUM. Hace muchos años, cuando se publicó el paper original sobre Scrum, se eligió en mayúsculas para darle más énfasis. Sin embargo, parece que muchos profesionales siguen tratándolo como un acrónimo.
La guía de Scrum es el documento que explica en detalle cuales son las mecánicas:
- Sus Eventos (Sprint, Sprint Planning, Daily Scrum, Sprint Review y Sprint Retrospective)
- Sus Roles (Scrum Master, Product Owner y Development Team)
- Sus Artefactos (Product Backlog, Sprint Backlog e Incremento)
https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Spanish-Latin-South-American.pdf
https://scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Spanish-SouthAmerican.pdf
Analicemos un caso práctico
- Estudiantes IT 2020 es una startup con sede en Argentina. Su productos es una plataforma de pagos entre particulares y empresas, que permite a los usuario decidir si quieren recibir un pago con dinero en efecto o quieren obtener vales regalo por un importe superior.
- Estudiantes IT 202 tiene un equipo de 9 desarrolladores con diferentes perfiles que se encargan de diferentes partes del producto,
- Todos los requisitos del producto están recogidos y expresados en una lista, el Product Backlog. Esta lista contiene todo el trabajo que hay que hacer al producto y que lleva muchos meses. El Product Owner, que representa al negocio, se encarga de mantener la lista actualizada y en lo alto coloca las prioridades más urgentes. Este rol es el único que decide sobre las prioridades y es responsable de decidir hacia dónde debe ir el producto.
- El equipo de Estudiantes IT 2020 hace una entrega de producto cada cuatro semanas. Al principio de la primera semana, el Development Team se reúne con el Product Owner en una reunión de planificación (Sprint Planning), donde éste le explica al equipo que su máxima prioridad es entregar la parte de la plataforma que se encarga del procesamiento de pagos. Esta es la meta para la iteración.
- Primero el equipo de desarrollo (Development Team) mira nuestra lista de requerimientos, que está actualizada y ordenada por prioridades y decide qué porción creen que pueden completar en un cuatro semanas atendiendo a la meta para esa iteración. En la segunda parte, una vez decidido el trabajo a realizar, el Development Team se encarga de analizar y desmenuzar en tareas cada uno de los requerimientos que han escogido, lo suficiente para empezar a trabajar.
- Durante cada uno de los días de trabajo, el equipo de desarrollo se reúne todas las mañanas durante 15 minutos [DAILY SCRUM] para analizar la lista de tareas y actualizar el trabajo que van completando y el que queda pendiente; los miembros del equipo informan a otros miembros de impedimentos y problemas. Juntos deciden cómo pueden resolverlos.
- Una vez que el equipo va terminando el trabajo sobre los requerimientos, los va mostrando al Product Owner para que les dé un visto bueno, y así poder continuar en el orden en que estaban inicialmente. La persona que ejerce este rol, trabaja con el equipo para informarles de la situación con respecto al producto. Todos los requerimientos terminados junto con la parte de producto hecha anteriormente se llama incremento. El objetivo de la iteración es entregar un incremente terminado que cumpla con la meta marcada.
- Al final del Sprint, el Product Owner organiza una reunión llamada Sprint Review, donde invita a Stakeholders y al equipo de desarrollo para mostrar el incremento terminado; los stakeholders dan feedback al Product Owner sobre el incremento y preguntan cualquier duda que tengan el equipo de desarrollo. Después ponen en común cual es la situación de negocio actual. Al final, se actualiza el Product Backlog con una nueva información que pudiera haber surgido.
- Después del Sprint Review, el Scrum Master que es la persona encargada de gestionar todo el proceso Scrum, organiza una Retrospectiva para todo el equipo Scrum - Product Owner + Equipo de Desarrollo + Scrum Master -, donde analizan la forma de trabajar, posibles problemas en el equipo, áreas de mejora y temas técnicos.
- La retrospectiva marca el final del Sprint e inmediatamente otro Sprint comienza, siguiendo el mismo procesos descripto arriba.