Menú

Metodología ágil: una guía para principiantes sobre el método ágil y Scrum

agile methodology beginner s guide agile method

Pruebe Nuestro Instrumento Para Eliminar Los Problemas

Una guía completa de la metodología ágil: (más de 20 tutoriales detallados de la metodología Agile Scrum)

Esta es la guía para que los desarrolladores y evaluadores de software comprendan y comiencen a trabajar en los Metodología ágil SCRUM para desarrollo y pruebas de software . Aprenda las terminologías básicas pero importantes que se utilizan en el proceso Agile Scrum junto con un ejemplo real del proceso completo.

Hemos enumerado todos los tutoriales ágiles de esta serie para su conveniencia. Espero que te sean de gran ayuda.

Tópicos cubiertos: Qué es Agile, Qué es Scrum, Metodología Agile en Desarrollo y Testing de Software, Pruebas Ágiles, Proceso Agile Scrum, Metodología Scrum con Scrum Team y Scrum Master.

introducción al desarrollo ágil

Lo que vas a aprender:

Lista de tutoriales de metodología ágil

Tutorial #1: Metodologías ágiles de Scrum (Este tutorial)
Tutorial #2: Manifiesto ágil
Tutorial #3: Scrum Team y sus roles y responsabilidades
Tutorial #4: Artefactos Scrum
Tutorial #5: Eventos de Scrum
Tutorial #6: Triaging de defectos en Scrum
Tutorial #7: Equipos Scrum autosuficientes
Tutorial #8: Three Amigo Principle
Tutorial #9: SAFe: marco ágil escalado
Tutorial #10: Prueba ágil de Scrum

MÁS tutoriales recomendados de Agile Scrum:

Tutorial #11: Principales técnicas de estimación ágil
Tutorial #12: Modelo híbrido de cascada ágil
Tutorial #13: Kanban vs Scrum vs Agile
Tutorial #14: JIRA Agile Tutorial
Tutorial #15: Reuniones ágiles retrospectivas
Tutorial #16: Papel de los analistas comerciales en SCRUM
Tutorial #17: Papel del control de calidad en Scrum

Herramientas y preguntas de la entrevista:

Tutorial #18: Herramientas de prueba ágiles
Tutorial #19: Las mejores herramientas de gestión de proyectos ágiles
Tutorial #20: Preguntas principales de la entrevista ágil
Tutorial #21: Principales preguntas de la entrevista de Scrum

Comencemos con el primer tutorial de la serie: Introducción a Agile Scrum.

Introducción al desarrollo ágil

Ágil en desarrollo de software:

Agile es uno de los marcos de desarrollo de software más utilizados y reconocidos del mundo.

La mayoría de las organizaciones lo han adoptado de una forma u otra, pero aún queda un largo camino por recorrer en la madurez de sus programas de adopción. El único objetivo de esta serie de tutoriales es incorporar profesionales tecnológicos y no tecnológicos en el mundo ágil.

Lo guiaremos a través del viaje ágil paso a paso hasta que comprenda la filosofía detrás del uso de Agile, sus ventajas y cómo practicarlo. Esta serie tiene como objetivo equipar y permitir a los lectores aplicar el aprendizaje Agile y Scrum en su trabajo.

Este tutorial en particular está dedicado a explicarle por qué era necesario Agile y cómo se creó. Lo fundamental aquí es hacerle comprender el concepto de adopción ágil en las industrias de desarrollo de software.

Historia de Agile

Agile nació cuando, un buen día, 17 personas con diferentes antecedentes en metodologías de desarrollo, se reunieron para intercambiar ideas sobre si había una posible solución alternativa al desarrollo de software que pudiera conducir a un tiempo de desarrollo más rápido y con menos documentación.

En ese momento, el desarrollo de software solía ocurrir durante tanto tiempo que cuando los proyectos estaban listos para entregarse, el negocio había avanzado y los requisitos habían cambiado. Por lo tanto, un proyecto no pudo satisfacer las necesidades comerciales, incluso si pudo cumplir con sus objetivos definidos.

Así, estos campeones de diferentes técnicas de ingeniería de software se reunieron y el resultado final de su encuentro fue lo que llamaron el 'manifiesto ágil' que discutiremos en detalle en el próximo tutorial de esta serie.

Pero lo ágil que nació ese día no es lo que vemos hoy en las organizaciones. La metodología que acordaron los expertos se describió como 'ligera' y rápida. Pero la principal ventaja de esta reunión fue la idea de que la entrega más rápida de un producto y la retroalimentación constante eran las claves para lograr el éxito en el desarrollo de software.

Las técnicas de cascada existentes eran demasiado engorrosas y no tenían posibilidad de retroalimentación hasta que el producto final estaba listo para ser entregado. Esto significaba que no había margen para corregir el rumbo y el cliente no podía ver el progreso hasta que todo el producto estaba listo. Y eso era lo que estos expertos querían evitar.

