[SCRUM] Aprendiendo SCRUM

Todo cambia, de eso no se escapa la gestión de proyectos. Pasamos de un enfoque tradicional a un enfoque “ágil”, hablamos de SCRUM.

Scrum es uno de los marcos ágiles de trabajo más populares. Es un framework adaptable, iterativo, rápido, flexible y eficaz, diseñado para ofrecer un valor considerable en forma rápida a lo largo del proyecto. Debe quedar claro que SCRUM no es una metodología. Además se basa en en los principios del Manifiesto Ágil:

El framework de la Guía SBOK™ (SCRUM BODY OF KNOWLEDGE) está formado por 3 partes: Principios, Aspectos y Procesos

Scrum puede aplicarse en forma efectiva a cualquier proyecto en cualquier industria, desde proyectos pequeños o equipos con tan solo seis miembros, hasta proyectos grandes y complejos con varios cientos de integrantes.

Este post no pretende replicar la guía oficial SCRUM, sino mencionar los principios que rigen SCRUM, sus aspectos y sus procesos. Luego de ello, comentaré mi experiencia en la clase donde aprendí SCRUM de forma práctica e innovadora pues se hizo uso de LEGO® Serious Play® y puedo confirmar que mediante esta técnica conseguí entender e interiorizar la teoría impartida al inicio de clase.

¿Listos? Ahí vamos

Los 6 Principios de Scrum

Los principios de Scrum son las pautas básicas para aplicar el framework de Scrum y deben implementarse en forma obligatoria en todos los proyectos Scrum. No están abiertos a discusión, ni pueden modificarse. Estos principios infunden confianza

  1. Control del proceso empírico (Empirical Process Control). Aprendemos con la práctica tres ideas principales de transparencia, inspección y adaptación.
  2. Auto organización (self organization) – ¿para qué estamos haciendo este proyecto? Para motivarnos. Buscar trabajo proactivamente, hacer el trabajo por sí mismo, comprender la visión del proyecto.
  3. Colaboración (collaboration) – co ubicación. Integrar las partes de nuestro eqipo. conocimiento, articulación y apropiación.
  4. Priorización basada en valor. ofrecer el máximo valor de negocio
  5. Time boxing. ¿en qué momento se hace revisión? Cuando el product owner lo solicite, teóricamente al final del sprint. 
    • Daily standup meeting – 15min
    • Sprint Planning Meeting – 8 horas para un Sprint de un mes
    • Sprint – 1 a 6 semanas
    • Retrospect Sprint Meeting – 4 horas para un sprint de un mes
    • Sprint review – 4 horas para un sprint d un mes
  6. Desarrollo iterativo. El marco tradicional usa cascada. Enfasis en cómo gestionar mejor los cambios y crear productos que satisfagan las necesidades del cliente.

