Scrum Master en 5 minutos

Inicio de Scrum

Scrum se inicia desde 1986 en un artículo en la revista de la Harvard Business Review, Titulado titulado: “The New New Product Development Game” / “El nuevo juego para el desarrollo de productos” por Hirotaka Takeuchi y Ikujiro Nonaka. Scrum no es un acrónimo, sino un término extraído del Rugby, que se refiere a la manera en cómo se reinicia el juego luego de una falta o cuando la bola se ha ido fuera del juego.

En 1993, Jeff Sutherland y su equipo en Easel Corporation crearon el proceso de Scrum para ser utilizado en los procesos de desarrollo de software combinando los conceptos del artículo de 1986 con los conceptos del desarrollo orientado a objetos, un control de procesos empírico, desarrollo iterativo e incremental, procesos de software y mejora de la productividad, así como el desarrollo de sistemas complejos y dinámicos.

El artículo, es el resultado del estudio de los sistemas de producción de algunas de las principales empresas de manufactura en los años 80: HP, Fuji o Epson entre otras, y de las que, analizados sus procesos, se encontraron seis puntos de coincidencia:

  1. La responsabilidad recae en el equipo.
  2. Los equipos se auto organizan.
  3. Las fases de desarrollo se solapan entre sí.
  4. El equipo es de carácter multidisciplinar.
  5. Hay un control sutil destinado a la selección del personal y puntos de control.
  6. Existe una transferencia de conocimiento entre equipos distintos.

Los autores , al finalizar el artículo, realizan una analogía con el juego de Rugby, donde en la fase de melé (scrum) se dan estas mismas características, con la finalidad de llevar el balón (objetivos) a la meta, y con ella definen por primera vez la estrategia de producto como flexible y holística.

Ahora si, una introducción rápida al marco de trabajo

¿Que es Scrum? es un proceso en el que se aplican de manera regular un conjunto de buenas prácticas para trabajar colaborativamente, en equipo, y obtener el mejor resultado posible de un proyecto. Esto significa que el proceso se compone de diferentes iteraciones que se denominan Sprints o carrera continua.

Los sprints tienen un tiempo establecido (entre 1 y 4 semanas máximo, es lo recomendado) y su objetivo, es el de construir un producto (o un incremento de producto) que pueda ser utilizado por los clientes.

Definiendo Roles y otros aspectos

Primeramente nos encontramos a los interesados o Stakeholders, que son las  personas para las que construimos el producto (Por ejemplo, si estuviéramos construyendo una aplicación para un hotel, los interesados podrían ir desde el Director, a los recepcionistas, camareras de planta…hasta llegara los clientes, todos aquellos a los que, de algún modo, les afecte directa o indirectamente en su trabajo la construcción de la app).

Luego de definido a nuestros stakeholders, debemos recopilar las ideas, funcionalidades y demás elementos que van a componer nuestro producto y que parten de las ideas y problemas de estos

A estos elementos ordenados por el valor de negocio que tienen, se le llama Pila de Producto o Product Backlog, y a los distintos componentes de la misma PBIs (Product Backlog Items o Elementos de la Pila de Producto).

Definimos Dueño del Producto o Product Owner, a la persona encargada de gestionar la comunicación y el Product Backlog, y su objetivo es realizar la entrega de valor en cada Sprint, es decir, asegurar que el equipo de trabajo construya lo que le aporte más valor a los Interesados.

Es fundamental el “Scrum Master” la persona que asegura el seguimiento de la metodología guiando las reuniones y ayudando al equipo ante cualquier problema que pueda aparecer.

No podía faltar definir el Equipo de Desarrollo o Development Team, encargado de las labores reales de construcción del producto, los encargados de entregar los incrementos de producto en cada Sprint. Este equipo tendrá como características básicas: ser de reducido tamaño, multidisciplinar y auto-organizado.

Iniciemos a trabajar

Reunión de Planificación del Sprint o Sprint Planning: Comenzamos nuestro trabajo seleccionando los PBIs más importantes, y los desgranamos para trabajar sobre ellos en tareas técnicas. En esta reunión estarán presentes el Product Owner, el Development Tem y el Scrum Master y el resultado de la misma debería ser una Pila del Sprint (lista de tareas para este iteración) junto con los objetivos claros del mismo.