Querían una solución que permitiera una retroalimentación constante con el fin de evitar el costo de volver a trabajar en una etapa posterior.

Desafíos ágiles

Las técnicas de cascada existentes en ese momento eran demasiado engorrosas y no tenían provisión de retroalimentación hasta que el producto final estaba listo para ser entregado. Se le llamó un modelo de desarrollo en cascada porque los equipos primero terminaron un paso por completo y solo después avanzaron al siguiente paso.

Esto significaba que no había margen para corregir el rumbo y el cliente no podía ver el progreso hasta que todo el producto estaba listo. Y eso era lo que estos expertos querían evitar. Querían una solución que permitiera una retroalimentación constante con el fin de evitar el costo de volver a trabajar en una etapa posterior.

Y es por eso que ágil también se trata de ser adaptativo y de mejora continua, tanto como de retroalimentación constante y velocidad de entrega.

¿Qué son las promesas ágiles?

Promesas ágiles

Agile no se trata solo de aplicar las prácticas establecidas en el desarrollo de software. También trae un cambio en la mentalidad del equipo que los impulsa a desarrollar un mejor software, trabajar juntos y, finalmente, lograr que sean un Cliente feliz.

Los valores y principios ágiles permiten al equipo cambiar su enfoque y cambiar su proceso de pensamiento para construir un mejor software.

¿Qué es exactamente ágil?

Agile no es un conjunto de reglas. Agile no es un conjunto de pautas. Agile ni siquiera es una metodología. Más bien, Agile es un conjunto de principios que fomentan la flexibilidad, la adaptabilidad, la comunicación y el software de trabajo sobre planes y procesos. Está muy sucintamente capturado en lo que se llama el manifiesto ágil.

El desarrollo de software ágil permite que el equipo trabaje en conjunto de manera más eficiente y efectiva en el desarrollo de proyectos complejos. Consiste en prácticas que ejercitan técnicas iterativas e incrementales que se adoptan fácilmente y muestran grandes resultados.

Para aplicar Agile en acción, contamos con varios métodos y metodologías basados ​​en Agile. Estos métodos y metodologías satisfacen todas las necesidades de una industria de desarrollo de software desde el diseño y la arquitectura de software, el desarrollo y las pruebas hasta la gestión de proyectos y las entregas.

No solo eso, los métodos y metodologías ágiles también abren un campo para la mejora de procesos como parte integral de cada entrega.

Agile es un enfoque de desarrollo de software en el que un equipo autosuficiente y multifuncional trabaja para realizar entregas continuas a través de iteraciones y evoluciona a lo largo del proceso mediante la recopilación de comentarios de los usuarios finales.

¿Cómo practicar Agile?

Hay varias Metodologías Ágiles que están en práctica en varias industrias diversificadas.

Metodologías ágiles

Sin embargo, las metodologías más populares entre todas ellas son:

  • Melé
  • Kanban
  • Programación extrema

Todas estas metodologías se centran en el desarrollo de software ajustado y ayudan a crear un mejor software de manera eficaz y eficiente.

Eso es todo con Introducción ágil. La parte está estructurada para ayudarlo a comprender los valores y principios fundamentales que se adoptarán para que un equipo trabaje en un modo y una mentalidad ágiles.

Ágil Metodología

Introducción a los modelos ágiles:

Metodología ágil

mejor software de recuperación de disco duro externo

Como todos sabemos, Agile es una metodología de desarrollo de software.

También hemos aprendido sobre los valores y principios que fueron mencionados en el manifiesto ágil por los fundadores de ágil. En nuestras discusiones iniciales, también eludimos las diferencias entre los modelos ágiles y tradicionales en cascada.

En este tutorial conoceremos las ventajas y desventajas de la metodología ágil.

Veremos ¿qué es scrum? y en qué se diferencia de ágil. Luego entenderemos las diversas metodologías ágiles que están siendo utilizadas por diferentes organizaciones y cómo podemos implementar ágiles usándolas.

También podrá apreciar la diferencia y también las ventajas / desventajas de estas metodologías.

Ventajas de la metodología ágil

A continuación se presentan las diversas ventajas de la metodología ágil:

  • Los clientes continuamente ven y sienten el progreso del proyecto al final de cada iteración / sprint.
  • Cada sprint proporciona al cliente un software funcional que cumple con sus expectativas según la definición de hecho proporcionada por ellos.
  • Los equipos de desarrollo responden bastante a los requisitos cambiantes y pueden adaptarse a los cambios incluso en las etapas avanzadas de desarrollo.
  • Existe una comunicación bidireccional constante que mantiene a los clientes involucrados, por lo que todas las partes interesadas, comerciales y técnicas, tienen una visibilidad clara del progreso del proyecto.
  • El diseño del producto es eficiente y cumple con los requisitos comerciales.

Desventajas de la metodología ágil

Aunque hay varias ventajas de la metodología Agile, también hay ciertas desventajas involucradas.

Son:

