SPC Conocimientos Generales APF key terms

Declaración de 2001 con cuatro valores y doce principios que priorizan personas, software funcionando, colaboración con el cliente y respuesta al cambio sobre documentación y planes rígidos.

Las cuatro preferencias del Manifiesto: individuos e interacciones, software funcionando, colaboración con el cliente y respuesta ante el cambio, sin negar el valor de lo que queda a la derecha.

Los doce enunciados que traducen los valores en conducta diaria: entregas tempranas y frecuentes, ritmo sostenible, simplicidad, equipos autoorganizados y mejora continua, entre otros.

Mentalidad que combina empirismo, colaboración y adaptación, aplicando ciclos cortos de aprendizaje en lugar de planes predictivos extensos y detallados.

Enfoque que basa las decisiones en lo observado y experimentado, reconociendo que el conocimiento llega con la experiencia y que los planes se ajustan con evidencia.

Pilar empírico que exige que el proceso, el trabajo y los impedimentos sean visibles y comprendidos igual por quienes entregan y quienes reciben el resultado.

Pilar empírico que consiste en revisar con frecuencia los artefactos y el progreso hacia la meta, con la cadencia suficiente para detectar desviaciones a tiempo.

Pilar empírico que lleva a ajustar el proceso o el producto cuando la inspección revela desviaciones inaceptables, minimizando la interferencia en el trabajo en curso.

Marco ligero en el que un equipo pequeño entrega incrementos de valor en ciclos cortos, usando roles, eventos y artefactos definidos para gestionar trabajo complejo.

Método de flujo que visualiza el trabajo en un tablero, limita el trabajo en curso y gestiona la entrega continua midiendo tiempos de ciclo y cuellos de botella.

Marco técnico ágil que agrupa prácticas como programación en pareja, desarrollo guiado por pruebas, integración continua y diseño simple para elevar la calidad del código.

Rol responsable de maximizar el valor del producto, ordenar el backlog y comunicar con claridad qué se necesita y por qué, con autoridad sobre el contenido y la prioridad.

Rol que sirve al equipo y a la organización eliminando impedimentos, facilitando los eventos y promoviendo las prácticas acordadas, sin dirigir el trabajo diario ni asignar tareas.

Miembros del equipo que crean el incremento utilizable en cada Sprint, se autoorganizan para elegir cómo hacer el trabajo y comparten la responsabilidad de la calidad.

Grupo reducido formado por Product Owner, Scrum Master y desarrolladores, con habilidades complementarias y responsabilidad colectiva sobre el resultado de cada Sprint.

Capacidad del equipo para decidir internamente cómo repartir el trabajo y resolver problemas técnicos, sin que una autoridad externa asigne tareas o métodos.

Iteración de duración fija, de una a cuatro semanas, durante la cual el equipo produce un incremento utilizable sin cambiar la meta acordada para ese ciclo.

Evento inicial del Sprint donde el equipo acuerda por qué es valioso el ciclo, qué elementos del backlog abordará y cómo organizará el trabajo para lograrlo.

Reunión breve de hasta quince minutos donde los desarrolladores inspeccionan el avance hacia la meta del Sprint y ajustan su plan para el día siguiente.

Evento al final del Sprint en el que el equipo muestra el incremento a las partes interesadas y recoge retroalimentación que alimenta el backlog del producto.

Evento de cierre del Sprint donde el equipo examina cómo trabajó junto, identifica causas de fricción y acuerda mejoras concretas para el siguiente ciclo.

Lista ordenada y en evolución de todo lo que podría mejorar el producto, con los elementos más valiosos o urgentes en la parte superior para su refinamiento.

Subconjunto del backlog del producto seleccionado para un Sprint, junto con el plan de trabajo suficiente para producir el incremento comprometido.

Propósito único y concreto que da coherencia al trabajo del Sprint y permite al equipo decidir qué elementos del backlog contribuyen a alcanzarlo.

Estado futuro deseado del producto que orienta la priorización del backlog y da sentido a las decisiones del Product Owner a medio plazo.

Resultado utilizable y potencialmente entregable que se suma a lo construido antes, cumpliendo la definición de terminado acordada por el equipo.

