Please enable JavaScript.

Coggle requires JavaScript to display documents.

Metodologías ágiles (Eventos 7 (Scrum diario :calendar: (Planning Poker …

- - - - Propietario del producto
      - Otros interesados también pueden asistir
      - Equipo completo de desarrollo
    - - Objetivo del sprint
      - Elementos de la pila de producto a ejecutar
      - Pila de sprint con todas las tareas estimadas
      - Duración del sprint y fecha de la reunión de revisión
  - - - Análisis del incremento y adaptación de la pila de producto si es necesario
      - < 4 horas para sprints largos (1 mes)
      - Resultados
        
        Feedback para el propietario del producto
        
        Información para mejorar la visión del producto
        
        Convocatoria de siguiente reunión de planificación de sprint
  - - - Trabajo realizado el día anterior.
      - Trabajo que tiene previsto realizar ese día.
      - Necesidades a cubrir o impedimentos a salvar para poder realizarse el trabajo.
    - - Monitoriza el sprint: figura el trabajo pendiente (no el realizado)
      - Se detecta el ritmo de avance para detectar si vamos en tiempo, se va a adelantar o retrasar la entrega del sprint
    - - Todo el equipo de desarrollo de forma obligatoria
      - Otros interesados opcionalmente
    - - Práctica ágil
      - Soporte para reuniones donde se estima
        
        Esfuerzo :weight_lifter:
        
        Duración de tareas :timer_clock:
      - Intenta evitar discusiones dilatadas que no dan conclusiones concretas
      - Cada participante tiene 1 juego de cartas
      - Valores
        
        0, ½, 1, 2, 3, 5, 8, 13, 21
        
        ∞ = la tarea requiere más horas del tamaño máximo para una tarea
        
        ? = no puedo estimar el esfuerzo
        
        = necesidad de descanso
      - Operativa
        
        Para cada tarea (historia de usuario o funcionalidad, según sea el nivel de requisitos que se va a estimar) el cliente, moderador o propietario del producto expone la descripción empleando un tiempo máximo.
        
        Hay establecido otro tiempo para que el cliente o propietario del producto atienda a las posibles preguntas del equipo.
        
        Cada participarte selecciona la carta, o cartas que representan su estimación, y las separa del resto, boca abajo.
        
        Cuando todos han hecho su selección, se muestran boca arriba.
        
        Si estimación = ∞ (por sobrepasar el límite máximo establecido) :arrow_right: dividir tarea en sub-tareas de menor tamaño.
        
        Si las estimaciones resultan muy dispares, quien asume la responsabilidad de gestionar la reunión, con su criterio de gestión, y basándose en las características del proyecto, equipo, reunión, nº de elementos pendientes de evaluar, puede optar por
        
        Preguntar a las personas de las estimaciones extremas: ¿Por qué crees que es necesario tanto/tan poco tiempo? Tras escuchar las razones, repetir la estimación.
        
        Dejar a un lado la estimación de esa tarea y retomar al final o en otro momento aquellas que hayan quedado pendientes.
        
        Pedir al cliente o propietario del producto que descomponga la funcionalidad y valorar cada una de las funcionalidades resultantes.
        
        Tomar la estimación menor, mayor, o la media
      - Protocolo de moderación
        
        Evita en la reunión los atascos de análisis circulares en ping-pong entre diversas opciones de implementación,
        
        Hace participar a todos los asistentes
        
        Reduce el cuarto de hora o la media hora de tiempo de estimación de una funcionalidad, a escasos minutos
        
        Consigue alcanzar consensos sin discusiones
        
        Resulta divertido y dinamiza la reunión
- - - - Ordenadas por la prioridad que el cliente otorga
      - Requisito escrito en 1 o 2 frases utilizando lenguaje común del usuario
        Como [rol de usuario] quiero [objetivo] para poder [beneficio]
    - - Más prioritarios le dan más valor al producto o resultan más necesarios
      - Preparados o accionables se seleccionan en la reunión de planificación del sprint
    - - Dan una visión del producto definida y conocida por todo el equipo
      - Están definidas, priorizadas y pre-estimadas
    - - Id único
      - Descripción de la funcionalidad / requisito
      - Sistema de priorización
      - Esfuerzo necesario
      - Observaciones, criterio de validación, persona asignada, nº de sprint, módulo al que pertenece
  - - - Monitorizar el avance a diario
      - Identificar los riesgos y problemas de forma fácil
- - - - Persona responsable de lograr el mayor valor de producto para clientes, usuarios y demás implicados
      - Toma las decisiones del cliente
      - 1 sola persona :arrow_right: simplifica la comunicación y la toma de decisiones :silhouette:
      - Decide el resultado final y el orden en el que se construyen los incrementos :arrow_right: pila de producto y prioridades
      - Conoce el plan del producto, sus posibilidades, plan de inversión y ROI (retorno de la inversión) esperado
      - Se responsabiliza de fechas y funcionalidades
    - - Grupo de profesionales multifuncional que realizan el incremento de cada sprint
      - Tamaño recomendado = 3-8 personas (no incluye al scrum master ni propietario del producto)
      - Responde en su conjunto con responsabilidad solidaria, trabaja de forma cohesionada y autoorganizada
      - No hay un gestor para delimitar, asignar y coordinar tareas
      - Se comporta como un equipo
        
        Equipo = espíritu de colaboración y propósito común (conseguir el mayor valor posible para la visión del cliente)
        
        Todos conocen y comprenden la visión del producto owner
        
        Colaboran con él en el desarrollo de la pila de producto
        
        Comparten el objetivo de cada sprint y la responsabilidad del logro
        
        Todos participan en las decisiones, conocen el modelo de trabajo de scrum y se respetan sus opiniones y aportaciones
- - - - Se logran los objetivos del proyecto
      - No se pueden cumplir los objetivos con los recursos del proyecto
      - Ya no existe la necesidad que dio origen al proyecto
    - - Aplicación de conocimientos, habilidades, herramientas y técnicas para que se lleven a cabo las actividades del proyecto, cumpliendo con los requisitos del mismo y teniendo en cuenta sus recursos :female-police-officer::skin-tone-2:
- - - - Determinar lo antes posible
        
        Alcance del proyecto
        
        Tiempo
        
        Costo
      - Atraviesa fases secuenciales o superpuestas
        
        Enfocadas a un subconjunto de actividades
        
        Trabajo diferente en cada fase, requiriendo tareas y habilidades distintas
    - - Dentro de las fases del proyecto o iteraciones se repiten de forma intencionada una o más actividades del proyecto, de forma que el entendimiento del producto por parte del equipo aumenta
      - En cada iteración aumenta la funcionalidad y se completan entregables, que mejoran en la siguiente iteración o se crean nuevos
      - Durante cada iteración se planifica la siguiente
      - Para objetivos y alcances cambiantes o cuando la entrega parcial de un producto beneficia y genera valor para uno o más interesados sin afectar al entregable final
    - - Niveles altos de cambio y a la participación continua de los interesados
        
        Clientes/usuarios involucrados para proporcionar retroalimentación sobre los entregables y garantizar que el trabajo pendiente sigue reflejando sus necesidades actuales
      - Como los iterativos o incrementales, pero con iteraciones muy rápidas (2-4 semanas)
      - Alcance global
        
        Conjunto de requisitos
        
        Trabajos a realizar (pila de producto)
      - Al final de cada iteración :arrow_right: producto listo para que el cliente lo revise, sin características incompletas o inutilizables (el cliente no tiene porque aceptarlo)