Visión general de Scrum

Visión general de Scrum

En Scrum, el gerente de proyecto se llama Scrum Master, y el equipo de proyecto se llama Equipo Scrum. Existe un Propietario del Producto que prioriza las características y requisitos que se deben desarrollar en el Backlog del Producto.

La metodología Scrum utiliza Sprints para entregar pequeños incrementos de trabajo y recopilar retroalimentación de los clientes.

Existen tres (3) pilares de Scrum:

SCRUMemplea un enfoque empírico (a veces llamado empirismo) para adaptarse a las necesidades cambiantes de los clientes. El empirismo es la práctica de tomar decisiones basadas en la experiencia real. Un enfoque empírico significa trabajar de manera basada en hechos, experiencia y evidencia—especialmente cuando el progreso se basa en la observación de la realidad en lugar de en planes elaborados de antemano basados en requisitos iniciales extensos.

En resumen, aprendemos y mejoramos a partir de errores y experiencias pasadas. Los tres pilares de Scrum que apoyan el control del proceso empírico en cada implementación son: Transparencia, Inspección y Adaptación, como se muestra en el diagrama a continuación:

The Three Pillars of Scrum

  • Transparencia — Un lenguaje común y estándares para garantizar consistencia y comprensión compartida.
  • Inspección — Revisión frecuente del progreso y entregables de Scrum para obtener retroalimentación. Es importante no ocultar el progreso del proyecto.
  • Adaptación — Incorporar fácilmente la retroalimentación recibida y abordar los problemas cuando surgen.

Componentes del proceso Scrum

El marco Scrumen sí mismo es muy sencillo. Define solo unas pocas directrices generales, junto con un pequeño conjunto de reglas, roles, artefactos, y eventos. Sin embargo, cada uno de estos componentes es importante, cumple una función específica y es fundamental para utilizar con éxito el marco.

Los componentes principales del marco Scrum son:

El diagrama siguiente ilustra los elementos clave del marco SCRUM. Este proceso se ha implementado en el Herramienta de software ágil — Cuadro de proceso Scrum.

Scrum Framework
Marco Scrum

Roles de Scrum

Cuando una organización decide adoptar Scrum, una de las primeras cosas que debe entender es cómo los roles de Scrum difieren de los roles tradicionales de ejecución de proyectos. Aunque Scrum tiene solo tres roles principales, no se alinean automáticamente con los títulos con los que la mayoría de nosotros estamos familiarizados. Comencemos con una breve definición de cada uno:

Propietario del producto

El Propietario del producto es el rol de Scrum responsable de representar a la comunidad empresarial o de usuarios y trabajar con grupos de usuarios para determinar qué características se incluirán en las versiones del producto. Las responsabilidades principales del Propietario del producto son:

  • Establecer la dirección y la estrategia para el producto o servicio, incluyendo objetivos a corto y largo plazo;
  • Proporcionar o obtener conocimientos sobre el producto o servicio;
  • Ayudar al equipo de desarrollo a comprender e interpretar las necesidades del cliente;
  • Recopilar, priorizar y gestionar los requisitos para el producto o servicio;
  • Asumir la responsabilidad de cualquier tarea relacionada con el presupuesto del producto o servicio, incluida su rentabilidad;
  • Determinar las fechas de lanzamiento para las características del producto o servicio;
  • Responder preguntas y tomar decisiones diariamente con el equipo de desarrollo;
  • Aceptar o rechazar las características completadas relacionadas con el Sprint;
  • Demostrar los entregables clave del equipo de desarrollo al final de cada Sprint;
  • Ser responsable del Product Backlog.

Scrum Master

El Scrum Master es el facilitador del equipo de desarrollo ágil. Scrum es un método que permite a los equipos organizarse de forma autónoma y realizar cambios rápidos según los principios ágiles. El Scrum Master gestiona el proceso de intercambio de información. Las responsabilidades principales del Scrum Master son:

  • Actuar como coach para ayudar al equipo a seguir los valores y prácticas de Scrum;
  • Ayudar a eliminar obstáculos y proteger al equipo de la interferencia externa;
  • Facilitar una buena colaboración entre el equipo y los interesados;
  • Promover el sentido común dentro del equipo;
  • Proteger al equipo de la interferencia organizacional.

Equipo Scrum

El Equipo Scrum (también conocido como el Equipo de Desarrollo) está compuesto por 3 a 9 personas que poseen colectivamente todas las habilidades técnicas necesarias para entregar el producto o servicio. Son guiados directamente por el Scrum Master, pero no son gestionados directamente. Deben ser autogestionados, versátiles y suficientemente responsables para completar todas las tareas requeridas.