#1) No se prefiere la documentación completa, lo que puede llevar a que los equipos ágiles lo interpreten incorrectamente, ya que ágil no requiere documentación. Entonces el rigor se pierde en la documentación. Esto debe evitarse preguntándose continuamente si esta es información suficiente para continuar o no.

#2) A veces, al comienzo de los proyectos, los requisitos no son muy claros. Los equipos pueden continuar y encontrar que la visión de los clientes se ha realineado y, en tales situaciones, los equipos necesitan incorporar muchos cambios y también es difícil medir el resultado final.

Tipos de metodologías ágiles

Hay varias metodologías ágiles en práctica en todo el mundo. Vamos a conocer más en detalle cuatro de los más populares.

Tipos de metodologías ágiles

# 1) Scrum

Scrum puede considerarse fácilmente como el marco ágil más popular. La mayoría de los profesionales consideran el término 'scrum' como sinónimo de 'ágil'. Pero eso es un error. Scrum es solo uno de los marcos mediante los cuales puede implementar Agile.

La palabra scrum proviene del rugby deportivo. Donde los jugadores se apiñan en una posición entrelazada empujando contra los oponentes. Cada jugador tiene un papel definido en su posición y puede jugar tanto ofensivo como defensivo según la demanda de la situación.

De manera similar, el scrum en TI cree en equipos de desarrollo autogestionados empoderados con tres roles específicos y claramente definidos. Estos roles incluyen: Product Owner (PO), Scrum Master (SM) y el equipo de desarrollo formado por programadores y testers . Trabajan juntos en duraciones de recuadros de tiempo iterativo llamadas sprints.

El primer paso es la creación de la cartera de pedidos del producto. Es una lista de tareas pendientes que debe hacer el equipo de scrum. Luego, el equipo de scrum selecciona los elementos de máxima prioridad e intenta terminarlos dentro del cuadro de tiempo llamado sprint.

Una forma más fácil de recordar todo esto es memorizar el marco 3-3-5. Significa que un proyecto de scrum tiene 3 roles, 3 artefactos y 5 eventos.

Estos son –

Roles: PO, Scrum master y equipo de desarrollo.

Artefactos: Pila de Producto, Pila de SprintyIncremento de producto.

Eventos: Sprint, planificación de Sprint, Scrum diario, revisión de Sprint y retrospectiva de Sprint.

3-3-5 marco

Conoceremos con más detalle cada uno de estos en nuestros tutoriales posteriores.

# 2) Kanban

Kanban es un término japonés que significa tarjeta. Estas tarjetas contienen detalles del trabajo a realizar en el software. El propósito es la visualización. Cada miembro del equipo es consciente del trabajo a realizar a través de estas ayudas visuales.

Los equipos utilizan estas tarjetas Kanban para la entrega continua. Al igual que Scrum, Kanban también sirve para ayudar a los equipos a trabajar de manera eficaz y promueve equipos autogestionados y colaborativos.

Pero también hay diferencias entre estos dos, como durante un scrum sprint, los elementos en los que trabaja un equipo son fijos y no podemos agregar elementos al sprint, mientras que, en Kanban, podemos agregar elementos si hay capacidad disponible. Esto es particularmente útil cuando los requisitos cambian con frecuencia.

Del mismo modo, otra diferencia es que, si bien el scrum tiene roles definidos de un PO, scrum master y equipos de desarrollo, no hay roles predefinidos en Kanban.

Otra diferencia es que, si bien el scrum sugiere una priorización de la acumulación de productos, Kanban no tiene tal requisito y es totalmente opcional. Por lo tanto, Kanban requiere menos organización y evita actividades que no agregan valor y es adecuado para los procesos que requieren capacidad de respuesta a los cambios.

#3) Lean

Lean es una filosofía que se centra en la reducción de residuos. ¿Como hace eso?

En lean, divide un proceso en actividades que agregan valor, actividades que no agregan valor y actividades esenciales que no agregan valor. Cualquier actividad que pueda ser clasificada como una actividad que no agrega valor es un desperdicio y debemos tratar de eliminar ese desperdicio en el proceso para hacerlo más ágil.

Un proceso más ágil significa una entrega más rápida y menos esfuerzo desperdiciado en tareas que no ayudan a lograr los objetivos del equipo. Esto ayuda a optimizar cada paso del ciclo de desarrollo de software. Es por eso que los principios lean se adaptaron de la fabricación ajustada al desarrollo de software.

El desarrollo de software Lean se puede utilizar en cualquier proyecto de TI aplicando los siete principios Lean que se muestran a continuación:

siete principios lean

Estos se explican por sí mismos, como sugieren sus nombres. Eliminar el desperdicio es el primer y más importante principio lean y vimos cómo hacerlo, simplemente clasificamos las actividades como valor y sin valor agregado.

Una actividad sin valor agregado puede ser cualquier parte del código que pueda hacerla menos robusta, aumentar el esfuerzo involucrado y tomar mucho tiempo sin agregar un valor comercial justificable. También pueden ser historias de usuarios vagas o pruebas deficientes o agregar características que no son necesarias en el panorama general.

