Scrum Master en 5 minutos

Inicio de de la Metodología Ágil

Descubramos Scrum Master en 5 minutos, sus comienzos se remontan a un artículo de 1986 en la revista de la Harvard Business Review, Titulado: “The New Product Development Game” / “El nuevo juego para el desarrollo de productos” de Hirotaka Takeuchi y Ikujiro Nonaka.

Scrum no es un acrónimo, es una expresión proveniente del Rugby, que hace referencia a la forma en cómo se reinicia el juego después de una falta o cuando la pelota se ha ido fuera del juego.

En el año 1993 en Easel Corporation, Jeff Sutherland y su equipo crearon el proceso de Scrum para ser empleado en los procesos de creación de software integrando los conceptos del artículo de 1986 con los conceptos del desarrollo dirigido a objetos, desarrollo iterativo e incremental, control de procesos empírico,  procesos de software y mejora de la productividad, tanto 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 como lo son: HP, Fuji, Epson, entre otras.

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.

En la parte final del artículo, los autores establecen una comparación con el juego de Rugby, ya que en la fase de melé (scrum) se presentas estas mismas características, con el propósito de llevar el balón (objetivos) a la meta, y de esta manera definen por vez primera la estrategia de producto como holística y flexible.

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

¿Qué es Scrum Master en 5 minutos? Se trata de un proceso por medio del cual se aplican regularmente un conjunto de buenas prácticas para trabajar en colaboración, en equipo, y alcanzar así el mejor resultado posible de un proyecto.

Esto quire decir que el proceso está compuesto por diferentes iteraciones que se llaman 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 de la Metodología Ágil

Primeramente nos encontramos a los interesados o Stakeholders, que son las  personas para las que construimos el producto.

Como ejemplo, si estuviéramos elaborando una aplicación para un hotel, los interesados podrían ser desde el Director hasta los recepcionistas, camareras de planta y finalmente 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.

Posteriormente definidos 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, por sus siglas en inglés, o Elementos de la Pila de Producto).

Por otro lado definamos 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.

También es indispensable el “Scrum Master” que es la persona que garantiza el seguimiento de la metodología liderando las reuniones y apoyando al equipo ante cualquier problema que pueda surgir.

Definiendo Scrum Master en 5 minutos 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
  • Auto-organizado.
Imagen blog

Iniciemos a trabajar con este Marco de Trabajo

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:

Ya que hemos iniciado el sprint, es importante fomentar la comunicación y sincronización entre todos los miembros del equipo, así como detectar tempranamente los posibles problemas que van apareciendo y trabajar en 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.

En esta reunión participa el Dueño de Producto como representante de los Interesados, aparte del Equipo de Construcción y el Scrum Master.

Reunión de Retrospectiva 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, principalmente entre el Product Owner y el Equipo de Desarrollo en donde se establecen los criterios por las cuales un PBI está listo para entrar a Sprint.

Lo más importante es que 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), que hace refencia a una lista de acciones que deben completarse para dar por finalizada una tarea y/o PBI.

Scrum Master en 5 minutos

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.

Te hemos resumido Scrum Master en 5 minutos y 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.

Para acceder a la Certificación Professional Scrum Master

Te notificamos que G-Talent ha sido seleccionado como Partner de Certiprof por lo cuál puedes acceder a las diversas Certificaciones Scrum con un fabuloso descuento ingresando al siguiente enlace: Certificaciones Scrum

Te recomendamos leer:

Comments

  • Excelente información y resumen de SCRUM