Reunión diaria o Daily Meeting: Una vez que hemos comenzado el sprint, es necesario fomentar la comunicación y sincronización entre los miembros del equipo, así como detectar de forma temprana los posibles problemas que van surgiendo y trabajar sobre ellos. Esta reunión de no más de 15 minutos tiene lugar a primera hora de la mañana.

Reunión de Revisión o Demo: Tiene lugar al finalizar el sprint, es necesario revisar todo lo construido, ver si se ajusta a lo que necesitan los stakeholders y poder recibir feedback de los mismos. A esta reunión acuden el Dueño de Producto como representante de los Interesados, además del Equipo de Construcción y el Scrum Master.

Reunión de Restrospectiva o Retrospective Sprint: en esta el foco está en las personas y el proceso dejando a un lado el producto en sí. A esta reunión deben acudir todos los miembros del Equipo Scrum, procurando que sea conducida no por por el Scrum Máster si no por otra persona neutral, para que participe como un miembro más del equipo.

Reunión de Refinamiento o Refinement Meeting: es la última reunión, cuyo objetivo es trabajar sobre los elementos futuros que entrarán en el Sprint, es decir, trabajar sobre los siguientes elementos de la Pila de Producto.

Definiciones para el trabajo

Para asegurarnos que durante el Sprint se bloquea el menor número de elementos, contamos con la Definición de Listo (Ready o DoR) es un acuerdo entre el equipo de trabajo, especialmente entre el Product Owner y el Equipo de Desarrollo donde se colocan los criterios por las cuales un PBI se encuentra listo para entrar a Sprint. Nos evitará desperdicios al elegir una parte del producto que pueda bloquearse, y por tanto alterar el objetivo, por causas ajenas al mismo, en mitad de la iteración.

Por último, para asegurarnos que se terminan todas las tareas y PBIs de cada Sprint con calidad suficiente contamos con el concepto de Definición de Terminado (Done o DoD), entendido como una lista de acciones que deben cumplirse para dar por terminada una tarea y/o PBI.

En resumen les dejo a continuación los doce principios del desarrollo ágil:

  1. Nuestra principal prioridad es satisfacer al cliente a través de la entrega temprana y continua de software que aporte valor.
  2. Aceptamos de buen grado cambios en los requisitos, incluso si llegan tarde al desarrollo. Los procesos ágiles aprovechan el cambio para la ventaja competitiva del cliente.
  3. Entregar con frecuencia software que funcione, desde un par de semanas hasta un par de meses, con preferencia a la escala de tiempo más corta.
  4. La gente de negocio y los desarrolladores deben trabajar juntos de forma cotidiana durante todo el proyecto.
  5. Construir proyectos en torno a individuos motivados. Darles el entorno y el apoyo que necesitan y confiar en que ellos conseguirán hacer el trabajo.
  6. El método más eficiente y efectivo de comunicar información a y dentro de un equipo de desarrollo es la conversación cara a cara.
  7. El software que funciona es la principal medida de progreso.
  8. Los procesos ágiles promueven el desarrollo sostenido. Los promotores, desarrolladores y usuarios deben ser capaces de mantener un ritmo constante de forma indefinida.
  9. La atención continua a la excelencia técnica y al buen diseño mejora la agilidad.
  10. La simplicidad, el arte de maximizar la cantidad de trabajo que no se hace, es esencial.
  11. Las mejores arquitecturas, requisitos y diseños emergen de equipos autoorganizados.
  12. En intervalos regulares, el equipo reflexiona en cómo ser más efectivo, se afina y ajusta su comportamiento de acuerdo con esto.

Ya conoces la importancia de la aplicación de metodologías ágiles para lidera proyectos, por lo cual prepararte como Scrum Master te dará muchas herramientas y obtendrás las posiciones laborales que deseas en el marco de la gerencia de proyectos.

Por estas razones es casi inevitable que te certifiques como Scrum Master.

Si deseas convertirte en un líder Ágil y Certifícate como Scrum Master, apúntate ya a nuestro curso Scrum Master ¡HOY en promoción! ¡comienza ya!

Scrum Master

¡Regístrate Ahora!

Comments