Roles de Scrum en el desarrollo de software explicados en términos claros y simples

Scrum es una metodología ágil de desarrollo de software que ahora está siendo adoptada por muchas empresas y corporaciones como parte de las iniciativas de transformación digital.

Acerca de Scrum

El papel de la metodología Scrum es proporcionar un marco para el desarrollo de software Agile que permita a los equipos trabajar de forma colaborativa y eficiente para ofrecer productos de software de alta calidad.

Es un marco para que los equipos trabajen juntos para desarrollar productos complejos. En lugar de lanzar un producto después de largas fases de planificación, diseño, desarrollo y prueba, Scrum tiene como objetivo entregar productos listos para usar desde el principio en pequeños incrementos.

Los principios fundamentales de Scrum son la comunicación transparente del equipo, la verificación periódica de la calidad y la capacidad de adaptarse al cambio. Si se adoptan y utilizan de la manera correcta, los equipos pueden entregar productos de software de alta calidad de manera oportuna y eficiente.

Beneficios clave de Scrum

Fuente: scrum.org

  • Puede lograr una mayor productividad. Ser un equipo Scrum significa que el equipo está descomponiendo problemas complejos en partes pequeñas. Luego, esas piezas pequeñas se entregan dentro de los sprints como incrementos de sprint. Los miembros del equipo pueden concentrarse en tareas específicas dentro de un Sprint (período de tiempo definido en el que se desarrollan los incrementos, por ejemplo, dos semanas).
  • Scrum fomenta la comunicación regular entre todo el equipo. Esto entonces asegura que todos tengan claro el alcance y las expectativas. Reduce una cantidad bastante significativa de malentendidos que de otro modo podrían ocurrir. Especialmente si quieres avanzar con un ritmo alto de sprint a sprint, todo el equipo debe trabajar hacia el mismo objetivo día a día.
  • Scrum está diseñado para ser flexible, de modo que los equipos puedan adaptarse a los requisitos y prioridades cambiantes. Esto permite que los equipos respondan rápidamente a los cambios en el alcance del proyecto o las necesidades del cliente. En lugar de esperar hasta que termine todo el ciclo de vida del desarrollo, puede simplemente cambiar el contenido entre los sprints.
  • Scrum enfatiza la importancia de las pruebas y la garantía de calidad, idealmente de forma automatizada. El objetivo final es aumentar la calidad del producto final. Esto reduce el riesgo de defectos y asegura que el producto cumpla con los requisitos del cliente.
  • Scrum está diseñado para centrarse en el cliente, lo que significa que el cliente está involucrado en el proceso de desarrollo de principio a fin, generalmente en el rol de propietario del producto o con una conexión directa con el propietario del producto (más sobre esto más adelante). Esto asegura que el producto final satisfaga las necesidades del cliente y con la prioridad correcta.

A continuación, discutiremos el papel de la metodología scrum.

Rol de la Metodología Scrum

Fuente: hangoutagile.com

El objetivo de la metodología Scrum es proporcionar un marco para el desarrollo de software Agile que permita a los equipos trabajar en colaboración. Usted construye un equipo Scrum que se reúne diariamente y regularmente y tiene discusiones programadas (ceremonias) dentro de un sprint que se repite cada sprint. Por lo general, las siguientes ceremonias son parte de la configuración básica de un equipo scrum:

  • Standups diarios: una hora y un lugar donde todos los miembros del equipo se reunirán y discutirán lo que se hizo el último día, cuál será el trabajo del día siguiente y cuáles son los obstáculos actuales, si los hay.
  • Refinamiento de historias: aquí es donde se discute y finaliza el nuevo contenido (para los próximos sprints).
  • Planificación de Sprint: durante esta ceremonia, el equipo estima el contenido listo para usar (definido en Historias) y luego se compromete con un subconjunto específico de ellos, principalmente en función de las estimaciones de prioridad y esfuerzo.
  • Revisión de Sprint: aquí, el equipo se reúne con las partes interesadas y les presenta lo que logró el equipo en el último Sprint.
  • Retrospectiva de Sprint: un diálogo dedicado al equipo solo para discutir qué se puede mejorar o qué siente el equipo que se debe cambiar en el futuro.

La importancia de la metodología Scrum radica en su capacidad para ayudar a los equipos a trabajar de manera más efectiva. Los principios básicos de la metodología Scrum se basan en el Manifiesto Ágil y son los siguientes.

Control empírico de procesos