Acuerdo explícito sobre los criterios que debe cumplir un elemento para considerarse completo, lo que evita ambigüedad sobre la calidad del incremento.

Condiciones verificables que un elemento del backlog debe satisfacer para ser aceptado, escritas de forma que puedan comprobarse sin interpretación subjetiva.

Descripción breve de una necesidad desde la perspectiva de quien la usa, que expresa valor esperado y se complementa con criterios de aceptación verificables.

Actividad continua de revisar, aclarar, dividir y reordenar elementos del backlog para que estén listos cuando llegue el momento de planificarlos.

Proceso de ordenar el trabajo según valor, riesgo, urgencia o dependencias para decidir qué se aborda antes, manteniendo visible el criterio usado.

Beneficio observable que un resultado aporta a usuarios u organización, usado como criterio para elegir y ordenar el trabajo en lugar de la mera cantidad de tareas.

Cantidad de trabajo estimado completado por el equipo en un Sprint; sirve para prever capacidad interna, no para comparar equipos ni presionar rendimiento.

Unidad relativa y sin dimensión temporal que expresa esfuerzo, complejidad e incertidumbre de un elemento, calibrada por el propio equipo.

Representación del trabajo restante frente al tiempo disponible dentro de un Sprint o una entrega, útil para detectar tendencias y conversar sobre riesgos.

Cantidad de elementos iniciados y aún no terminados; mantenerla limitada reduce cambios de contexto y acorta el tiempo hasta la entrega de valor.

Regla que fija cuántos elementos pueden estar activos a la vez en una etapa del flujo, obligando a terminar antes de empezar y a exponer cuellos de botella.

Intervalo entre el inicio y la finalización de un elemento de trabajo, usado para evaluar la capacidad de respuesta del flujo y su previsibilidad.

Práctica de revisar de forma periódica cómo se trabaja, experimentar con cambios pequeños y medir su efecto antes de adoptarlos de forma permanente.

Acumulación de decisiones de diseño apresuradas que encarecen el mantenimiento futuro; se gestiona haciendo visible su costo y reservando capacidad para reducirla.

Obstáculo que frena el avance del equipo y que este no puede resolver por sí mismo; el Scrum Master facilita su eliminación con quienes tienen autoridad.

Conjunto de técnicas para guiar una conversación hacia un resultado acordado, cuidando la participación equilibrada y la claridad de decisiones y acuerdos.

Condición en la que el equipo tiene autoridad real para decidir sobre su trabajo y confianza organizacional para asumir el riesgo de esas decisiones.

Grupo con confianza mutua, propósito compartido y seguridad psicológica que entrega de forma sostenible y mejora su forma de trabajar de manera autónoma.

Clima en el que las personas pueden admitir errores, preguntar y discrepar sin temor a represalias, condición necesaria para aprender y detectar problemas a tiempo.

Personas o grupos afectados por el producto o con influencia sobre él; se les involucra de forma selectiva para obtener información útil sin convertir cada petición en requisito.

Conjunto de acuerdos que coordina varios equipos ágiles, definiendo cómo se alinean metas, dependencias y decisiones sin imponer control centralizado sobre el trabajo diario.

Relación en la que el avance de un equipo depende del trabajo de otro; se hace visible y se reduce mediante acuerdos, rediseño del trabajo o integración frecuente.

Grupo voluntario que comparte un oficio y aprende entre pares mediante encuentros regulares, generando estándares y conocimiento que atraviesan los equipos.

Conjunto explícito de expectativas de comportamiento profesional que orienta decisiones difíciles y sirve de referencia ante conflictos de interés o presiones indebidas.

Situación en la que un interés personal puede influir indebidamente en una decisión profesional; se gestiona declarándolo y apartándose de la decisión afectada.

Coherencia entre lo que se declara y lo que se hace, incluyendo reconocer límites de conocimiento, no exagerar resultados y corregir errores con transparencia.

Deber de proteger información del cliente o de la organización, usándola solo para el propósito autorizado y evitando exponerla en herramientas o conversaciones abiertas.

Práctica de comunicar con honestidad alcance, riesgos y fechas probables, evitando promesas basadas en certeza inexistente y corrigiendo desviaciones a tiempo.