El segundo principio que amplifica el aprendizaje es nuevamente fácil de entender, ya que un equipo necesita diversas habilidades para entregar productos en un entorno que cambia rápidamente con nuevas tecnologías que surgen en duraciones rápidas.

Tomar decisiones tardías puede ser gratificante en circunstancias en las que reduce la repetición del trabajo, como si se espera algún cambio, entonces es mejor retrasarlo para que el equipo no tenga que rehacer el trabajo a medida que cambian las necesidades comerciales.

Pero siempre hay una compensación aquí, ya que los equipos deben equilibrar esto con el cuarto principio de entregar más rápido. La demora en las decisiones no debe afectar la entrega general y no debe reducir el ritmo de trabajo. Un ojo debe estar siempre en la imagen completa.

Tener equipos empoderados también es muy común hoy en día y esto es algo que incluso sugiere ágil. Los equipos empoderados son más responsables y pueden tomar decisiones más rápido. El sentido de propiedad en un equipo empoderado conduce a mejores resultados. Para empoderar a un equipo, se les debe permitir organizarse y tomar decisiones por sí mismos.

Por lo tanto, vemos que lean y ágil tienen mucho en común con una gran diferencia: mientras que los equipos lean pueden ayudar a refinar un producto, los equipos ágiles son los que realmente construyen el producto.

# 4) Programación extrema (XP)

La programación extrema es otra de las técnicas ágiles más populares. Según extremeprogramming.org, el primer proyecto de XP se inició el 6 de marzo de 1996. También mencionan que XP afecta el desarrollo de proyectos de software de 5 formas diferentes: comunicación, simplicidad, retroalimentación, respeto y coraje. Estos se denominan valores de XP.

Fuera de estos, todo comienza con la comunicación. Los equipos de XP colaboran con equipos comerciales y compañeros programadores de forma regular y comienzan a crear código desde el primer día. El enfoque aquí está en la comunicación cara a cara en la medida de lo posible con la ayuda de otras ayudas visuales.

Los programadores extremos también crean un código simple y comienzan a recibir comentarios sobre él desde el primer día. La atención se centra en no exagerar o predecir requisitos que no se han compartido. Esto mantiene el diseño simple y produce solo el producto mínimo que cumplirá con los requisitos.

La retroalimentación ayuda al equipo a mejorar y producir una mejor calidad de trabajo. Esto les ayuda a desarrollar el respeto mutuo a medida que aprenden unos de otros y aprenden a compartir sus puntos de vista.

Esto también les da valor, ya que saben que han reunido las mejores ideas de todos y han producido un buen producto con los comentarios de los demás. Por lo tanto, tampoco temen incluir cambios o recibir más comentarios sobre su trabajo.

Esto es particularmente útil en proyectos donde los requisitos van a cambiar con frecuencia. La retroalimentación constante ayudará a los equipos a incluir estos cambios con valentía.

Así hemos visto las diferentes metodologías ágiles como Scrum, XP, Kanban y Lean junto con sus respectivas ventajas y desventajas.

Ahora, podemos diferenciar fácilmente entre ellos y también apreciar las diferencias más sutiles entre ellos. También aprendimos los fundamentos de cada una de estas metodologías y vimos cómo aplicarlos en nuestros proyectos cuando y como sea necesario.

En la siguiente parte, comprendamos todo sobre Scrum.

Metodología Scrum

SCRUM es un proceso en metodología ágil que es una combinación del modelo iterativo y el modelo incremental.

Una de las mayores desventajas del tradicional Modelo de cascada fue eso - hasta que se complete la primera fase, la aplicación no pasa a la otra fase. Y, por casualidad, si hay algunos cambios en la última etapa del ciclo, entonces se vuelve muy difícil implementar esos cambios, ya que implicaría volver a visitar las fases anteriores y rehacer los cambios.

Prueba ágil de scrum

Algunas de las características clave de SCRUM incluyen:

  • Equipo autoorganizado y enfocado.
  • No hay documentos de requisitos enormes, más bien tienen historias muy precisas y al grano.
  • Los equipos multifuncionales trabajan juntos como una sola unidad.
  • Estrecha comunicación con el representante del usuario para comprender las funciones.
  • Tiene un cronograma definido de máximo un mes.
  • En lugar de hacer toda la 'cosa' a la vez, Scrum hace un poco de todo en un intervalo determinado.
  • La capacidad y disponibilidad de los recursos se consideran antes de comprometer nada.

Para comprender bien esta metodología, es importante comprender las terminologías clave en SCRUM.

También leer => Cómo ofrecer funciones de software de alto valor en un corto período de tiempo utilizando Agile Scrum Process

Terminologías importantes de SCRUM

1) Equipo Scrum

