Metodología Scrum
Hola, si has llegado hasta aquí es porque estás interesado en la metodología de trabajo Scrum. Una de las metodologías más utilizadas en el desarrollo de software. A continuación resolveros todas esas dudas y conocerás los conceptos, documentos y herramientas para utilizarla.
¿Qué es Scrum?
Scrum es un marco de trabajo para desarrollo ágil de software que se ha expandido a otras industrias. 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 en el desarrollo de proyectos.
Entidades dentro de Scrum
Lidera el equipo de Scrum y mantiene a los miembros enfocados en los principios del marco de trabajo. Además, ayuda a los encargados de productos y sus organizaciones al compartir las prácticas de las metodologías Scrum.
Funciones del Scrum Máster:
- Organizar las reuniones y planificar los Sprints.
- Organizar las reuniones diarias.
- Eliminar los obstáculos en el desarrollo de software o productos.
- Realizar análisis retrospectivos.
- Ayuda a gestionar el trabajo pendiente del software o producto.
En concreto, el Product Owner procura que el equipo Scrum aporte valor al negocio en cuestión. Él representa a los stakeholders o a las partes interesadas en desarrollar el software o producto.
En la ejecución de los proyectos ágiles, el Product Owner normalmente posee las siguientes responsabilidades:
- Determinar los requisitos generales y actividades iniciales del proyecto.
- Representar a los usuarios del producto.
- Buscar y asegurar los recursos financieros que requiere el proyecto para iniciarse y desarrollarse;
- analizar la viabilidad del emprendimiento;
- garantizar que el producto se entregue;
- desarrollar y establecer los criterios para aceptar las historias de los usuarios;
- aprobar o negar los productos entregables.
El equipo se incluye al Cliente / Product Owner y al Facilitador / Scrum Máster / Development Team.
Cuando se habla específicamente de equipo de desarrollo, se refiere al conjunto de personas más técnicas que de manera conjunta desarrollan el producto del proyecto.
Tienen un objetivo común, comparten la responsabilidad del trabajo que realizan (así como de su calidad) en cada iteración y en el proyecto
Características del Development Team:
- Autónomo y multidisciplinar.
- El tamaño del equipo es de 5 a 9 personas.
- Se autogestionan y organizan
- Interaccionan con Stakeholders.
Herramientas de Scrum
Los tres principales herramientas Scrum son:
Product Backlog
Es un inventario que contiene cualquier tipo de trabajo que haya que hacer en el producto o software: requerimientos funcionales y no funcionales, casos de uso, tareas y dependencias.
Es la principal fuente de información sobre el producto en Scrum, una lista, en cualquier formato, que contiene todos los requerimientos que necesitamos implementar en el producto. Esta lista es el resultado del trabajo del Product Owner con el cliente, los distintos stakeholders, sponsors, comités, etc.
Refleja el estado real del trabajo pendiente de implementar en el producto, así como el ya realizado.
El Product Backlog debe ser gestionado en exclusiva por el Product Owner, siendo su principal función la de priorizar aquellos elementos que tienen más valor en cada etapa y detallarlos para que el equipo de desarrollo sea capaz de valorarlos y ejecutarlos.
Es recomendable empezar con los dos o tres requerimientos más urgentes arriba e ir añadiendo elementos conforme vamos descubriendo más necesidades de nuestro producto.
Un Product Backlog contiene distintos elementos:
- Funcionalidades
- Bugs
- Historias de usuario: una forma de expresar elementos de un Product Backlog. Para obtener el máximo valor de una historia de usuarios es necesario expresarlas desde el punto de vista del usuario.
- Tareas técnicas
- Trabajo de investigación
Sprint Backlog
Se trata de una lista de elementos en los que trabajar durante la etapa de Sprint. Estos elementos normalmente se componen de tareas técnicas más pequeñas que permiten conseguir un incremento de software terminado.
Todo el trabajo que el Development Team(Equipo de desarrollo) haya seleccionado para hacer durante el siguiente Sprint pasa al Sprint Backlog.
Esta herramienta es un elemento para visualizar el trabajo a realizar durante cada Sprint y está gestionado por el equipo de desarrollo. Su propósito es mantener la transparencia dentro del desarrollo, actualizándolo durante toda la iteración, especialmente a través de los daily Scrums.
El Sprint Backlog permite visualizar, durante cada Sprint, aquellos elementos que aún no han empezado a desarrollarse, aquellos que sí y quiénes están trabajando en los mismos, así como aquellos que están esperando a desplegarse o están completamente terminados.
Esta herramienta permite entender cuál es la evolución del trabajo durante el Sprint, así como hacer un análisis de riesgos.
Dado que cada Sprint tiene una meta específica.
Ejemplo:
- Permitir que los usuarios se registren en la app móvil).
- Inicio de sesión dentro de la aplicación
hay elementos seleccionados del Product Backlog que tienen más o menos valor, el Sprint Backlog permite analizar hasta donde se ha cumplido el objetivo y que se podría eliminar. De esta forma, maximizamos el retorno de la inversión en desarrollo.
Ceremonias en Scrum
El Sprint Planning es una reunión que se realiza al comienzo de cada Sprint donde participa el equipo Scrum al completo; sirve para inspeccionar el Backlog del Producto (Product Backlog) y que el equipo de desarrollo seleccione los Product Backlog Items en los que va a trabajar durante el siguiente Sprint. Estos Product Backlog Items son los que compondrán el Sprint Backlog.
Durante esta reunión, el productOwner presenta el ProductBacklog actualizado que el equipo de desarrollo se encarga de estimar, además de intentar clarificar aquellos ítems que crea necesarios.
Si bien en el Sprint Planning participa el equipo Scrum al completo, no participan los stakeholders. En el Sprint Planning se inspeccionan el Product Backlog-
El Sprint Planning se divide en dos partes. En la primera parte de la reunión se trata Qué se va a hacer en el siguiente Sprint y, en la segunda parte, se discute el Cómo. La primera parte está organizada y liderada por el product owner, mientras que de la segunda parte se encarga el Development Team. La única labor del Scrum Máster es asegurarse de que la reunión existe como parte de Scrum y que se mantiene dentro de las duraciones estimadas.
El Sprint Planning puede durar hasta 8 horas para Sprints de 4 semanas. En la práctica, esta ceremonia suele llevar una mañana completa -alrededor de 5 horas- y, solo si el producto o el Sprint definido por el Product Owner son complejos o están poco claros, se llegan a alcanzar las 8 horas definidas en la metodología. La razón del Sprint Planning es conseguir alineamiento entre negocio y desarrollo de producto en relación con las prioridades.
Conocido comúnmente solo como Daily, es una reunión diaria de 15 minutos en la que participa exclusivamente el Development Team.
En esta reunión, todas y cada una de las personas del Development Team responden a las siguientes preguntas:
- ¿Qué hice ayer para contribuir al Sprint Goal?
- ¿Qué voy a hacer hoy para contribuir al Sprint Goal?
- ¿Tengo algún impedimento que me impida entregar?
Mucha gente confunde el Daily Scrum con el Standup Meeting, sin embargo, este último es una práctica de eXtreme Programming (XP) orientada a controlar y gestionar el trabajo motivado por un manager, mientras que el primer término, Daily Scrum, hace referencia a la práctica que permite la inspección y adaptación a través de la auto-organización del equipo.
Es la reunión que ocurre al final del Sprint, generalmente el último viernes del Sprint, donde el product owner y el Develpment Team presentan a los stakeholders el incremento terminado para su inspección y adaptación correspondientes.
En esta reunión organizada por el product owner se estudia cuál es la situación y se actualiza el Product Backlog con las nuevas condiciones que puedan afectar al negocio.
La retrospectiva ocurre al final del Sprint, justo después del Sprint Review. En algunos casos y por comodidad de los equipos, se realiza conjuntamente con el Sprint Planning, siendo la retrospectiva la parte inicial de la reunión.
El objetivo de la retrospectiva es hacer de reflexión sobre el último Sprint e identificar posibles mejoras para el próximo. Aunque lo habitual es que el Scrum Master sea el facilitador, es normal que distintos miembros del equipo Scrum vayan rotando el rol de facilitador durante la retrospectiva.
Un formato común es analizar qué ha ido bien durante el Sprint, qué ha fallado y qué se puede mejorar. Este formato se puede facilitar pidiendo a los miembros del equipo Scrum que escriban notas –en post-its- para luego agruparlas y votar aquellos ítems más relevantes, dando la oportunidad a todos de hablar y expresar sus inquietudes.
También se utiliza el formato de retrospectiva basado en cinco fases:
- Preparar el ambiente: un pequeño ejercicio para romper el hielo.
- Recolectar información: durante esta fase, se utilizan actividades para intentar construir una imagen de lo que ha sido el último Sprint, resultando una imagen conjunta de equipo.
- Generación de ideas: el equipo intenta generar ideas para identificar acciones que ayuden a mejorar el rendimiento del equipo durante el siguiente Sprint.
- Decidir qué hacer: de las ideas generadas, se proponen acciones que el equipo pueda implementar en el próximo Sprint.
- Cierre: Una pequeña actividad de cierre, normalmente unida a una evaluación de la propia retrospectiva, ayuda al equipo a decidir hacia dónde dirigirse en próximas ocasiones. Un recordatorio de la mejora continua.
La duración recomendada por Scrum para un Sprint de 4 semanas es de un máximo de 3 horas, aunque habitualmente se destina entre 1 y 2 horas a este evento.
Video sobre ¿Como trabajar en un desarrollo de software con marco de trabajo Scrum?
En este camino hacia la preparación me encontré con excelentes profesores en la preparatoria, específicamente en el conalep naucalpan 1 en la carrera de informática. Ellos me dieron un voto de confianza e impulsándome a seguir con esa hambre de conocimiento, llevándome a hacer lo que más me gusta crear y programar hasta llegar a trabajar conjuntamente en proyectos importantes como lo fue el Sitio de formación continua de docentes, de igual manera partícipe en la reingeniería de la página de Escuela superior de música de la UNAM.