El Equipo de Desarrollo es responsable de entregar incrementos de producto potencialmente entregables en cada Sprint, desde el análisis, diseño, desarrollo, pruebas hasta la redacción técnica. Las características clave del Equipo Scrum incluyen:

  • El equipo debe ser autogestionado. Todos los miembros del equipo deben gestionar sus propios esfuerzos para completar las tareas asignadas. En Scrum ágil, no existe una figura de líder de equipo ni de gerente directo. Todos deben estar comprometidos lo suficiente como para llevar a cabo sus actividades y contribuir al éxito del equipo. Si uno falla, todos fallan.
  • El equipo debe ser multidisciplinario. Todos los miembros del equipo deben poseer el conocimiento y las habilidades necesarias para entregar un servicio o producto completo y listo para usar. Los expertos pueden utilizarse cuando sea necesario, pero únicamente como coaches para transferir conocimientos al equipo y cubrir brechas específicas.
  • El Propietario del Producto requiere una visión empresarial. El Propietario del Producto representa la voz del cliente y debe transmitir sus necesidades al Scrum Master y al Equipo de Desarrollo. Este es típicamente un rol de tiempo completo.
  • El Scrum Master no es un gerente directo. Proporcionan el coaching necesario para el Equipo de Desarrollo y ayudan a eliminar cualquier obstáculo que el equipo enfrenta.

Backlog del Producto

Esta es una lista ordenada de todo el trabajo que debe realizarse en el proyecto. Se presenta en forma de historias, comúnmente llamadas historias de usuario.

Historias de Usuario — Diferentes representaciones de cómo los usuarios interactúan con los entregables del proyecto (producto, servicio u resultado). A través de las historias de usuario, el equipo identifica las características y funcionalidades necesarias para los entregables.

Por lo tanto, el Backlog del Producto contiene historias de usuario priorizadas (características y funcionalidades) para el producto/servicio/resultado. El Propietario del Producto es responsable de priorizar el backlog.

Nota: No es necesario crear todas las historias para todo el proyecto antes de comenzar el trabajo (esta es una de las ventajas del enfoque ágil). Comience con las historias que conoce, y a medida que aprenda más, agregue al backlog y reordene según sea necesario.

Planificación del Sprint

A diferencia del enfoque en cascada, los equipos ágiles no planifican todo de antemano. Aquí, el equipo planifica un poco: lo que se necesita para el Sprint actual (los Sprints suelen durar de 2 a 4 semanas), lo entrega, aprende de ello y vuelve a planificar el siguiente Sprint.

El equipo Scrum revisa el Product Backlog y selecciona el número de historias de usuario que puede completar dentro del tiempo del Sprint. Las historias de usuario seleccionadas se convierten en el Sprint Backlog. El Sprint Backlog representa el objetivo del Sprint.

También se establece la Definición de Terminado. La Definición de Terminado puede considerarse como los criterios de aceptación para los elementos del backlog.

Planifique únicamente el trabajo que se ajuste a la capacidad del equipo, es decir, el trabajo que el equipo pueda completar de manera realista en cada Sprint.

Reunión Diaria de Scrum (Reunión de Pie Diaria)

El equipo utiliza esta reunión para hacer compromisos micro a otros, identificar problemas y asegurar que el trabajo del Sprint fluya sin problemas dentro del equipo. Suele durar 15 minutos. El equipo responde las siguientes preguntas:

  • ¿Qué completé desde la última reunión de Scrum?
  • ¿Cuál es mi plan para hoy? ¿Qué tengo intención de completar entre ahora y la próxima reunión de Scrum?
  • ¿Hay algún impedimento (problemas, cuestiones o riesgos) que me esté bloqueando?

Recuerde que esta reunión no es una reunión de estado: no es para resolver problemas, sino para tomar conciencia de ellos (si los hay). Si se necesita una reunión para resolver cuestiones, realice una reunión separada.

Reunión de Revisión del Sprint

Al final de cada Sprint, el equipo demuestra todos los elementos de trabajo completados. Esta reunión de revisión se utiliza para recibir retroalimentación de los interesados del proyecto y cualquier solicitud de cambio.

Es importante tener en cuenta que los elementos de trabajo que no estén al 100% completos según la Definición de Terminado establecida durante la planificación no se demostrarán, ya que no están “terminados”.

Reunión de Retrospectiva del Sprint

Esta reunión tiene lugar después de la Revisión del Sprint. El propósito es ayudar al equipo a aprender del Sprint. El proceso se centra en la mejora continua en lugar de culpar al equipo si las cosas no salieron bien durante el Sprint.

El equipo reflexiona sobre cómo volverse más eficaz e identifica otras áreas de mejora.

El Scrum Master clasifica la importancia de cada elemento de mejora, y luego el equipo selecciona un número adecuado de elementos de mejora para implementar en el siguienteSprint.

Dejar una contestacion