Scrum se basa en la idea de que el progreso se logra mejor a través de un proceso empírico de inspección y adaptación continuas. Esto significa que los equipos deben inspeccionar periódicamente su trabajo y adaptar sus procesos para mejorar su desempeño.

Equipos autoorganizados

Los equipos Scrum se autoorganizan, lo que significa que son responsables de administrar su trabajo y tomar decisiones sobre el logro de sus objetivos. Esto ayuda a promover la colaboración y la responsabilidad dentro del equipo.

Iteraciones en caja de tiempo

Puede dividir los proyectos de scrum en iteraciones de tiempo limitado, llamadas sprints, que suelen durar entre una y cuatro semanas. Esto asegura que el equipo esté trabajando hacia una meta específica y progresando regularmente.

Backlog de producto priorizado

La cartera de productos es una lista priorizada de características y requisitos en los que trabajará el equipo durante el proyecto. El propietario del producto es responsable de mantener la acumulación de productos y garantizar que refleje las necesidades y prioridades del cliente.

Mejora continua

Scrum enfatiza la importancia de la mejora continua. Tanto en términos del producto que se está desarrollando como de los procesos utilizados para desarrollarlo. Esto significa que los equipos deben reflexionar periódicamente sobre su trabajo y buscar formas de mejorar su desempeño.

Desafíos

Fuente: scrum.org

Si bien la metodología Scrum puede ser muy efectiva en el desarrollo de software, también existen algunos desafíos que los equipos pueden enfrentar al implementarla.

Resistencia al cambio

Scrum requiere un cambio significativo en la mentalidad y la cultura, lo que puede ser difícil de aceptar para algunos miembros del equipo. Algunos miembros del equipo pueden resistirse al cambio, lo que puede dificultar la implementación efectiva de Scrum. En otras palabras, necesitas “conseguirlo”. Hasta que no lo hagas, no estás dentro.

Falta de experiencia

Necesita un cierto nivel de experiencia y conocimientos para implementar de manera efectiva. Si los miembros del equipo no están familiarizados con las metodologías Scrum o Agile, representa un desafío a superar.

Falta de compromiso

Scrum necesita un alto compromiso de todos los miembros del equipo, incluido el propietario del producto, el maestro de Scrum y el equipo de desarrollo. Si los miembros del equipo no están completamente comprometidos con el proceso, puede ser difícil lograr los resultados deseados.

Mala comunicación

Scrum depende en gran medida de la comunicación y la colaboración entre los miembros del equipo. Si los miembros del equipo no se comunican con frecuencia y eficacia, puede ser un desafío para ellos.

Énfasis excesivo en el proceso

Si bien Scrum proporciona un marco para el desarrollo de software Agile, es importante recordar que es solo un marco. Si los miembros del equipo se enfocan demasiado en seguir el proceso, pueden perder de vista el objetivo final de entregar productos de software de alta calidad.

Roles de un equipo Scrum

Cada equipo scrum, para ser efectivo, constará de unos roles concretos. Si esos roles no están dedicados al equipo o se cuentan de manera incorrecta, la creación exitosa de un equipo de scrum de este tipo podría estar en peligro.

#1. Equipo de desarrollo

Esta es la parte de ejecución del equipo, por lo que desde la perspectiva de la entrega del producto, quizás sea la parte más importante del equipo. Un equipo típico de desarrollo de Scrum consta de especialistas en desarrollo/pruebas/arquitectura/analistas en una cantidad total de 4 a 10 personas. Si es menos, es cuestionable si aún puede llamarlo un equipo. Si es más, todas las ceremonias y la gestión de las discusiones del equipo se volverán demasiado complejas y no valdrá la pena el esfuerzo de mantenerlas.

El equipo de desarrollo toma las historias del backlog, las estima y las implementa dentro de los sprints. El equipo es responsable del desarrollo y las pruebas de la historia y, una vez hecho esto, también de la implementación en producción.

#2. Maestro Scrum

Un maestro de scrum actúa como orquestador para el equipo de desarrollo. Programa reuniones periódicas, se asegura de que el equipo de desarrollo sea claro en el contenido y organiza las actividades durante un sprint con el objetivo de lograr el plan y los objetivos del sprint.

Este no es realmente un rol de contenido. De hecho, el scrum master no necesita comprender técnicamente nada del contenido de las historias que el equipo de desarrollo está resolviendo (aunque seguro que ayuda). Sin embargo, el scrum master sirve al equipo de desarrollo y lo protege del entorno externo. Por proteger, me refiero a permitir que el equipo trabaje en base a principios ágiles. Sé el orador del equipo y no permitas cambiar el plan de sprint actualmente acordado por solicitudes no planificadas.