El equipo de scrum es un equipo compuesto por 7 con + o - dos miembros. Estos miembros son una mezcla de competencias y se componen de desarrolladores, probadores, personas de bases de datos, personas de apoyo, etc. junto con el propietario del producto y un scrum master.

Todos estos miembros trabajan juntos en estrecha colaboración durante un intervalo recursivo y definido, para desarrollar e implementar dichas características. La disposición de los asientos del equipo SCRUM juega un papel muy importante en su interacción, nunca se sientan en cubículos o cabinas, sino en una mesa enorme.

Equipo Scrum

2) Sprint

Sprint es un intervalo o marco de tiempo predefinido en el que el trabajo debe completarse y estar listo para revisión o para la implementación de producción. Este recuadro de tiempo suele situarse entre 2 semanas y 1 mes.

cuales son las etapas de sdlc

En nuestro día a día, cuando decimos que seguimos un ciclo de Sprint de 1 mes, simplemente significa que trabajamos durante un mes en las tareas y las preparamos para su revisión a finales de ese mes.

3) Dueño del producto

El propietario del producto es la parte interesada clave o el usuario principal de la aplicación que se va a desarrollar. El propietario del producto es la persona que representa al cliente. Él / ella tiene la autoridad final y siempre debe estar disponible para el equipo.

Debe estar disponible cuando alguien tenga dudas que necesiten aclaración. Es importante que el propietario del producto comprenda y no asigne ningún requisito nuevo en medio del sprint o cuando el sprint ya ha comenzado.

4) Scrum Master

Scrum Master es el facilitador del equipo scrum. Él / ella se asegura de que el equipo de scrum sea productivo y progresivo. En caso de cualquier impedimento, scrum master hace un seguimiento y lo resuelve para el equipo. SCRUM Master es el mediador entre el PO y el equipo.

Mantiene informado al PO sobre el progreso del Sprint. Si hay obstáculos o inquietudes para el equipo, hable con el PO y los resuelva. Al igual que el Daily Standup del equipo, todos los días ocurre un standup del SCRUM Master con el PO.

Lectura recomendada => ¿Cómo ser un buen mentor, entrenador y defensor de equipo en un mundo de pruebas ágil?

5) Analista de negocios (BA)

Un analista de negocios juega un papel muy importante en SCRUM. Esta persona es responsable de finalizar el requisito y redactarlo en los documentos de requisitos (según los cuales se crean las historias de usuario).

Si hay alguna ambigüedad en las Historias de Usuario / Criterios de Aceptación, él / ella es quien es abordado por el equipo técnico (SCRUM) y luego lo lleva al PO o si es posible lo resuelve por su cuenta. En proyectos a gran escala, puede haber más de 1 BA, pero en proyectos a pequeña escala, el Master SCRUM también puede actuar como BA.

Siempre es una buena práctica tener una licenciatura cuando comienza el proyecto.

6) Historia de usuario

Las historias de usuario no son más que los requisitos o características que deben implementarse.

En el scrum, no tenemos esos enormes documentos de requisitos, sino que los requisitos se definen en un solo párrafo, que normalmente tiene el formato:

Como un
quiero
Conseguir

Por ejemplo :

Como administrador, quiero tener un bloqueo de contraseña en caso de que el usuario ingrese una contraseña incorrecta durante 3 veces consecutivas para restringir el acceso no autorizado.

Hay algunas características de las historias de usuario que deben cumplirse. Las historias de los usuarios deben ser breves, realistas, estimables, completas, negociables y comprobables. Una historia de usuario nunca se modifica ni cambia en medio del Sprint.

Es responsabilidad del SCRUM Master y del BA (si corresponde) asegurarse de que el PO haya redactado correctamente las Historias de usuario con un conjunto adecuado de Criterios de aceptación ”. Si se van a realizar cambios que afectarán el lanzamiento del sprint, dichas historias se retiran del sprint o se realizan según las horas disponibles.

Cada historia de usuario tiene un criterio de aceptación que debe estar bien definido y entendido por el equipo.

Los criterios de aceptación detallan la historia del usuario que proporciona los documentos de respaldo. Ayuda a refinar aún más la historia del usuario. Cualquiera del equipo puede anotar los criterios de aceptación. El equipo de pruebas basa sus casos / condiciones de prueba en estos criterios de aceptación.

7) Épicas

Las epopeyas son historias de usuarios equívocas o podemos decir que estas son historias de usuarios que no están definidas y se guardan para sprints futuros.

Solo trata de relacionarlo con la vida, imagina que te vas de vacaciones. A medida que avanza la próxima semana, tiene todo en su lugar, como las reservas de hotel, visitas turísticas, cheques de viaje, etc. Pero ¿qué pasa con su plan de vacaciones para el próximo año? Solo tiene una vaga idea de que puede ir al lugar XYZ, pero no tiene un plan detallado.

Un Epic es como tu plan de vacaciones del próximo año, donde simplemente sabes que es posible que quieras ir, pero a dónde, cuándo, con quién, todos estos detalles no tienes idea en este momento.

