SPC Conocimientos Generales APF cheat sheet

Manifiesto Ágil (2001): 4 valores y 12 principios; los valores priorizan individuos, software funcionando, colaboración con el cliente y respuesta al cambio sobre procesos, documentación, contratos y planes.

Scrum: marco empírico basado en transparencia, inspección y adaptación; se implementa con 3 roles, 5 eventos y 3 artefactos.

Kanban: método de flujo continuo que visualiza el trabajo, limita el WIP y gestiona el flujo; no prescribe iteraciones ni roles específicos.

XP (Extreme Programming): prácticas como TDD, programación en parejas, integración continua y diseño simple; enfatiza la retroalimentación técnica.

Lean: origen en Toyota; sus principios incluyen eliminar desperdicios, crear valor, flujo, pull y mejora continua (kaizen).

Crystal: familia de metodologías adaptadas al tamaño del equipo y criticidad del proyecto; prioriza personas y comunicación sobre procesos.

SAFe, LeSS y Nexus son marcos de escalado; no son marcos ágiles base sino extensiones para múltiples equipos.

Regla de decisión: si el trabajo es complejo y cambiante, usar enfoque empírico (Scrum); si el flujo es predecible y continuo, Kanban.

Los 4 valores del Manifiesto Ágil: (1) Individuos e interacciones sobre procesos y herramientas; (2) Software funcionando sobre documentación extensiva; (3) Colaboración con el cliente sobre negociación contractual; (4) Respuesta ante el cambio sobre seguir un plan.

Aunque hay valor en los elementos de la derecha, se priorizan los de la izquierda.

Principio 1: satisfacer al cliente mediante entrega temprana y continua de software con valor.

Principio 3: entregar software funcionando con frecuencia, en escalas de tiempo cortas (semanas o meses).

Principio 5: construir proyectos en torno a individuos motivados; darles el entorno y apoyo necesarios.

Principio 7: el software funcionando es la medida principal de progreso.

Principio 11: los mejores requisitos, arquitecturas y diseños emergen de equipos auto-organizados.

Los valores de Scrum (compromiso, enfoque, apertura, respeto y coraje) complementan los valores ágiles y guían el comportamiento del equipo.

El Scrum Team es autogestionado y multifuncional; consta de Product Owner, Scrum Master y Developers (sin subequipos ni jerarquías).

Product Owner: maximiza el valor del producto; es el único responsable de gestionar y priorizar el Product Backlog.

Scrum Master: facilita los eventos, elimina impedimentos, asegura la adopción de Scrum y actúa como líder servicial; no es un jefe de proyecto.

Developers: crean el incremento, se auto-organizan y son responsables de estimar y comprometerse con el trabajo del Sprint.

Tamaño recomendado del Scrum Team: 10 o menos personas (idealmente 3-9); equipos más grandes requieren coordinación adicional.

El Product Owner puede delegar la gestión del backlog pero sigue siendo el responsable final.

El Scrum Master no tiene autoridad para asignar tareas ni para tomar decisiones de producto.

Regla de decisión: si hay conflicto sobre prioridades, el Product Owner decide; si es sobre cómo hacer el trabajo, deciden los Developers.

Los 5 eventos de Scrum: Sprint, Sprint Planning, Daily Scrum, Sprint Review y Sprint Retrospective.

El Sprint es un contenedor de todos los eventos; su duración es de 1 a 4 semanas (máximo un mes).

Sprint Planning: define qué se hará y cómo; responde a las preguntas ¿qué? y ¿cómo?; duración máxima de 8 horas para un Sprint de 4 semanas.

Daily Scrum: 15 minutos, para Developers; se inspecciona el progreso hacia el Sprint Goal y se adapta el plan.

Sprint Review: al final del Sprint; se inspecciona el incremento y se adapta el Product Backlog; duración máxima de 4 horas para un Sprint de 4 semanas.

Sprint Retrospective: inspecciona el proceso y el equipo; duración máxima de 3 horas para un Sprint de 4 semanas.

Los 3 artefactos: Product Backlog, Sprint Backlog e Incremento; cada uno tiene un compromiso: Product Goal, Sprint Goal y Definition of Done.

Definition of Done: acuerdo compartido que describe el estado de calidad del incremento; si no se cumple, el trabajo no se considera terminado.

El Product Backlog es una lista ordenada y emergente de lo que se necesita para mejorar el producto; su dueño es el Product Owner.

El refinamiento del backlog es el acto de descomponer y clarificar ítems; no es un evento formal de Scrum pero es continuo.

Las historias de usuario son descripciones cortas de una funcionalidad desde la perspectiva del usuario; suelen seguir el formato: Como [rol], quiero [acción] para [beneficio].