Los 5 Aspectos de Scrum

  1. Organización. Existe un grupo denominado “Roles Centrales” formado por las personas completamente comprometidas con el proyecto y por tanto responsables del éxito de cada iteración. El otro grupo, “Roles no Centrales” formado por los stakeholders (clientes, usuarios y patrocinadores. Lo más importante es que el proyecto produzca beneficios colaborativos para elos). Detallaremos los “Roles Centrales”:
    • Product Owner: Tiene como responsabilidad lograr máximo valor empresarial para el proyecto, gestionar los requisitos del cliente y mantener la justificación del negocio para el proyecto. Es la voz del cliente.
    • Scrum Master: Es el facilitador y asegura que el Equipo Scrum cuente con un ambiente propicio para completar el proyecto con éxito. Guía, facilita y enseña las prácticas de Scrum a todos. Elimina los impedimentos del equipo.
    • Equipo Scrum: Responsables de entender los requisitos especificados por el Product Owner y de crear los entregables del proyecto. Orientado a objetivos.
  2. Justificación del Negocio. Se basa en el concepto de entrega impulsada por el valor (Value Driven Delivery). Scrum busca iniciar la entrega de resultados lo antes posible en el proyecto. Esta entrega temprana de resultados, y por lo tanto de valor, proporciona una oportunidad para la reinversión y demuestra el valor del proyecto a los stakeholders.
  3. Calidad. Se define como la capacidad con la que cuenta el producto o los entregables para cumplir con los criterios de aceptación y de alcanzar el valor de negocio que el cliente espera. Debido a que Scrum requiere que el trabajo se realice en incrementos durante los sprints, esto hace que los errores o defectos se noten con más facilidad mediante pruebas de calidad repetitivas y no simplemente cuando el producto final o servicio esté casi terminado. Esto asegura que la brecha entre las expectativas de los clientes del proyecto y los verdaderos entregables se reduzca constantemente.
  4. Cambio. Los proyectos Scrum aceptan los cambios mediante el uso de sprints breves e iterativos que incorporan la retroalimentación del cliente en cada entregable del sprint. Esto permite que el cliente interactúe regularmente con los miembros del Equipo Scrum, que vea los entregables a medida que estén listos y que cambie los requisitos si es necesario antes del siguiente sprint.
  5. Riesgo. Se define como un evento incierto o serie de eventos que pueden afectar los objetivos de un proyecto y pueden contribuir a su éxito o fracaso. Los riesgos deben ser identificados, evaluados y atendidos con base a dos factores: la probabilidad de ocurrencia de cada riesgo y el posible impacto en el caso de tal ocurrencia.

Los Procesos de SCRUM

La imagen a seguir muestra el ciclo de vida de un proyecto SCRUM. Para dar inicio a nuestro proyecto SCRUM, deberemos seguir 19 procesos agrupados en 5 fases.

La mejor manera de entender estos procesos es actuando! Así que aquí va mi experiencia práctica durante el curso que seguí en GESAP, lo recomiendo :).

Caso Práctico:

 

“El proveedor X ofrece carnes y vegetales al supermercado Y. Se desea optimizar el proceso de envío de carnes y vegetales a dicho supermercado”. Deberá definir los elementos que Ud considere necesario para resolver dicha problemática.

 

Primero, formamos nuestro equipo de trabajo (sin roles aún). Luego nos entregaron una caja llena de “lego”, a mí y a mi equipo nos sorprendió mucho eso, luego recordé que hay una metodología llamada Lego Serius Play que permite de una forma lúdica generar innovación y conocimiento:

“You can learn more about a person in an hour of play than you can from a lifetime of conversation”
Plato

El profesor indicó que cada pieza de lego representaba un $ asignado al proyecto, por tanto deberíamos utilizar todas las piezas pues “que sobren o falten piezas” significaba que no se hizo la estimación correcta del presupuesto.

Fase 1: INICIO

  • Crear la visión del proyecto: Se explicó la necesidad del caso práctico que consistió en la Optimización del proceso de envío de las carnes y vegetales al supermercado con el fin de que lleguen los productos de forma rápida, segura y sin dañarse. No se detalló el cómo, simplemente el qué. Además definimos quién sería nuestro Product Owner según sus skills (habilidades de negociación y comunicación)
  • Identificar al Scrum Master y stakeholder(s): Yo fui la Scrum Master (habilidades de motivador y líder servicial), el stakeholder en este caso fue el profesor que fungía como el cliente.
  • Formar el Equipo Scrum: Formado por los demás compañeros restantes.
  • Desarrollar Épicas: Las épicas son historias de usuarios (éstas describen funcionalidades desde el punto de vista de los usuarios) a alto nivel. Para este proyecto, definimos, por ejemplo, las sgts épicas: “Criar animales”, “Cultivar plantas”, “Cosechar plantas”, “Construir almacén de carne”, “Construir almacén de verduras”, “Gestionar envío”, “Transportar alimentos”, “Construir supermercado”, “Construir almacenes del supermercado”, “Diseñar sección de carnes del supermercado”, “Diseñar sección de verduras”, “Construir estacionamientos de clientes”, etc.
  • Crear el Product Backlog Priorizado: Que es la lista priorizada de los requerimientos del negocio y de los proyectos escritos en forma de épica(s). La priorización depende de valor, riesgo y dependencias. Nosotros priorizamos según la dependencia. Las épicas iniciales del Product Backlog fueron aquellas realizadas en el campo, las intermedias referentes al transporte y las finales aquellas correspondientes al supermercado.
  • Realizar la planificación del lanzamiento: El Equipo principal Scrum revisa el Product Backlog Priorizado para desarrollar el cronograma de planificación del lanzamiento.. duración dl sprint)