#3. Dueño del producto

Servidores de propietarios de productos (PO) para la conexión entre el equipo de desarrollo y los usuarios comerciales (partes interesadas) externos al equipo. PO discute el contenido con todas las partes relevantes y trae el contenido acordado al equipo Scrum.

Luego, PO crea historias para el equipo con descripciones y expectativas claras. PO debe asegurarse de que el equipo de desarrollo comprenda este contenido para que pueda estimar cada historia. Como tal, PO posee las discusiones de refinamiento de historias dentro del equipo.

Además del contenido y la gestión completa del backlog, PO también es responsable de establecer las prioridades para cada historia dentro del backlog. Sin embargo, PO no es responsable de la selección de historias concretas en el sprint. Eso solo lo puede hacer el equipo de desarrollo comprometiéndose con el alcance, el equipo elegirá para el próximo sprint. La OP solo puede influir en esa selección estableciendo y comunicando adecuadamente las prioridades.

Interacciones de roles dentro de un equipo Scrum

Fuente: scrum.org

Incluso con todas las personas y roles manejados, la comunicación es realmente la clave del éxito. Lo más importante, la comunicación correcta porque hay muchas maneras de hacerlo mal. Y esa es en realidad la principal razón por la que muchos equipos de scrum no tienen éxito. Simplemente no lo arreglan bien.

Por ejemplo, los propietarios de productos a menudo le piden al equipo de desarrollo que presente nuevas historias de contenido. Pero no es el propósito del equipo de desarrollo crear el backlog. Claro, pueden ayudar a definir las historias, hacerlas detalladas y dividirlas para que sea posible ejecutarlas dentro de los sprints. Pero el propietario del producto es responsable de la acumulación. Lo ideal es que la PO no le pida al equipo de desarrollo que se conecte con las partes interesadas del negocio.

En otra nota, ni el scrum master ni el propietario del producto definirán cuál será exactamente el alcance del próximo sprint. De todos modos, esto sucede muy a menudo, ya que los roles de maestro de scrum y propietario del producto son una especie de roles de líder natural dentro del equipo de scrum. Pero en realidad, no están en condiciones de decidir qué debe o no debe llevar el equipo de desarrollo al sprint. El equipo de desarrollo es el único que puede ejecutar esto, por lo que es el equipo de desarrollo quien decide. Eso significa que PO está brindando información sobre qué tan importante es cada historia desde la perspectiva comercial; PO puede incluso ordenar la acumulación de historias de la más importante a la menos importante. De esta manera, el equipo de desarrollo tiene una idea de qué historias tomar primero.

El propietario del producto debe hacer un esfuerzo para discutir periódicamente con el equipo el contenido nuevo que la OP quiere que entregue el equipo. PO está aquí para discutir a fondo cada historia que crea o trae a la cartera de pedidos. Todo el mundo en el equipo de desarrollo debe entender la historia, y les queda claro cuáles son los criterios de aceptación.

El Scrum master no es solo el orquestador del equipo; de alguna manera, SM protege al equipo contra el propietario del producto, el liderazgo u otras partes interesadas externas. SM mantiene en funcionamiento los procesos internos de scrum y dirige la mayoría de las ceremonias para el equipo. En las llamadas de estado diarias, SM se asegura de que todos digan solo las actualizaciones importantes del día para que la reunión no tarde más de lo programado. Eso realmente se aplica a todas las llamadas.

SM también organiza llamadas retrospectivas periódicas para el equipo, en las que ayuda al equipo a reflexionar sobre el trabajo realizado en el sprint anterior e identificar áreas en las que el equipo puede mejorar.

Ultimas palabras

Establecer un equipo scrum exitoso suele ser un largo camino. Debe adquirir experiencia dentro del equipo, incluso si los miembros concretos del equipo ya tienen alguna experiencia previa. Cada equipo Scrum es único, y siempre lleva tiempo encontrar la manera de trabajar y colaborar juntos como equipo en temas comunes.

Lo más importante es mantener estable el equipo una vez que ya lo formas. Solo entonces el equipo puede comenzar a mejorar con cada próximo sprint. El objetivo final es convertirse en un equipo autoorganizado, donde incluso la presencia de un maestro de la escoria ya no sea obligatoria la mayor parte del tiempo. Si no puede mantener unido al equipo, todavía estará en la fase de aprendizaje.

A continuación, consulte las mejores herramientas de scrum para una empresa nueva o mediana.