Criterios de aceptación: condiciones que debe cumplir una historia para ser aceptada; se definen antes de la implementación.

Priorización: se puede usar MoSCoW (Must, Should, Could, Won't), valor vs. esfuerzo, o el método de los 100 puntos.

El Sprint Goal es un objetivo único para el Sprint, acordado durante la Sprint Planning; da coherencia y enfoque.

El Product Goal describe un estado futuro del producto y sirve de guía para el equipo; es el compromiso del Product Backlog.

Regla de decisión: si un ítem del backlog no aporta valor claro, el Product Owner debe eliminarlo o repriorizarlo.

Un equipo de alto rendimiento se caracteriza por autogestión, confianza, comunicación abierta y mejora continua.

Las 5 disfunciones de un equipo (Lencioni): ausencia de confianza, miedo al conflicto, falta de compromiso, evitación de responsabilidad y desatención a resultados.

La facilitación efectiva incluye: definir objetivos claros, establecer reglas básicas, fomentar la participación equitativa y gestionar conflictos.

Técnicas de facilitación: brainstorming, dot voting, round-robin, 1-2-4-todos, y el uso de un parking lot para temas fuera de agenda.

El Scrum Master actúa como facilitador neutral; no debe imponer soluciones ni tomar partido.

La seguridad psicológica (Edmondson) es la creencia de que se puede hablar sin ser castigado; es clave para el alto rendimiento.

Regla de decisión: si el equipo no llega a consenso, se puede usar la votación por puntos o decidir posponer la decisión.

Un equipo de alto rendimiento tiene un propósito compartido y objetivos medibles; la retroalimentación regular es esencial.

Velocidad: cantidad de trabajo completado por Sprint (en puntos de historia o unidades acordadas); se usa para previsibilidad, no para comparar equipos.

Burndown chart: muestra el trabajo restante vs. tiempo; el burnup chart muestra el trabajo completado vs. alcance total.

Lead time: tiempo desde que se solicita hasta que se entrega; Cycle time: tiempo desde que se inicia hasta que se entrega.

Throughput: número de ítems completados en un período; WIP (trabajo en progreso) debe limitarse para mejorar el flujo (Ley de Little: Lead time = WIP / Throughput).

Calidad: la Definition of Done es el principal mecanismo de calidad; incluye pruebas, revisión y criterios de aceptación.

La mejora continua se basa en el ciclo PDCA (Plan-Do-Check-Act) y en la retrospectiva para identificar acciones.

Métricas de flujo: se usan en Kanban; el diagrama de flujo acumulado (CFD) visualiza cuellos de botella.

Regla de decisión: si el lead time aumenta, revisar el WIP y los cuellos de botella antes de añadir más trabajo.

El escalado ágil aplica principios ágiles a múltiples equipos; marcos comunes: SAFe, LeSS, Nexus, Scrum@Scale.

SAFe (Scaled Agile Framework): organiza equipos en Agile Release Trains (ART) y usa PI Planning (Planificación de Intervalo de Programa).

LeSS (Large-Scale Scrum): extiende Scrum a varios equipos con un solo Product Backlog y un Product Owner; enfatiza la simplicidad.

Nexus: marco de escalado de Scrum que añade un Nexus Integration Team para coordinar la integración.

La colaboración organizacional requiere alinear objetivos, eliminar silos y fomentar la comunicación entre equipos.

El rol de Release Train Engineer (RTE) en SAFe facilita el ART y elimina impedimentos a nivel de programa.

Regla de decisión: escalar solo cuando sea necesario; primero optimizar el equipo único antes de añadir capas de coordinación.

Los eventos de escalado incluyen Scrum of Scrums, PI Planning y reuniones de sincronización entre equipos.

El practicante ágil debe actuar con integridad, transparencia y honestidad en todas las interacciones.

Confidencialidad: proteger la información sensible del equipo y de la organización; no divulgarla sin autorización.

Respeto: tratar a todas las personas con dignidad, valorar la diversidad y evitar conductas discriminatorias.

Responsabilidad: cumplir los compromisos adquiridos y rendir cuentas por las decisiones y acciones.

Conflicto de intereses: declarar cualquier interés personal que pueda influir en las decisiones profesionales.

El Scrum Master debe modelar los valores de Scrum y promover un entorno seguro y ético.

Regla de decisión: ante un dilema ético, preguntarse si la acción es legal, justa y transparente; en caso de duda, consultar.

La conducta profesional incluye no plagiar, no falsear métricas y no presionar al equipo para obtener resultados a costa de la calidad.