De manera similar, hay características que se requieren implementar en el futuro cuyos detalles aún no se conocen. En su mayoría, una función comienza con una épica y luego se divide en historias que podrían implementarse.

8) Pila de Producto

La acumulación de productos es una especie de depósito o fuente donde se guardan todas las historias de usuarios. Esto lo mantiene el propietario del producto. La cartera de productos se puede imaginar como una lista de deseos del propietario del producto, que la prioriza según las necesidades comerciales.

Durante la reunión de planificación (consulte la siguiente sección), se toma una historia de usuario de la cartera de pedidos del producto, luego el equipo hace la lluvia de ideas, la comprende, la perfecciona y decide colectivamente qué historias de usuario tomar, con la intervención del propietario del producto.

9) Pila de Sprint

Según la prioridad, las historias de los usuarios se toman de la Lista de Producto como una a la vez. El equipo de Scrum hace una lluvia de ideas para determinar la viabilidad y decide las historias para trabajar en un sprint en particular. La lista colectiva de todas las historias de usuario con las que trabaja el equipo de scrum en un sprint en particular se conoce como backlog de Sprint.

Sprint Backlog

10) Puntos de historia

Los puntos de la historia son una indicación cuantitativa de la complejidad de una historia de usuario. Con base en el punto de la historia, se determinan la estimación y los esfuerzos para una historia.

Un punto de la historia es relativo y no absoluto. Para asegurarnos de que nuestras estimaciones y esfuerzos sean correctos, es importante verificar que las historias de usuarios no sean grandes. Cuanto más precisa y pequeña sea la historia del usuario, más precisa será la estimación.

Todas y cada una de las historias de usuario se asignan a un punto de la historia basado en la serie Fibonacci (1, 2, 3, 5, 8, 13 y 21). Más alto es el número, lo complejo es la historia.

Para ser preciso

  • Si asigna 1/2/3 punto de historia, significa que la historia es pequeña y de baja complejidad.
  • Si da puntos como 5/8, es un complejo medio y
  • 13 y 21 son muy complejos.

Aquí la complejidad consiste tanto en el desarrollo como en el esfuerzo de prueba.

Para decidir un punto de la historia, la lluvia de ideas ocurre dentro del equipo de scrum y el equipo decide colectivamente un punto de la historia.

Puede suceder que el equipo de desarrollo dé un punto de historia de 3 a una historia en particular, porque para ellos pueden ser 3 líneas de cambio de código, pero el equipo de pruebas da 8 puntos de historia porque sienten que este cambio de código afectará módulos más grandes, por lo que el esfuerzo de prueba sería mayor. Cualquiera que sea el punto de la historia que esté dando, debe justificarlo.

Entonces, en esta situación, ocurre una lluvia de ideas y el equipo acepta colectivamente un punto de la historia.

Siempre que esté decidiendo sobre un punto de la historia, tenga en cuenta los siguientes factores:

  • La dependencia de la historia con otra aplicación / módulo.
  • El conjunto de habilidades del recurso.
  • La complejidad de la historia.
  • Aprendizaje histórico.
  • Criterios de aceptación de la historia de usuario.

Si no está al tanto de una historia en particular, no la dimensione.

Siempre que una historia tiene = o> 8 puntos, se divide en 2 o más historias.

11) Gráfico de quemado

El gráfico de quemado es un gráfico que muestra el esfuerzo real estimado v / s de las tareas de scrum.

Es un mecanismo de seguimiento mediante el cual, para un sprint en particular, se realiza un seguimiento de las tareas diarias para verificar si las historias están progresando hacia la finalización de los puntos de la historia comprometidos o no.

Ejemplo : Para comprender esto, consulte la siguiente figura:

Gráfico de quemado 1

He asumido:

  • Sprint de 2 semanas (10 días)
  • 2 recursos reales trabajando en el sprint.

'Historia' -> Esta columna muestra las historias de usuario tomadas para el sprint.

'Tarea' -> Esta columna muestra la lista de la tarea asociada con la historia del usuario.

'Esfuerzo' -> Esta columna muestra el esfuerzo. Ahora bien, esta medida es el esfuerzo total para completar la tarea. No representa el esfuerzo realizado por un individuo específico.

'Día 1 - Día 10' -> Esta (s) columna (s) muestra las horas que quedan para completar la historia. Por favor, observe que la hora NO es la hora que ya está hecha, SINO las horas que quedan.

'Esfuerzo estimado' -> Es el total del esfuerzo. Para el 'Inicio' es simplemente la suma de toda la tarea individual: SUM (C5: C15)

Un número total de esfuerzo que debe completarse en 1 día es 70/10 = 7. Por lo tanto, al final del día 1, el esfuerzo debe reducirse a 70 - 7 = 63. De manera similar, se calcula para todos los días hasta el día 10, cuando el esfuerzo estimado debe ser 0 (Fila 16)

