EniunEniunEniunEniun
  • Inicio
  • Servicios
    • Desarrollo Web
    • Diseño Web
    • Marketing Digital
    • Social Media
    • Experiencia de usuario
  • Nosotros
  • Diseño de Interfaces Web
  • Blog
  • Contacto
✕
            No results See all results
            centrar horizontal verticalmente CSS
            Centrar horizontal y verticalmente en CSS un elemento
            01/11/2020
            indicadores clave en email marketing
            Indicadores clave en email marketing
            21/06/2021

            Metodología Scrum para el desarrollo de software ágil

            metodología scrum

            metodología scrum

            Tabla de contenidos

            • 1. Desarrollo ágil de software 
            • 2. Principios de la metodología ágil
            • 3. Metodología Scrum
            • 4. Roles – Scrum
              • 4.1. Product Owner
              • 4.2. Scrum Master
              • 4.3. Development team
            • 5. Artefactos – Scrum
              • 5.1. Product Backlog 
              • 5.2. Product backlog items 
              • 5.3. Historia de Usuario
              • 5.4. Estimación 
              • 5.5. Planning poker o Scrum poker
              • 5.6. Orden de los PBIs
              • 5.7. Tablero Scrum
            • 6. Ceremonias o reuniones
              • 6.1. Daily meeting (reunión diaria)
              • 6.2. Sprint Planning (planificación del sprint)
              • 6.3. Spring Review (revision de sprint)
              • 6.4. Sprint Retrospective (retrospectiva del sprint)
              • 6.5. Refinement (refinamiento)

            La metodología Scrum es una metodología de desarrollo ágil de software que ayuda a los equipos a desarrollar productos en periodos cortos, permitiendo obtener de forma rápida feedback por parte del cliente, adaptaciones y una mejora continuada.

            Para comprender a fondo qué es la metodología Scrum vamos a ver primero las características del desarrollo ágil de software y sus diferencias con respecto a la metodología tradicional.

            1. Desarrollo ágil de software 

            El desarrollo ágil de software o metodología ágil (Agile Methodology en inglés) es una metodología de desarrollo de software basada en el desarrollo iterativo e incremental, donde los requisitos y soluciones van evolucionando según las necesidades del proyecto. 

            En las metodologías ágiles la adaptación al cambio forma parte del proceso natural del proyecto.

            Hay muchas diferencias entre el desarrollo ágil de software y el método de desarrollo tradicional. Si nos centramos en las diferencias fundamentales cabe destacar lo siguiente:

            En la metodología tradicional, se define el proyecto desde el inicio y se crea un plan detallado con contratos estrictos. Sin embargo, en la metodología ágil se comienza definiendo las funcionalidades básicas del proyecto garantizando la entrega continua de software de valor que se va mejorando de forma continuada en cada iteración. En lugar de contratos estrictos, se mantienen reuniones constantes con el cliente y se adapta el proyecto a sus necesidades.

            Desarrollo ágil de software
            Figura 1. Comparativa entre la metodología ágil y la tradicional.

            2. Principios de la metodología ágil

            Las metodologías ágiles se basan en una serie de principios:

            1. Satisfacción del cliente mediante la entrega temprana y continua de software de valor.
            2. Gran aceptación y respuesta al cambio de los requisitos definidos.
            3. Entrega frecuente de software que funcione, normalmente en periodos de dos semanas hasta dos meses.
            4. Trabajo conjunto entre el equipo de negocio y los desarrolladores.
            5. Creación de equipos motivados y respaldados.
            6. Comunicación cara a cara.
            7. Equipos auto-organizados.
            8. Reflexión continua de formas para mejorar la efectividad y realizar los ajustes necesarios.

            3. Metodología Scrum

            Scrum es una metodología ágil que engloba una serie de principios que ayudan a los equipos a desarrollar productos en periodos cortos (llamados sprints), permitiendo obtener de forma rápida feedback, adaptaciones y una mejora continua.

            4. Roles – Scrum

            4.1. Product Owner

            • Es el más cercano al negocio/cliente.
            • Decide qué desarrollar y qué no.
            • Define buenas historias de usuario.
            • Gestiona el Product Backlog y se asegura que esté claro para todo el equipo.
            • Encargado del retorno de inversión del proyecto (ROI).
            • Define el producto mínimo viable (MVP).
            • Valida las entregas (sprint review).

            4.2. Scrum Master

            • Planifica la implantación de Scrum y se asegura de que todo el equipo lo entienda y lo aplique correctamente.
            • Ayuda a resolver los impedimentos que surjan durante el sprint.
            • Crea un buen ambiente en el equipo y favorece la auto-organización.
            • Protege al equipo de interferencias externas.
            • Ayuda al product owner a comprender la metodología ágil.
            • Se asegura de que se celebren las reuniones y de que se cumpla el objetivo en el tiempo establecido.

            4.3. Development team

            • Compuesto de 5 a 9 componentes.
            • Auto-organizado y auto-gestionado.
            • Decide la cantidad de trabajo a realizar en un sprint (sprint planning).
            • Estable, motivado y dedicado.
            • Se obtienen mejores resultados cuando trabajan en la misma localización física.

            5. Artefactos – Scrum

            5.1. Product Backlog 

            El product backlog o pila del producto es una lista ordenada y priorizada de funcionalidades definidas por el cliente.

            5.2. Product backlog items 

            Dentro del product backlog definiremos los elementos de la pila de producto o PBI (de sus siglas en inglés Product Backlog Item).

            Los elementos del product backlog suelen contener la descripción, el orden, la estimación y el valor. Además, también pueden disponer de otra información relevante como diagramas de uso, prototipos, datos de encuestas o gráficos. Sin embargo, lo más habitual es crear este listado de elementos con el formato de Historia de Usuario.

            5.3. Historia de Usuario

            Una historia de usuario (elemento de la lista del product backlog) es una característica o funcionalidad que tiene valor para el usuario final y es lo suficientemente pequeña para que pueda ser desarrollada en un sprint. El formato de Historia de Usuario es el siguiente:

            • Como <tipo de usuario>
            • Quiero <necesidad a implementar>
            • Para <funcionalidad>

            Un ejemplo aplicado podría ser:

            historia de usuario
            Figura 2. Ejemplo de historia de usuario

            5.4. Estimación 

            Cada historia de usuario del product backlog debe ser estimada. Lo importante de la estimación es la realización de una reunión para ver qué tipo de dificultades, problemas y riesgos pueden surgir durante el sprint. Se suelen tener en cuenta las siguientes características:

            • Esfuerzo: Cuánto tiempo llevará su desarrollo.
            • Complejidad: Cómo de difícil es.
            • Incertidumbre: Grado de inseguridad para su implementación.

            5.5. Planning poker o Scrum poker

            Para la realización de estimaciones se ideó el planning poker o scrum poker que ayuda a la estimación de la duración de las historias de usuario de forma rápida evitando largas discusiones por parte del equipo de desarrollo.

            El funcionamiento es muy sencillo: durante la estimación cada miembro del equipo dispone de un juego de cartas, y en la estimación de cada tarea, todos los miembros vuelven boca arriba la combinación que suma el esfuerzo estimado.

            Cada equipo puede utilizar un juego de cartas con las numeraciones adecuadas a la unidad de esfuerzo con la que trabajan, y el tamaño máximo de tarea que se va a estimar. Las tareas que exceden el tamaño máximo definido deben descomponerse en tareas de menor tamaño.

            Las dos variantes de planning poker más conocidas son las cartas con serie de Fibonacci y con tallas de ropa.

            5.5.1. Cartas basadas en la serie de Fibonacci

            A continuación se propone la operativa que se llevaría durante una reunión de estimación mediante cartas basadas en la serie de Fibonacci:

            1. Cada miembro dispone de un mazo de cartas. Cada componente dispone de un mazo de cartas con puntuación basada en la serie Fibonacci: 0, ½, 1, 2, 3, 5, 8, 13, 21, infinito.
            2. Cliente o Product Owner lee la historia. Las historias de usuario son explicadas por el cliente o por el Product Owner. El equipo de desarrollo debe realizar todas las preguntas necesarias para la estimación.
            3. El Development Team selecciona las cartas. Cada miembro del equipo de desarrollo selecciona una carta, sin mostrársela al resto.
            4. Se muestran las cartas. Todas las cartas se levantan a la vez.
            5. Argumentación de las diferencias. Se argumentan las diferencias entre las estimaciones más extremas.
            6. Nueva estimación. Se vuelve a realizar una nueva estimación hasta que se consiga un consenso
            Figura 3. Scrum planning poker – Fibonacci

            5.5.2. Cartas con talla de ropa

            El mecanismo es el mismo que mediante cartas con serie de Fibonacci. La diferencia es que en vez de utilizar números, se utilizan tallas de camiseta o de ropa. De esta forma se pueden definir otros valores diferentes que se pueden asociar a cada una de las cartas durante en la estimación.

            Scrum planning poker - Talla
            Figura 4. Scrum planning poker – Tallas

            5.6. Orden de los PBIs

            Los PBIs prioritarios deben estar situados en la parte superior del listado ya que son los primeros que se desarrollarán. De tal manera que, si al finalizar el sprint no se han completado todos los PBIs, serán los de menor importancia (los de abajo) los que no se hayan terminado.

            Para priorizar la importancia de los elementos de la lista se pueden utilizar diferentes técnicas. Una de las más destacadas es el método MoSCoW:

            M: Must have, elementos importantes que se deben desarrollar.

            S: Should have, elementos importantes que pueden esperar a otra iteración y que no son necesarios en la entrega actual.

            C: Could have, elementos que solo se tendrán en cuenta si hay tiempo suficiente. Son elementos deseables, pero no necesarios.

            W: Won’t have, elementos que seguro que no dará tiempo a desarrollar.

            5.7. Tablero Scrum

            El tablero Scrum es una herramienta para monitorizar la carga de trabajo y facilitar la sincronización diaria. El tablero se puede dibujar en una pizarra, colgar en un corcho o pegar en una pared. Además, existen numerosas herramientas online que permiten crear tableros Scrum de forma colaborativa y en tiempo real, como por ejemplo la herramienta Trello.

            6. Ceremonias o reuniones

            6.1. Daily meeting (reunión diaria)

            El objetivo de las reuniones diarias es la comunicación del equipo para resolver posibles barreras y tomar decisiones para asegurar la consecución de los objetivos del sprint. En las reuniones diarias cada miembro dispone de unos 2-3 minutos para responder a las siguientes preguntas:

            • ¿Qué hiciste ayer?
            • ¿Qué harás hoy?
            • ¿Tienes algún impedimento?

            6.2. Sprint Planning (planificación del sprint)

            El objetivo de la reunión es el de planificar la cantidad de trabajo que el equipo va a poder soportar durante el próximo sprint.

            La reunión de planificación responde a dos preguntas: 

            • ¿Qué puede entregarse en el sprint? El product owner detalla las funcionalidades que hay que desarrollar en este sprint.
            • ¿Cómo se realizará el trabajo? El equipo de desarrollo estudia las historias de usuario y estima el esfuerzo que será necesario. Para ello, se suele usar la técnica de planning poker.

            6.3. Spring Review (revision de sprint)

            El objetivo de la reunión es realizar una revisión del sprint para facilitar la retroalimentación de información y la colaboración.

            6.4. Sprint Retrospective (retrospectiva del sprint)

            El objetivo de esta reunión es el de analizar el trabajo realizado por el equipo y reflexionar sobre acciones de mejora. 

            6.5. Refinement (refinamiento)

            Es un proceso continuo donde se revisan y examinan diferentes elementos de la Pila de Producto. Este proceso puede hacerse en diferentes sesiones a lo largo del sprint o en una sola reunión. Sin embargo, resulta recomendable que se realice de forma frecuente.

            Compartir

            Módulo Diseño de Interfaces Web

            • UD1. Planificación de interfaces gráficas
            • UD2. HTML
            • UD3. CSS básico
            • UD4. CSS avanzado
            • UD5. Imágenes, licencias y software de gestión
            • UD6. Sonido, vídeo y animaciones
            • UD7. Plantillas y frameworks de desarrollo
            • UD8. Integración de contenido interactivo
            • UD9. Diseño de webs accesibles
            • UD10. Usabilidad web
            • Metodología Scrum

            Artículos recientes

            • Diseño orientado a la personalización de productos
            • ¿Qué es SQL y por qué deberías aprender a usarlo?
            • Principales tendencias en marketing digital para 2023
            • Formas de crear una tienda online
            • Qué significa el modo mantenimiento en una página web

            ENLACES

            • Nosotros
            • Contacto
            • Mapa del sitio
            • Blog

            CodePen

            codepen

            CURSOS

            • Diseño de Interfaces Web

            REDES SOCIALES

            NUESTRA MISIÓN

            Queremos que consigas tus objetivos y que tu proyecto llegue a todo el mundo de la manera más óptima. Tu éxito es nuestro deseo y pondremos en práctica toda nuestra experiencia para que lo consigas.

            Únete y recibe gratis contenido exclusivo



              © 2022 Eniun Diseño Web y Marketing Digital
              Política de privacidad y cookies
                          No results See all results