Please enable JavaScript.

Coggle requires JavaScript to display documents.

SCRUM - Coggle Diagram

- - - - Cualquier persona conoce el estado del proyecto
    - - cualquier persona puede observar los requerimientos
    - - capacidad de reconocer cambios
      - implementarlos de forma más rápida
  - - - 100% en el objetivo
    - - cualquier miembro puede cumplir cualquier tarea
    - - todos enfocados en cumplir el objetivo
    - - dispuestos a escuchar aportes u observaciones
    - - buen trato y buena comunicación importantes
- - - - responsable de maximizar valor del producto
      - Características
        principales
        
        Dueño del producto
        
        Gestiona los requerimientos
        
        Atiende peticiones del cliente
      - Responsabilidades
        
        Maximiza el valor del producto entregado
        
        Es el único que gestionar el Product Backlog
        
        Decide en qué se va a trabajar y en qué orden
        
        Despeja dudas al equipo
        
        Explica en qué consiste cada funcionalidad del producto
        
        Encargado de que conozcan todos los elementos del Product Backlog
    - - promover y apoyar Scrum
      - Responsabilidades
        
        Con el Product Owner
        
        Facilita los eventos de Scrum
        
        Asegura que objetivos y alcance se entiendan
        
        Transmite conocimientes sobre Scrum y prácticas ágiles
        
        Con el Dev team
        
        Guía al equipo para ser autoorganizado y multifuncional
        
        Identifica líderes
        
        Ayuda a desarrollar productos
        
        Recuerda al equipo los objetivos
        
        Elimina impedimentos para el progreso del equipo
        
        Con la organización
        
        Lidera y guía a la organización de adopción de Scrum
        
        Trabaja con otros Scrum Master para incrementar la efectividad y ejecución de Scrum
    - - entrega continua de producto terminado
      - Autoorganizado
        
        saben qué y cómo van a hacer las cosas
        
        se autogestionan en roles y actividades internas
      - Multifuncional
        
        capaces de realizar cualquier actividad
      - No tienen títulos
        
        se tratan por igual
        
        Respeto y buscan consenso
        
        no hay jerarquías
      - No hay subequipos
        
        no existen grupos dentro del equipo
        
        Las actividades se asignan por igual
      - No se modifica el equipo
        
        Durante todo el sprint
        
        así nose afectan las actividades
  - - - Ritmo del Sprint
        
        Daily Stand-up
        
        ¿Qué es?
        
        Reunión de 15 min
        
        Solo el Dev Team
        
        Planificación de las siguientes 24 horas de trabajo
        
        Scrum Master la organiza
        
        A la misma hora
        
        Pueden existir invitados
        
        sin participar
        
        ¿Cómo hacerla?
        
        Se expone
        
        ¿Qué hice ayer?
        
        ¿Qué haré hoy?
        
        ¿Tengo algún impedimiento?
        
        Información compartida
        
        exclusiva de objetivos
        
        Discutir sobre tema
        específico
        
        agendar una reunión
        
        Beneficios
        
        Mejora comunicación del equipo
        
        Posible conocer y medir progreso
        
        Identificación de problemas
        
        puedan frenar avance
        
        Cómo va el proceso para alcanzar objetivo
        
        Sprint review
        
        Características
        
        Enfocada en la comunicación del cliente
        
        Informa y abierta al dialogo
        
        < 4h
        
        Al final
        
        Product Backlog actualizada
        
        Mostrar algo funcional
        
        no diapositivas
        
        ¿Qué es?
        
        Se muestra avances de la iteración
        
        Pueden ser varias sesiones
        
        Se lleva a cabo el último día
        
        Sprint
        Retrospective
        
        Características
        
        Reunión pasiba y productiva
        
        No se busca culpas
        
        < 3h - 1 mes
        ideal 15 - 30 min
        
        ¿Qué es?
        
        Renión interna
        
        Equipo Scrum
        
        Equipo se expresa libremente
        
        Elementos
        
        Herramientas
        
        Se tiene todo lo necesario para cumplir
        
        Relaciones
        
        ¿comunicación fluida o con problemas?
        
        Personas
        
        ¿cómo es la intracción con los integrantes?
        
        Procesos
        
        ¿se ajustan los procesos al desarrollo óptimo?
        
        Preguntas
        sugeridas
        
        ¿Qué hicimos bien?
        
        ¿Qué no hicimos tan bien?
        
        ¿Qué podemos mejorar?
        
        Sprint Planning
        
        ¿Qué es?
        
        Organizada por Scrum Master
        
        Presencial de preferencia
        
        Van todos los miembros del equipo
        
        Donde se definen las Historias a realizar
        
        Características
        
        Duración
        
        < 8h sprints de 4 semanas
        
        1h sprints de 2 semanas
        
        Funciones
        Scrum Master
        
        Encargado de realizar
        reunión. Lugar adecuado
        
        Debe tener todo para realizarce
        
        Acuerdos
        
        Nadie responde correos, SMS, calls, etc.
        
        Equipo concentrado
        
        Participación de todos
        
        Objetivos
        
        ¿qué se puede
        entregar al final?
        
        Trabajar en elementos prioritarios del Product Backlog
        
        Discutir objetivo a lograr
        
        Identificar la capacidad del equipo
        
        Conocer la velocidad de la última iteración
        
        ¿Cómo se logra
        hacer trabajo?
        
        Selecciona elementos
        
        Sprint Backlog
        
        Realizar estimación de esfuerzo
        
        Product Owner aclara cualquier duda
        
        Invitados que aporten valor
        
        cliente
        
        usuario final
        
        Proceso de
        Planeación
        
        Elementos
        
        Estimación
        
        Capacidad
        
        Objetivos
      - ¿Qué es?
        
        Periodo determindo
        
        se crea incremento
        
        Duración
        
        1 a 4 semanas
      - Característica
        
        Objetivo claro
        
        Cambios
        
        Negociados entre
        
        Dev Team
        
        Product Owner
        
        Objetivo obsoleto
        
        puede ser candelado por
        Prodcut Owner
      - Refinar Historias
        de Usuario
        
        Sesiones especiales
        
        Al menos 1 por Sprint
        
        A la mitad del Sprint
        
        Puede participar todo el equipo
        
        Product Owner está presente
        
        Preguntas previas
        
        Es claro el
        
        ¿por qué?
        
        ¿qué?
        
        ¿Contribuye a la visión
        del producto?
        
        Sino se desecha la idea
        
        ¿Agrega valor?
        
        Importancia de
        refinir
        
        Product Owner
        
        Analiza define que se va a trbajar
        
        Toda información necesaria disponible
        
        Detectar
        
        impedimentos
        
        dudas
        
        Product Owner responsable del “qué”
        
        equipo del “cómo”
        
        Lo primero que se redacta no siempre se entiende
      - Iteración se crea el incremento del producto
  - - - ¿Qué es?
        
        Lista ordenada
        
        necesaria para el proyecto
        
        Si hay cambios
        
        se añade a la lista
        
        Historia de Usuario no
        está en el backlog
        
        no existe
        
        Backlog es dinámico
        
        va evoucionando
        
        Elementos más
        prioritarios
        
        tienen descripción más completa
        
        Todo lo que se conoce necesario en el producto
      - Historias de
        Usuario
        
        ¿qué es?
        
        Son los elementos del Backlog
        
        Contiene la visión del usuario sobre la funcionalidad esperada del producto
        
        Contiene los Requerimiento: lo que quiere o espera el usario del producto
        
        El grupo se llama Épicas
        se agrupan en:
        
        En base a funcionalidades
        
        Módulos de producto
        
        Toman más de un sprint
        
        Conversaciones con el usuario, para conocer claramente lo que se desea intervenir
        
        Componentes
        
        Titulo
        
        Descipción de qué se trata la historia
        
        Debe ser clara y concreta
        
        Descripción
        
        Información de cómo
        ejecutar la tarea
        
        Ejemplo:
        
        Quiero: poder completar evaluaciones en la plataforma
        
        Como: estudiante
        
        Para: poder ser evaluado y tener una calificación
        
        Para qué
        
        Quiero realizar esta función
        
        se pide requerimiento
        
        Quiero
        
        qué fundionalidad está buscando
        
        qué quire el usuario
        
        Cómo
        
        quién es el usuario que cuenta la historia
        
        Quién va a realizar la acción
        
        Puntos
        
        Esfuerzo que se va a tomar el equipo
        
        Criterios de
        aceptación
        
        Requisitos para que
        la historia esté completa
        
        Calidad
        
        ¿qué se va a permitir?
        
        ¿qué no se va a permitir?
        
        Indentificar
        
        2 more items...
        
        Funcionalidad vs Expectativa
        
        ¿qué más necesita saber
        el equipo?
        
        conocer las experiencias de los colaboradores
        
        Planeación Historias
        de Usuario las 3C
        
        Conversation
        
        conversación del equipo sobre la historia
        
        se aclaran las dudas
        
        Confirmation
        
        todos llegan a un acuerdo
        
        confirman que entienen el contenido
        
        Cards
        
        tarjetas con los componentes de cada historia
        
        Una buena Historia
        
        I
        
        Independiente
        
        no debe depender de otras
        
        De depender debe estar marcado
        
        N
        
        Negociable
        
        Si es muy grande, negociar para dividirla
        
        V
        
        Valiosa
        
        debe hacer algo por la funcionalidad del producto
        
        Agregar valor
        
        E
        
        Estimable
        
        Poder estimar el esfuerzo para completar la historia
        
        S
        
        Small
        
        Suficientemente pequeña para cumplir una funcionalidad
        
        T
        
        Testable
        
        Verificar que se completo
        
        Criterio de aceptación
        
        Definición de completado
        
        Estimar Historias
        de Usuario
        
        Complejidad de
        la historia
        
        Definir qué tan difícil es la historia
        
        Cantidad de trabajo
        requerido
        
        Esfuerzo que debe invertir el equipo
        
        Conocimientos
        necesarios
        
        Habilidades técnicas, de diseño y de negocio, etc.
        
        Incertidumbre
        
        acciones necesarias para ejecutar la Historia
        
        Si no se tiene claro el tiempo o esfuerzo
        
        Poker de
        planeación
        
        Cartas para realizar la estimación
        
        Escala Finobacci
        
        2X
        
        Al final se verifica
        
        Velocidad
        
        Total de puntos de la historia
        completadas por equipo
        
        Capacidad
        
        total de historias que se
        pueden completar en un sprint
        
        Extra
        
        Avance Proyecto
        
        Gráfica de trabajo pendiente
        Bourn Down Chart
        
        Visualizar la velocidad de avance
        
        Visible el trabajo pendiente
        
        Bournup Chart
        
        Trabajo completado durante el sprint
        
        Línea amarilla
        
        ideal de puntos a alcanzar
        
        Gráfica de flujo
        acumulado
        
        Histórico de los Sprint anteriores
        
        Fracaso al
        implementar HU
        
        Subestimación de
        la simplicidad
        
        entender el para qué
        
        Scrum no son solo HU
        
        Falla la simplicidad
        
        diferencia entre épica e historia
        
        Estrategias de habilitación
        para HUs
        
        Objetivos de negocio
        
        todos deben comprender cómo impacta al negocio el retrabajo
        
        Requerimientos técnicos
        
        qué se necesita (tecnología) para entregar el producto
        
        Requerimientos de transición
        
        comprobaciones para indicar que se terminó o se entregó
        
        Entendimiento del problema
        
        ¿qué solución se está implementando?
        
        ¿Qué problema se está resolviendo?
        
        ¿Cómo se optimizan
        las HU?
        
        Aportación al negocio
        
        Monetario
        
        reducción tiempo o costo
        
        integración con algún tipo de tecnología
        
        Aportación al usuario
        
        mejorar interfaz
        
        funcionalidad que premia el usuario
        
        Entender cuál aporta más
        en este momento
        
        cuál no aporta
        
        cuál puede esperar
        
        Primeros pasos para
        habilitar HU
        
        Identificar barreras en ti
        
        habilidad
        
        negociación
        
        comunicación
        
        redacción
        
        conocimiento
        
        qué otras cosas debemos conocer para proponer el cambio
        
        Recomendaciones
        generales
        
        Cambia la forma de conversar
        
        Cambia la forma de gestionar
        
        Incluir
        
        valor
        
        calidad
        
        factibilidad
        
        Escuchar con atención
        
        preguntar más
        
        Trabajar por timebox
        
        Baja tu nivel de lenguaje técnico
        
        Baja tu Ego
        
        tener empatía
        
        Identificas barreras
        en tu equipo/empresa
        
        Costumbre de los casos de uso
        
        Resistencia al contexto en partes
    - - Detalles
        
        Plan detallado
        
        equipo tiene capacidad de comprenderlo
        
        Todo el equipo tiene conocimiento del Sprint Backlog
        
        Dueños del Sprint Backlog
        Dev Team
        
        potestad para aceptar o no agregar elementos
        
        Elementos innecesarios
        
        se los puede sacar
        
        Product Owner
        
        Negocia poder bajar prioridad de una historia o eliminarla
      - Prioridades
        
        Valor para el cliente
        
        historias que añadan valor
        
        Urgencia
        
        cuando tiene fecha límite
        
        Riesgo /
        oportunidad
        
        Impacto que la historia tiene en el avance
        
        Esfuerzo
        
        que tanto esfuerzo requiere
      - elementos que se trabajarán en el sprint
- - - - coordinan esfuerzos de diferentes equipos
  - - - poder de decisión
      - Compromisos a nombre del equipo
- - - - procesos y herramientas
    - - documentación extensiva
    - - Negociación contractual
    - - seguir un plan
  - - - entrega temprana y continua
    - - en cualquier etapa del proyecto
    - - producto funcionando en un periodo corto
    - - entre miembros del equipo y el cliente
    - - buen entorno de trabajo
      - independencia del equipo (toma de decisiones)
    - - optimiza la colaboración
    - - software funcional señal de progreso
    - - debe ser constante
    - - excelencia técnica
      - buen diseño
    - - requerimientos bien definidos
      - alcance claro
    - - equipos capaces e independientes
    - - equipo ajusta y perfecciona su comportamiento
- - - - ¿Qué nos gusta?
    - - ¿Cómo lo compartimos?
      - ¿Cómo lo practicamos?
    - - ¿a quién más le interesa?
  - - - Enfocadas a la especialización
    - - Crear una comunidad sobre un tema
      - Crear una comunidad sobre un tema