Guía
Esta guía fundamental es una introducción al esquema SCRUM: sus roles; artefactos y eventos juntos a través de un caso práctico.
Introducción
Guía Oficial (Español)
Teoría de Scrum
Scrum se basa en el empirismo y el pensamiento Lean. El empirismo afirma que el conocimiento proviene de la experiencia y de la toma de decisiones con base en lo observado. El pensamiento Lean reduce el desperdicio y se enfoca en lo esencial.
Scrum combina cuatro eventos formales para inspección y adaptación dentro de un evento contenedor, el Sprint. Estos eventos funcionan porque implementan los pilares empíricos de Scrum de transparencia, inspección y adaptación.
Transparencia
El proceso y el trabajo debe ser visible tanto para quienes realizan el trabajo como para quienes lo reciben, por eso se utilizar softwares como Clickup (ops) o Gitlab (ing).
Los artefactos que tienen poca transparencia pueden llevar a decisiones que disminuyan el valor y aumenten el riesgo. La transparencia permite la inspección. La inspección sin transparencia es engañosa y derrochadora.
Con Scrum, las decisiones importantes se basan en el estado percibido de sus tres artefactos formales.
Terminología
El "SCRUM Master"
Es responsable de promover y apoyar Scrum como se define en la Guía Scrum. El Scrum Master hace esto al ayudar a todos a comprender la teoría, las prácticas, las reglas y los valores de Scrum. El Scrum Master es un líder al servicio del Equipo Scrum.
El Dueño Del Producto
El Dueño del Producto es responsable de maximizar el valor del producto resultante del trabajo del Equipo de Desarrollo. La forma en que se hace esto puede variar ampliamente entre organizaciones, equipos Scrum e individuos.
El propietario del producto es la única persona responsable de gestionar la cartera de productos. La gestión de la cartera de productos incluye:
• Expresar claramente los elementos de la cartera de productos.
• Ordenar los elementos en el Product Backlog para lograr mejorar las metas y misiones.
• Optimizar el valor del trabajo que realiza el Equipo de Desarrollo.
Planificación de Sprint
La planificación no necesita más de 2 horas de reunión por 1 semana de Sprint. La reunión tiene que cumplir con los marcos de tiempo. Sprint Planning responde lo siguiente:
• ¿Qué se puede hacer este Sprint?
• ¿Cómo se hará el trabajo elegido?
El aporte a esta reunión es el Product Backlog, el último Incremento del producto, la capacidad proyectada del Equipo de Desarrollo durante el Sprint y el desempeño anterior del Equipo de Desarrollo.
Producto Backlog
Este es el trabajo que se deja en la columna de "Planeación" o de "Open".
SCRUM para Operaciones/Directores
El seguimiento del Producto Backlog de operaciones/directores se realiza en Clickup. Allí se encontrará una serie de columnas: Idea, Under Review, Planned, Sprint, In progress, Review and Done.
Cada trabajo del Producto Backlog se genera individualmente en lo que se conoce como issue, este se agenda en la columna Idea, y a medida que se acerca el Weekly Sprint, el issue se mueve de columna a columna hasta finalmente ser asignado en Sprint, donde será adjudicado al empleado encargado de terminarlo con un número de horas determinado para completar en la semana.
Cada empleado debe obtener un máximo de 40 hrs de trabajo combinado en cada Sprint.
El estimado de horas por issue se escribe en el título descriptivo de cada trabajo. Este debe seguir la siguiente sintaxis: n hrs - "Título" .
Last updated