'Esfuerzo real restante' -> Como su nombre indica, es el esfuerzo que realmente queda para completar la historia. También puede suceder que los esfuerzos reales aumenten o disminuyan del estimado.

Puede utilizar las funciones incorporadas y el gráfico en Excel para crear este gráfico de evolución.

Los pasos de Burn Down Chart serían:

  1. Ingrese todas las historias (Columna A5 - A15).
  2. Ingrese todas las Tareas (Columna B5 - B15).
  3. Ingrese los Días (Día 1 - Día 10).
  4. Ingrese los esfuerzos iniciales (Suma las tareas C5 - C15).
  5. Aplique la fórmula para calcular los 'Esfuerzos estimados' para cada día (día 1 al día 10). Ingrese la fórmula en D15 (C16- $ C $ 16/10) y arrástrela para todos los días.
  6. Para cada día, ingrese los esfuerzos reales. Ingrese la fórmula en D17 (SUM (D5: D15)) para resumir los esfuerzos reales restantes y arrástrela para todos los demás días.
  7. Selecciónelo y cree el gráfico de la siguiente manera:

Gráfico de quemado 2

12) Velocidad

El número total de puntos de la historia que un equipo de scrum archiva en un sprint se llama Velocidad. El equipo Scrum es juzgado o referenciado por su velocidad. Dicho esto, se debe tener en cuenta que el objetivo aquí NO es lograr los máximos puntos de la historia, sino tener un entregable de calidad, respetando el nivel de comodidad del equipo scrum.

Por ejemplo : Para un sprint en particular: el número total de historias de usuario es de 8 con puntos de historia como se muestra a continuación.

Velocidad de Scrum

Entonces aquí la velocidad será la suma de los puntos de la historia = 30

Definición de Terminado:

Un Sprint se marca como Completado cuando se completan todas las historias, todas las tareas de desarrollo, investigación y control de calidad están marcadas como 'Completadas', todos los errores se corrigen y cierran, de lo contrario los que se pueden hacer más tarde (como no completamente relacionados o son menos importantes) se extraen y agregan a la cartera de pedidos, se completa la revisión del código y las pruebas unitarias, las horas estimadas han cumplido con las horas reales dedicadas a las tareas y, lo más importante, se ha entregado una demostración exitosa al PO y las partes interesadas.

Actividades realizadas en la metodología SCRUM

# 1) Reunión de planificación

Una reunión de planificación es el punto de partida de Sprint. Es la reunión donde se reúne todo el equipo de scrum, el SCRUM Master selecciona una historia de usuario en función de la prioridad de la cartera de productos y la lluvia de ideas del equipo.

Basado en la discusión, el equipo de scrum decide la complejidad de la historia y la dimensiona según la serie de Fibonacci. El equipo identifica las tareas junto con los esfuerzos (en horas) que se realizarían para completar la implementación de la historia de usuario.

Muchas veces, la reunión de planificación está precedida por una “reunión de planificación previa”. Es como la tarea que hace el equipo de scrum antes de sentarse para la reunión formal de planificación. El equipo intenta anotar las dependencias u otros factores que les gustaría discutir en la reunión de planificación.

# 2) Ejecución de tareas de Sprint

Como sugiere el nombre, estos son el trabajo real realizado por el equipo de scrum para realizar su tarea y llevar la historia del usuario al estado 'Listo'.

# 3) Standup diario

Durante el ciclo de sprint, todos los días el equipo de scrum se reúne por no más de 15 minutos (podría ser una llamada de pie, se recomienda tener durante el comienzo del día) y declare 3 puntos:

  1. ¿Qué hizo ayer el miembro del equipo?
  2. ¿Qué planeaba hacer el miembro del equipo hoy?
  3. ¿Algún impedimento (barricadas)?

Es el Scrum Master quien facilita este encuentro. En caso de que algún miembro del equipo se enfrente a algún tipo de dificultad, el scrum master hace un seguimiento para resolverlo. En Stand ups, el tablero también se revisa y en sí mismo muestra el progreso del equipo.

# 4) Reunión de revisión

Al final de cada ciclo de sprint, el equipo de SCRUM se reúne nuevamente y demuestra las historias de usuario implementadas al propietario del producto. El propietario del producto puede verificar las historias según sus criterios de aceptación. Nuevamente, es responsabilidad del Scrum Master presidir esta reunión.

También en la herramienta SCRUM, el Sprint se cierra y las tareas se marcan como completadas.

# 5) Reunión retrospectiva

La reunión retrospectiva ocurre después de la reunión de revisión.

El equipo de SCRUM se reúne, discute y documenta los siguientes puntos:

  • ¿Qué salió bien durante el Sprint (mejores prácticas)?
  • ¿Qué no salió bien en el Sprint?
  • Lecciones aprendidas
  • Elementos de acción.

El equipo Scrum debe continuar siguiendo las mejores prácticas, ignorar las 'no mejores prácticas' e implementar las lecciones aprendidas durante los sprints posteriores. La reunión retrospectiva ayuda a implementar la mejora continua del proceso SCRUM.