Fase 2: PLANIFICACIÓN Y ESTIMACIÓN

  • Crear historias de usuario. Estas historias más pequeñas son generalmente funcionalidades simples, cortas y fáciles de implementar, o bloques de tareas que deben completarse en un sprint. Un ejemplo para nuestro caso fue
    • Historia: “Cultivar plantas”
      • Como: Agricultor
      • Quiero: Cultivar las verduras X,Y y Z
      • Para: Poder vender verduras al supermercado
  • Estimar historias de usuario. El Equipo Scrum estima el esfuerzo necesario para desarrollar la funcionalidad descrita en cada historia de usuario
  • Comprometer historias de usuario. Cada miembro del Equipo Scrum de forma voluntaria eligió cuales historias se comprometía a realizar.
  • Identificar tareas. Las historias de usuario fueron desglosadas en tareas específicas y nuestro Product Owner se encargó de registrarla en una lista de tareas.
  • Estimar tareas.
  • Crear el sprint backlog. Nuestro Equipo principal de Scrum elaboró un Sprint Backlog que contiene todas las tareas a ser completadas en un sprint como parte de la Reunión de Planificación del Sprint

Fase 3: IMPLEMENTACIÓN

  1. Crear entregables –  Esta etapa fue la de “Manos a la Obra” o mejor dicho “¡Manos a los legos!”. El seguimiento de las actividades se realizó usando un Scrumboard (ver imagen: Pendiente, En Proceso, Terminado). 
  2. Realizar daily standup – Es aquí donde los miembros del Equipo Scrum se actualizan el uno al otro referente a sus progresos y sobre los impedimentos que pudieran enfrentar.
  3. Refinar el backlog priorizado del producto – Se actualizó el estado de cada historia de usuario.

Fase 4: REVISIÓN Y RETROSPECTIVA

  1. Demostrar y validar el sprint – el Equipo Scrum muestra los entregables del sprint al Product Owner y a los stakeholders relevantes en una Reunión de Revisión del Sprint. El profesor del curso revisaba nuestros avances y nos hacía sugerencias.
  2. Retrospectiva del sprint – En este proceso, el Scrum Master y el Equipo Scrum se reúnen para analizar las lecciones aprendidas durante todo el Sprint. Por ejemplo, en nuestro primero sprint, nos dimos cuenta que para optimizar nuestro proceso de creación de entregables: “deberíamos seleccionar las piezas de lego por tamaño y/o color para así armar con más rapidez”

Fase 5: LANZAMIENTO

  1. Enviar entregables – Un documento denominado Working Deliverables Agreement (Acuerdo de entregables funcionales) documenta la conclusión satisfactoria del sprint.
  2. Retrospectiva del proyecto – —En este proceso, mismo que concluye el proyecto, los stakeholders y miembros del equipo principal de Scrum se reúnen para hacer una retrospectiva del proyecto e identificar, documentar e internalizar las lecciones aprendidas.

Observación: Como Scrum sigue una modalidad iterativa, las fases de “Planificación y Estimación”, “Implementación”, “Revisión y Retrospectiva”, “Lanzamiento” se realiza por cada Sprint.

Fue una gran experiencia de aprendizaje de Scrum! :), un gran Equipo de Trabajo. Cualquier observación, comentario, corrección, etc, no duden en comentar este artículo!

Fuente: CUERPO DE CONOCIMIENTO DE SCRUM (GUÍA SBOK™)
Puntuación: 5 / Votos: 7