¿Cómo se realiza el proceso? ¡Un ejemplo!

Habiendo leído sobre las jergas técnicas de SCRUM. Permítanme intentar demostrar todo el proceso con un ejemplo.

Ejemplo:

Paso 1 : Tengamos un equipo SCRUM de 9 personas compuesto por 1 propietario de producto, 1 Scrum Master, 2 probadores, 4 desarrolladores y 1 DBA.

Paso 2 : Se decide que el Sprint siga un ciclo de 4 semanas. Así que tenemos un Sprint de 1 mes a partir del 5 de junio al 4thde julio.

Paso 3 : El propietario del producto tiene la lista priorizada de historias de usuario en la cartera de pedidos del producto.

Paso 4: El equipo decide reunirse el 4thJunio ​​para la reunión de “Planificación previa”.

  • El propietario del producto toma 1 historia de la cartera de productos, la describe y deja que el equipo haga una lluvia de ideas sobre ella.
  • Todo el equipo discute y se comunica directamente con el propietario del producto para comprender claramente la historia del usuario.
  • De manera similar, se toman varias otras historias de usuarios. Si es posible, el equipo puede seguir adelante y dimensionar las historias también.

Después de toda la discusión, los miembros individuales del equipo regresan a sus estaciones de trabajo y

  • Identifique sus tareas individuales para cada historia.
  • Calcula el número exacto de horas en las que trabajarán. Veamos cómo concluye el miembro este horario.

Número total de horas de trabajo = 9
Menos 1 hora para un descanso, menos 1 hora para reuniones, menos 1 hora para correos electrónicos, discusiones, resolución de problemas, etc.
Entonces, las horas de trabajo reales = 6.
Un número total de días laborables durante el Sprint = 21 días.
Número total de horas disponibles = 21 * 6 = 126.
El miembro está de licencia por 2 días = 12 horas (Esto varía para cada miembro, algunos pueden tomar licencia y otros no).
Número de horas reales = 126 - 12 = 114 horas.

Esto significa que el miembro estará disponible durante 114 horas para este sprint. Así que desglosará su tarea de sprint individual de tal manera que se alcance un total de 114 horas.

Paso # 5 : El 5thde junio todo el equipo Scrum se reúne para la “Reunión de planificación”.

  • Se realiza el veredicto final de la historia del usuario de la cartera de pedidos del producto y la historia se mueve a la cartera de Sprint.
  • Para cada historia, cada miembro del equipo declara sus tareas identificadas, si es necesario, pueden tener una discusión sobre esas tareas, pueden dimensionarlas o redimensionarlas (¡recuerde la serie de Fibonacci!).
  • El Scrum Master o el equipo ingresan sus tareas individuales junto con sus horas para cada historia en una herramienta.
  • Una vez completadas todas las historias, Scrum Master toma nota de la Velocidad inicial y comienza formalmente el Sprint.

Paso # 6 : Una vez que el Sprint ha comenzado, según las tareas asignadas, cada miembro del equipo comienza a trabajar en esas tareas.

Paso # 7 : El equipo se reúne todos los días durante 15 minutos y discute 3 cosas:

  • ¿Qué hicieron ayer?
  • ¿Qué planean hacer hoy?
  • ¿Algún impedimento (barricadas)?

Paso # 8 : El Scrum Master realiza un seguimiento diario del progreso con la ayuda de 'Burn down chart'.

Paso # 9 : En caso de cualquier impedimento, el Scrum Master realiza un seguimiento para resolverlo.

Paso # 10 : El 4thJulio, el equipo se reúne nuevamente para la reunión de revisión. Un miembro muestra la historia de usuario implementada al propietario del producto.

Paso # 11 : El 5thJulio, el Equipo se reúne nuevamente para la Retrospectiva, donde discuten

  • ¿Qué salió bien?
  • ¿Qué no salió bien?
  • Elementos de acción.

Paso # 12 : El 6thEn julio, el equipo se reúne nuevamente para una reunión de planificación previa para el próximo sprint y el ciclo continúa.

proceso de metodología ágil scrum

Herramientas de actividad SCRUM

Hay varias herramientas que se pueden utilizar ampliamente para realizar un seguimiento de las actividades de scrum.

Algunos de ellos incluyen:

En el próximo tutorial, arrojaremos luz sobre el Manifiesto Ágil, que es una noción que impulsa los Equipos Ágiles efectivos.

Siguiente tutorial

Sobre los autores: Esta serie está escrita por los siguientes miembros del equipo de STH: Shruti Shrivastava - Un Scrum Master profesional con 9 años de experiencia en dominios BFSI, comercio electrónico y B2B. Shruti es un experto en pruebas de automatización y lidera equipos de scrum.

Anshul Kumar Srivastava: un profesional de gestión de productos orientado a resultados y un practicante ágil con 7 años de experiencia en los sectores de BFSI y telecomunicaciones.

Lectura recomendada

^