1. INTRODUCCIÓN: DE LA PLANIFICACIÓN PREDICTIVA A LA ADAPTACIÓN

El desarrollo ágil de software no es una técnica única ni una receta cerrada, sino un enfoque de gestión y construcción de productos digitales que busca entregar valor de manera temprana, aprender mediante resultados observables y adaptar tanto el producto como la forma de trabajo. La agilidad surge como respuesta a una realidad recurrente en los sistemas de información: al inicio de un proyecto existe incertidumbre sobre las necesidades reales, la solución tecnológica, las prioridades, la respuesta de los usuarios y los cambios del entorno. Pretender eliminar esa incertidumbre mediante un plan exhaustivo puede producir una apariencia de control, pero no garantiza que el resultado final resuelva el problema correcto.

Los modelos predictivos, entre ellos el ciclo en cascada, son adecuados cuando el trabajo es estable, repetible y suficientemente conocido. En ellos se intenta definir el alcance al principio, descomponerlo en fases secuenciales y ejecutar el plan con el menor número posible de desviaciones. Este enfoque continúa siendo útil en determinadas actuaciones: migraciones con pasos conocidos, renovación de infraestructuras, implantaciones reguladas o proyectos en los que el coste de modificar una especificación física es muy elevado. El error consiste en convertirlo en la única forma de abordar cualquier iniciativa de software, incluso cuando las necesidades evolucionan y la solución debe descubrirse progresivamente.

En un enfoque adaptativo, la planificación no desaparece; cambia su naturaleza. Se planifica con mayor detalle el horizonte próximo y con menor detalle el horizonte lejano. Se formulan hipótesis, se construyen incrementos pequeños, se obtiene retroalimentación y se revisan las decisiones. La unidad de progreso deja de ser el porcentaje declarado de documentos o tareas y pasa a ser el resultado utilizable: un incremento de producto que funciona, cumple los criterios de calidad y permite validar si se está generando valor. Esta idea es esencial para el examen: ágil no significa improvisado, carente de arquitectura o sin documentación; significa aplicar planificación continua, transparencia, inspección y adaptación.

La entrega incremental reduce varios riesgos. En primer lugar, limita el volumen de inversión comprometido antes de recibir evidencia. En segundo lugar, permite descubrir errores de interpretación cuando todavía son baratos de corregir. En tercer lugar, hace visible el trabajo y facilita que las personas interesadas ordenen prioridades reales, no prioridades hipotéticas. Finalmente, favorece la calidad técnica porque la integración, las pruebas y la puesta en funcionamiento se realizan con mayor frecuencia, evitando una gran fase final en la que confluyen todos los problemas.

Debe distinguirse entre iterativo e incremental. El desarrollo es iterativo cuando una solución se revisa y mejora en ciclos sucesivos; es incremental cuando cada ciclo añade una porción terminada y utilizable. Muchos enfoques ágiles combinan ambas propiedades: se amplía el producto mediante incrementos y, al mismo tiempo, se revisan decisiones anteriores a la luz del aprendizaje. Un prototipo desechable puede ser iterativo sin constituir un incremento productivo; una entrega de módulos independientes puede ser incremental sin revisar suficientemente el diseño global.

También es necesario separar proyecto y producto. Un proyecto tiene normalmente un inicio, un fin, un presupuesto y unos entregables. Un producto digital mantiene una relación continuada con usuarios y necesita evolucionar durante todo su ciclo de vida. Scrum, Kanban y DevOps se entienden mejor desde la perspectiva de producto: el equipo no se limita a entregar código, sino que procura resultados, opera el servicio, aprende de su uso y gestiona su sostenibilidad. En una Administración sanitaria, esa visión es especialmente relevante porque muchas aplicaciones son servicios permanentes y críticos, no entregables que desaparecen al terminar un contrato.

2. FILOSOFÍA, EMPIRISMO Y PENSAMIENTO SISTÉMICO

2.1. Valor, aprendizaje y reducción de riesgo

La filosofía ágil parte de que el valor no se deduce exclusivamente de una especificación inicial. Una funcionalidad puede estar correctamente construida y, sin embargo, no mejorar el resultado que interesa. Por ello, el trabajo debe conectarse con necesidades, objetivos y resultados medibles. En términos de producto, una salida u output es lo que el equipo fabrica —por ejemplo, una pantalla o una API—, mientras que un resultado u outcome es el cambio producido —por ejemplo, menos errores de registro, menor tiempo de respuesta o mejor accesibilidad—. La agilidad madura evita confundir volumen de producción con valor.

El aprendizaje se obtiene mediante ciclos de hipótesis, implementación, observación y adaptación. Cuanto mayor sea el lote de cambio, más tiempo transcurre antes de recibir información y más difícil es aislar la causa de un problema. Los lotes pequeños reducen el coste de coordinación, simplifican las pruebas, disminuyen el riesgo de despliegue y permiten revertir con mayor facilidad. No obstante, «pequeño» no significa arbitrariamente fragmentado: cada incremento debe conservar coherencia funcional y técnica.

La priorización se apoya en el valor, el riesgo, el coste del retraso y la dependencia. Una característica valiosa y arriesgada suele explorarse pronto para evitar que la incertidumbre permanezca oculta. El coste del retraso expresa la pérdida causada por posponer una capacidad; puede relacionarse con impacto asistencial, cumplimiento, ahorro, seguridad o experiencia del usuario. Estas consideraciones permiten ordenar el trabajo de forma más racional que una lista fija elaborada meses antes.

2.2. Empirismo: transparencia, inspección y adaptación

El empirismo sostiene que el conocimiento procede de la experiencia y de decisiones basadas en lo observado. En Scrum se concreta en tres pilares: transparencia, inspección y adaptación. La transparencia exige que el estado del producto y del trabajo sea comprensible para quienes toman decisiones. No basta con disponer de datos; deben existir definiciones compartidas, como qué significa que una tarea está iniciada, terminada o bloqueada. La inspección contrasta periódicamente el resultado con los objetivos. La adaptación modifica el producto, el plan o el proceso cuando la evidencia indica una desviación o una oportunidad.

Estos pilares se refuerzan mutuamente. Inspeccionar información incompleta conduce a conclusiones erróneas; disponer de transparencia sin inspeccionar genera burocracia pasiva; inspeccionar sin capacidad de adaptación convierte las reuniones en rituales. La agilidad no reside en celebrar eventos, sino en cerrar este ciclo de control empírico con suficiente frecuencia y honestidad.

2.3. Autoorganización, equipos multifuncionales y liderazgo

Los equipos ágiles asumen responsabilidad sobre cómo organizar el trabajo. Autoorganización no equivale a ausencia de dirección, límites o rendición de cuentas. La organización establece propósito, políticas, restricciones, estándares y resultados esperados; el equipo decide cómo convertirlos en un incremento. La autonomía eficaz requiere competencias, información, herramientas y capacidad real de decisión. Delegar sin proporcionar estas condiciones es abandono, no agilidad.

Un equipo multifuncional reúne las capacidades necesarias para producir valor sin depender de transferencias constantes entre silos. No significa que todas las personas sepan hacer todo al mismo nivel. Significa que, colectivamente, el equipo puede analizar, diseñar, construir, probar, desplegar y aprender. La colaboración reduce colas entre especialidades y evita que el trabajo se optimice localmente —por ejemplo, desarrollo produce muchas funcionalidades mientras pruebas acumula una cola imposible de absorber—.

El liderazgo cambia desde la asignación detallada de tareas hacia la creación de contexto: definir objetivos, eliminar impedimentos sistémicos, desarrollar competencias, proteger la calidad y facilitar decisiones. El liderazgo de servicio, asociado a Scrum Master y a otras funciones facilitadoras, no supone pasividad. Exige intervenir sobre hábitos, políticas y estructuras que impiden la efectividad del equipo.

2.4. Pensamiento sistémico y optimización global

Un sistema de entrega incluye ideación, análisis, desarrollo, pruebas, seguridad, aprobación, despliegue, operación y soporte. Mejorar una fase aislada puede empeorar el conjunto. Si desarrollo aumenta su productividad local y genera más cambios de los que pruebas o explotación pueden absorber, crece el inventario, el tiempo de espera y el riesgo. Lean, Kanban y DevOps insisten en optimizar el flujo extremo a extremo, no la utilización máxima de cada recurso.

La variabilidad y las dependencias afectan al flujo. Cuando todas las personas están ocupadas al cien por cien, cualquier incidencia crea colas y retrasos. Limitar el trabajo en curso, reservar capacidad y reducir el tamaño de lote mejora el tiempo total de entrega. Este principio puede parecer contraintuitivo: iniciar menos trabajo permite terminar más trabajo relevante.

3. EL MANIFIESTO ÁGIL: CONTEXTO Y CUATRO VALORES

El Manifiesto para el Desarrollo Ágil de Software fue formulado en 2001 por diecisiete profesionales que representaban distintas corrientes de desarrollo ligero. No crearon una metodología universal; expresaron cuatro preferencias de valor y doce principios. Su formulación es deliberadamente comparativa: reconoce valor en los elementos situados a la derecha, pero concede mayor valor a los situados a la izquierda. Esta última frase evita interpretaciones extremas.

3.1. Individuos e interacciones sobre procesos y herramientas

Los procesos y las herramientas son necesarios para coordinar, automatizar y conservar conocimiento, pero no sustituyen la conversación, el criterio profesional ni la responsabilidad compartida. Un flujo perfectamente configurado en una herramienta no resuelve por sí solo una ambigüedad clínica, una dependencia entre equipos o una decisión de arquitectura. La preferencia por individuos e interacciones pide diseñar los procesos al servicio del trabajo, no convertir su cumplimiento mecánico en el objetivo.

Este valor tampoco justifica depender de héroes individuales ni ignorar la trazabilidad. Precisamente, la interacción debe generar acuerdos, decisiones visibles y conocimiento compartido. En equipos distribuidos, la comunicación puede apoyarse en videoconferencia, mensajería, documentación breve, tableros y repositorios. Lo relevante es reducir pérdidas de contexto y tiempos de espera, no idealizar un único canal.

3.2. Software funcionando sobre documentación extensiva

El software funcionando proporciona evidencia de integración y permite recibir retroalimentación. La documentación, por sí sola, puede describir una intención que todavía no ha superado restricciones técnicas ni pruebas reales. Por eso se valora más un incremento utilizable. Sin embargo, «software funcionando» no significa código que únicamente se ejecuta en el equipo del desarrollador: debe satisfacer la Definition of Done, estar probado, integrado, seguro y, cuando proceda, desplegable.

La documentación mantiene valor cuando facilita operación, mantenimiento, auditoría, formación, interoperabilidad o cumplimiento. En sistemas sanitarios y Administraciones públicas pueden ser imprescindibles registros de decisiones, modelos de datos, contratos de API, manuales, evidencias de pruebas, análisis de riesgos y documentación de seguridad. El criterio ágil es producir documentación suficiente, actualizada y útil, evitando documentos extensos cuyo coste no se corresponde con su utilización.

3.3. Colaboración con el cliente sobre negociación contractual

La negociación contractual define obligaciones y protege a las partes, pero no puede anticipar todo el aprendizaje de un producto complejo. La colaboración continua permite aclarar necesidades, ordenar prioridades, revisar incrementos y tomar decisiones sobre alcance. El «cliente» debe entenderse ampliamente como usuarios, responsables de producto, áreas de negocio, operación y demás interesados que aportan conocimiento o reciben valor.

En contratación pública, este valor no elimina la Ley de Contratos ni permite modificar libremente el objeto. Obliga a diseñar mecanismos compatibles con el marco jurídico: criterios de aceptación objetivos, entregas incrementales, backlog trazable, demostraciones, gobernanza conjunta y gestión formal de cambios. Un contrato puede fijar resultados, capacidades y límites sin pretender congelar cada detalle funcional.

3.4. Respuesta ante el cambio sobre seguir un plan

Los planes son hipótesis sobre el futuro. Su utilidad reside en orientar decisiones, no en impedir que se incorpore nueva información. Responder al cambio significa evaluar su valor y coste, reordenar prioridades y adaptar el camino sin perder el propósito. No significa aceptar cualquier petición de manera inmediata. Todo cambio compite por capacidad, puede afectar a riesgos y debe hacerse transparente.

La planificación ágil se realiza en varios niveles: visión y objetivos de producto, hoja de ruta, previsiones de entrega, objetivos de Sprint y planificación diaria. Los niveles lejanos expresan opciones e intención; los cercanos contienen compromisos más concretos. Esta planificación progresiva conserva dirección estratégica y evita la falsa precisión.

4. LOS DOCE PRINCIPIOS DEL DESARROLLO ÁGIL

Los doce principios desarrollan el sentido operativo de los cuatro valores. No constituyen una lista de ceremonias, sino criterios para evaluar si una forma de trabajo produce adaptación, valor y sostenibilidad. Conviene estudiarlos agrupados, porque así se comprende su lógica y se evitan respuestas memorizadas sin contexto.

4.1. Entrega de valor y aceptación del cambio

1. Satisfacer al cliente mediante entrega temprana y continua de software con valor. La prioridad no es completar un plan interno, sino resolver necesidades. «Temprana» reduce el tiempo hasta obtener evidencia; «continua» evita que el aprendizaje quede concentrado al final.
2. Aceptar cambios de requisitos incluso en etapas tardías. El cambio puede proporcionar ventaja si el diseño y la organización permiten incorporarlo. Aceptar no significa hacerlo gratis ni sin análisis; significa no tratar la información nueva como una anomalía que deba ocultarse.
3. Entregar software funcional frecuentemente. El Manifiesto cita periodos de semanas a pocos meses y prefiere el intervalo más corto. La frecuencia obliga a reducir tamaño de lote, automatizar y mantener calidad.

Estos tres principios conectan valor con realimentación. Una entrega frecuente que no llega a usuarios ni permite comprobar hipótesis puede ser solo actividad técnica. De la misma manera, aceptar cambios sin una arquitectura mantenible provoca degradación. La agilidad necesita capacidad técnica para sostener la adaptabilidad.

4.2. Colaboración, motivación y comunicación

1. Negocio y desarrollo trabajan juntos diariamente. No exige una reunión diaria formal entre todas las personas, sino disponibilidad y cooperación continuas para resolver decisiones.
2. Construir proyectos en torno a personas motivadas. Se proporciona entorno, apoyo y confianza. La motivación no sustituye recursos ni competencias; florece cuando existen propósito, autonomía y seguridad psicológica.
3. La conversación directa es el medio más eficaz de transmitir información. En 2001 se formuló como conversación cara a cara. En contextos distribuidos, el principio se conserva mediante comunicación síncrona de alta riqueza cuando el asunto lo requiere, complementada con documentación accesible.

La colaboración reduce el coste de transferencias. Cada paso entre silos genera esperas, reinterpretaciones y responsabilidad difusa. Un equipo estable desarrolla contexto compartido y puede tomar decisiones con menos latencia. No obstante, la colaboración debe preservar trazabilidad: las decisiones relevantes se registran para que puedan consultarse y auditarse.

4.3. Progreso, excelencia técnica y simplicidad

1. El software funcionando es la medida principal de progreso. Las métricas de actividad, como horas o tareas iniciadas, no demuestran valor. El incremento terminado ofrece una base más objetiva, aunque debe complementarse con resultados de usuario y calidad.
2. Promover un ritmo sostenible. Patrocinadores, desarrolladores y usuarios deberían poder mantener un ritmo constante. La sobrecarga crónica aumenta defectos, rotación y deuda técnica; puede producir velocidad aparente y pérdida posterior de capacidad.
3. Atención continua a la excelencia técnica y al buen diseño. Refactorización, pruebas automatizadas, integración frecuente, arquitectura evolutiva y revisión de código aumentan la capacidad de cambio. La calidad no se pospone a una fase final.
4. Simplicidad, arte de maximizar el trabajo no realizado. No es construir soluciones pobres, sino evitar características, abstracciones y procesos que todavía no aportan valor. Se relaciona con YAGNI —no implementar anticipadamente lo que quizá se necesite— y con reducción de desperdicio.

La simplicidad exige criterio. Eliminar una salvaguarda de seguridad o una prueba necesaria no es simplificar, sino trasladar riesgo al futuro. Una solución simple satisface requisitos relevantes con la menor complejidad accidental, conservando calidad, mantenibilidad y cumplimiento.

4.4. Autoorganización y mejora continua

1. Las mejores arquitecturas, requisitos y diseños emergen de equipos autoorganizados. «Emerger» no significa ausencia de arquitectura. Significa que el diseño se desarrolla y valida de forma continua por quienes integran conocimiento de producto y tecnología, dentro de principios y restricciones compartidos.
2. El equipo reflexiona regularmente y ajusta su comportamiento. La retrospectiva materializa este principio en Scrum, pero cualquier método necesita mecanismos de mejora. La reflexión debe producir cambios concretos, no limitarse a expresar opiniones.

5. SCRUM: DEFINICIÓN, TEORÍA, VALORES Y EQUIPO

Scrum es un marco de trabajo ligero para generar valor mediante soluciones adaptativas a problemas complejos. No define un proceso técnico completo ni prescribe cómo programar, probar o desplegar. Proporciona una estructura mínima de responsabilidades, eventos, artefactos y reglas dentro de la cual pueden emplearse prácticas de ingeniería, diseño, seguridad y gestión de producto. La guía oficial vigente continúa siendo la Scrum Guide de noviembre de 2020.

Scrum se basa en empirismo y pensamiento Lean. El empirismo aporta transparencia, inspección y adaptación; Lean reduce desperdicio y se centra en lo esencial. El trabajo se organiza en Sprints que contienen todos los eventos y producen al menos un Increment valioso y usable. El marco es deliberadamente incompleto: añadir prácticas es posible, pero cambiar sus elementos esenciales puede ocultar problemas y dejar de ser Scrum.

5.1. Valores de Scrum

Los cinco valores son compromiso, foco, apertura, respeto y coraje. El compromiso se dirige a objetivos y calidad, no a cumplir ciegamente una previsión. El foco concentra al equipo en el Sprint Goal y evita dispersión. La apertura hace visibles trabajo, riesgos y problemas. El respeto reconoce la capacidad profesional y las perspectivas de las personas. El coraje permite abordar problemas difíciles, decir que una previsión no es realista o detener una práctica que perjudica al producto.

Los valores no son un añadido cultural opcional. Facilitan el empirismo: sin apertura no hay transparencia; sin coraje no se adapta lo que falla; sin foco aumenta el trabajo en curso; sin respeto se ocultan errores; sin compromiso se diluyen los objetivos. Una evaluación madura de Scrum observa comportamientos y resultados, no solo calendarios de reuniones.

5.2. Scrum Team y accountabilities

La Scrum Guide 2020 utiliza el término accountabilities, que puede traducirse como responsabilidades o rendiciones de cuentas, y no presenta tres «roles» en sentido jerárquico. El Scrum Team está formado por un Product Owner, un Scrum Master y Developers. Es una unidad cohesionada, sin subequipos ni jerarquías internas, enfocada en un Product Goal. Es multifuncional y autogestionada: decide internamente quién hace qué, cuándo y cómo.

El tamaño habitual es de diez personas o menos. La guía no lo convierte en un límite matemático absoluto, pero explica que equipos más pequeños suelen comunicarse mejor y ser más productivos. Si el equipo crece demasiado, puede reorganizarse en varios Scrum Teams cohesionados que compartan producto, Product Goal, Product Backlog y Product Owner.

5.2.1. Product Owner

El Product Owner es responsable de maximizar el valor del producto resultante del trabajo. También responde de la gestión efectiva del Product Backlog: desarrollar y comunicar explícitamente el Product Goal, crear y comunicar los elementos del backlog, ordenarlos y asegurar que el backlog sea transparente, visible y comprendido. Puede delegar tareas, pero conserva la responsabilidad.

El Product Owner es una persona, no un comité. Puede representar necesidades de múltiples interesados, pero las decisiones sobre el Product Backlog deben respetarse. Esto no implica poder unilateral ilimitado: opera dentro de estrategia, presupuesto, regulación y gobernanza. Su autoridad efectiva es necesaria para evitar listas contradictorias y prioridades negociadas continuamente fuera del equipo.

5.2.2. Developers

Developers son las personas del Scrum Team comprometidas con crear cualquier aspecto de un Increment usable cada Sprint. Sus responsabilidades incluyen elaborar un plan para el Sprint —el Sprint Backlog—, incorporar calidad mediante la Definition of Done, adaptar diariamente el plan hacia el Sprint Goal y responsabilizarse profesionalmente entre sí. El término no se limita a programadores: puede incluir análisis, pruebas, UX, datos, seguridad u otras capacidades necesarias.

5.2.3. Scrum Master

El Scrum Master responde de establecer Scrum tal como se define en la guía y de la efectividad del Scrum Team. Ayuda a comprender teoría y práctica, facilita la eliminación de impedimentos, promueve autogestión y multifuncionalidad y asegura que los eventos sean positivos, productivos y se mantengan dentro de su timebox. También presta servicio al Product Owner y a la organización.

No es jefe del equipo, secretario de reuniones ni responsable de asignar tareas. Tampoco «elimina» personalmente todos los impedimentos: ayuda a que se resuelvan y actúa sobre los que exceden la capacidad del equipo. Su éxito se mide por la efectividad creciente del sistema, no por dependencia permanente de su intervención.

6. SCRUM: SPRINT Y EVENTOS FORMALES

Los eventos de Scrum crean regularidad y oportunidades formales de inspección y adaptación. Se realizan dentro del Sprint. Reducirlos a reuniones administrativas vacía su función. Cada evento tiene un propósito, participantes y timebox. Cuando el objetivo se alcanza antes, el evento puede terminar; el timebox representa duración máxima, no duración obligatoria.

6.1. El Sprint

El Sprint es el contenedor de todos los demás eventos. Tiene duración fija de un mes o menos y un nuevo Sprint comienza inmediatamente después del anterior. Durante el Sprint no se realizan cambios que pongan en peligro el Sprint Goal, no disminuye la calidad, el Product Backlog se refina según sea necesario y el alcance puede aclararse y renegociarse con el Product Owner a medida que se aprende.

La duración fija genera cadencia y limita riesgo. Un Sprint más corto ofrece retroalimentación más frecuente y menor exposición, pero aumenta el coste relativo de eventos y puede dificultar objetivos con dependencias. Un Sprint más largo proporciona más horizonte, aunque incrementa complejidad y riesgo. No se modifica su duración una vez iniciado para «dar tiempo» a terminar trabajo pendiente.

Solo el Product Owner tiene autoridad para cancelar un Sprint y puede hacerlo si el Sprint Goal queda obsoleto. La cancelación es excepcional y no se confunde con cambiar el plan. El trabajo terminado se revisa y los elementos incompletos vuelven a estimarse y al Product Backlog cuando corresponda.

6.2. Sprint Planning

La Sprint Planning inicia el Sprint y aborda tres temas: por qué es valioso el Sprint, qué puede hacerse y cómo se realizará el trabajo elegido. Todo el Scrum Team colabora. El Product Owner propone cómo aumentar valor; el equipo formula un Sprint Goal. Los Developers seleccionan elementos del Product Backlog y elaboran un plan. Para un Sprint de un mes, el timebox máximo es de ocho horas.

La previsión se basa en rendimiento pasado, capacidad, Definition of Done y comprensión del trabajo. Los Developers son responsables del dimensionamiento y de decidir cuánto pueden asumir. El resultado es el Sprint Backlog, no un contrato rígido. El plan se actualiza durante el Sprint, pero el Sprint Goal aporta estabilidad y coherencia.

6.3. Daily Scrum

El Daily Scrum es un evento de quince minutos para los Developers. Su propósito es inspeccionar el progreso hacia el Sprint Goal y adaptar el Sprint Backlog, produciendo un plan accionable para el siguiente día de trabajo. Se celebra en el mismo momento y lugar cada día laborable para reducir complejidad. Si Product Owner o Scrum Master trabajan activamente en elementos del Sprint Backlog, participan como Developers.

La guía no prescribe las tres preguntas «qué hice, qué haré y qué impedimentos tengo». Los Developers pueden elegir cualquier estructura que se centre en el Sprint Goal. Tampoco es un informe de estado al Scrum Master. Las conversaciones detalladas pueden continuar después con las personas necesarias.

6.4. Sprint Review

La Sprint Review inspecciona el resultado del Sprint y determina adaptaciones futuras. El Scrum Team presenta los resultados a interesados clave y analiza el progreso hacia el Product Goal, cambios del entorno y próximas oportunidades. No debe limitarse a una demostración ni a una aceptación formal. Es una sesión de trabajo en la que el Product Backlog puede adaptarse. Su timebox máximo es cuatro horas para un Sprint de un mes.

6.5. Sprint Retrospective

La Sprint Retrospective planifica formas de aumentar calidad y efectividad. El equipo inspecciona personas, interacciones, procesos, herramientas y Definition of Done; identifica supuestos, problemas y soluciones; y selecciona mejoras útiles. Las más impactantes se abordan cuanto antes e incluso pueden incorporarse al Sprint Backlog siguiente. Su timebox máximo es tres horas para un Sprint de un mes.

7. SCRUM: ARTEFACTOS, COMPROMISOS Y GESTIÓN DEL PRODUCTO

Los artefactos representan trabajo o valor y maximizan la transparencia. Cada uno contiene un compromiso que proporciona foco y una base de medición: el Product Backlog se asocia al Product Goal; el Sprint Backlog, al Sprint Goal; y el Increment, a la Definition of Done. Esta correspondencia es una de las novedades más relevantes de la Scrum Guide 2020.

7.1. Product Backlog y Product Goal

El Product Backlog es una lista emergente y ordenada de lo necesario para mejorar el producto y constituye la fuente única de trabajo del Scrum Team. «Emergente» significa que evoluciona con el aprendizaje; «ordenada» no equivale necesariamente a una prioridad numérica simple, pues puede considerar valor, riesgo, dependencia, coste y oportunidad.

El refinamiento descompone y define los elementos con mayor precisión, añadiendo descripción, orden y tamaño. Es continuo. Los elementos que pueden terminarse dentro de un Sprint se consideran preparados para selección, aunque Scrum no prescribe una Definition of Ready. Los Developers responsables del trabajo realizan el dimensionamiento; el Product Owner ayuda a comprender alternativas y compensaciones.

El Product Goal describe un estado futuro del producto y es el objetivo a largo plazo del Scrum Team. El equipo debe cumplir o abandonar un Product Goal antes de asumir otro. Aporta dirección más allá de cada Sprint y evita que el backlog se convierta en una acumulación inconexa de peticiones.

7.2. Sprint Backlog y Sprint Goal

El Sprint Backlog contiene el Sprint Goal —por qué—, los elementos seleccionados —qué— y un plan accionable —cómo—. Es un plan creado por y para los Developers, visible y actualizado en tiempo real. A medida que se aprende, el plan cambia. Esta adaptabilidad no autoriza a alterar arbitrariamente el objetivo; se renegocia el alcance con Product Owner sin poner en peligro el Sprint Goal.

El Sprint Goal es el objetivo único del Sprint. Proporciona flexibilidad respecto al trabajo exacto y promueve colaboración. Un conjunto de tareas sin objetivo común puede producir ocupación, pero no necesariamente coherencia. Si un elemento deja de ser necesario, puede sustituirse por otro trabajo que permita lograr el mismo objetivo, siempre que se respete calidad y capacidad.

7.3. Increment y Definition of Done

Un Increment es un paso concreto hacia el Product Goal. Cada Increment se suma a los anteriores y se verifica para asegurar que todos funcionan conjuntamente. Puede crearse más de uno durante el Sprint y puede entregarse antes de la Sprint Review; esta reunión no es una puerta obligatoria de liberación. El trabajo no puede considerarse parte del Increment si no cumple la Definition of Done.

La Definition of Done es una descripción formal del estado del Increment cuando satisface las medidas de calidad exigidas. Crea transparencia y una comprensión compartida. Si forma parte de estándares organizativos, todos los Scrum Teams deben cumplirla como mínimo. Si varios equipos trabajan en el mismo producto, deben definir y cumplir una Definition of Done común.

Una Definition of Done puede incluir revisión de código, pruebas unitarias y de integración, análisis de seguridad, actualización de documentación, cumplimiento de accesibilidad, despliegue en entorno integrado y ausencia de defectos críticos. Debe expresar resultados verificables, no actividades vagas. Cuanto más exigente y automatizada sea, menor será la deuda oculta.

7.4. Historias de usuario y criterios de aceptación

Scrum no prescribe historias de usuario. Son una técnica frecuente para expresar necesidades desde la perspectiva de una persona usuaria. El formato «Como…, quiero…, para…» ayuda a mantener contexto, pero no sustituye conversación ni criterios de aceptación. Una historia es una invitación a conversar, no una especificación completa.

Los criterios de aceptación describen condiciones funcionales específicas de un elemento y permiten comprobar si satisface la necesidad. La Definition of Done se aplica de forma transversal al Increment. Confundir ambos conceptos es un error frecuente: una historia puede cumplir sus criterios funcionales y, sin embargo, no estar Done porque faltan pruebas de seguridad, integración o documentación.

8. ESTIMACIÓN, PLANIFICACIÓN Y MÉTRICAS ÁGILES

Scrum no prescribe puntos de historia, Planning Poker, velocidad ni gráficos burn-down. Son prácticas complementarias. El examen puede asociarlas al entorno ágil, pero es importante distinguir lo obligatorio de lo opcional. Una estimación es una previsión bajo incertidumbre, no una promesa exacta. Su utilidad reside en apoyar decisiones sobre alcance, riesgo y capacidad.

8.1. Estimación relativa y puntos de historia

La estimación relativa compara elementos considerando esfuerzo, complejidad, incertidumbre y riesgo. Los puntos de historia representan una magnitud relativa definida por el equipo; no son horas ni una unidad comparable entre equipos. Planning Poker facilita conversación y revela diferencias de comprensión. Si dos personas estiman de forma muy distinta, la información valiosa no es el promedio, sino la razón de la discrepancia.

La estimación puede basarse también en tamaños —pequeño, mediano, grande—, recuento de elementos suficientemente homogéneos o simulación probabilística a partir de datos de flujo. La elección depende del contexto. Invertir demasiado tiempo en estimar trabajo lejano puede ser desperdicio porque la información cambiará.

8.2. Velocidad y previsión

La velocidad suele calcular la cantidad de puntos completados por Sprint. Puede ayudar al mismo equipo a realizar previsiones, siempre que la Definition of Done, la escala y la composición sean relativamente estables. No debe utilizarse para comparar equipos ni como objetivo de productividad. Cuando se convierte en objetivo, los puntos se inflan, se fragmentan artificialmente historias y disminuye su valor informativo.

Una previsión responsable expresa rango y probabilidad, no una fecha única sin contexto. La evidencia histórica, el tamaño del backlog, la variabilidad y los riesgos permiten construir escenarios. La planificación ágil no elimina compromisos; mejora su calidad al hacer explícita la incertidumbre.

8.3. Burn-down, burn-up y deuda técnica

Un gráfico burn-down muestra trabajo restante a lo largo del tiempo. Puede aplicarse a un Sprint o a una entrega. Un burn-up muestra trabajo completado y alcance total, por lo que hace visible el cambio de alcance. Ninguno demuestra por sí solo valor ni calidad. Una línea descendente puede ocultar elementos mal terminados o reducción artificial de estimaciones.

La deuda técnica es el coste futuro generado por decisiones que reducen mantenibilidad, seguridad o capacidad de cambio. Puede asumirse conscientemente para aprender con rapidez, pero debe hacerse visible y gestionarse. Si cada Sprint añade funcionalidad sin refactorizar, automatizar y corregir defectos, la velocidad aparente caerá. La Definition of Done y las prácticas de ingeniería evitan que el incremento acumule trabajo no declarado.

8.4. Antipatrones de gestión

• Scrum de tareas: el Sprint contiene actividades sin objetivo de producto y la Review se limita a porcentajes.
• Mini-cascada dentro del Sprint: análisis, desarrollo y pruebas se realizan en bloques secuenciales, dejando integración al final.
• Backlog como almacén infinito: se acumulan peticiones antiguas sin depurar, ordenar ni conectar con un Product Goal.
• Velocidad como KPI individual: incentiva manipulación y destruye colaboración.
• Daily como reporte: cada persona informa a un superior en vez de adaptar el plan común.
• Definition of Done débil: se declara terminado trabajo pendiente de pruebas, seguridad o despliegue.

9. KANBAN: DEFINICIÓN DEL FLUJO Y SISTEMA PULL

Kanban es una estrategia para optimizar el flujo de valor mediante un proceso que utiliza un sistema visual y un mecanismo de arrastre o pull. Puede aplicarse sobre un proceso existente sin exigir Sprints, accountabilities concretas ni una cadencia de entrega fija. Por ello resulta útil tanto en desarrollo de producto como en mantenimiento, soporte, explotación, seguridad, gestión de incidencias y servicios con demanda variable.

La Kanban Guide de mayo de 2025 articula Kanban mediante tres prácticas: definir y visualizar el flujo de trabajo, gestionar activamente los elementos del flujo y mejorar el flujo. El tablero es la visualización del sistema, pero Kanban no se reduce a mover tarjetas. Sin políticas explícitas, control del trabajo en curso y métricas, un tablero puede limitarse a representar un proceso ineficiente.

9.1. Definition of Workflow

La Definition of Workflow —DoW— describe cómo circula el valor. Debe incluir, como mínimo, una definición de los elementos de trabajo, puntos explícitos de inicio y finalización, estados por los que pasan, control del WIP, políticas explícitas y una expectativa de nivel de servicio o SLE. La visualización de la DoW constituye el tablero Kanban. No existe una forma única: las columnas deben reflejar el flujo real y no una plantilla genérica impuesta por la herramienta.

Definir el inicio y el final es esencial para interpretar las métricas. Si un equipo mide cycle time desde que comienza análisis hasta que despliega, no puede compararlo directamente con otro que comienza a medir al crear una petición. El tablero debe hacer visibles bloqueos, clases de servicio, políticas y cualquier condición que influya en el movimiento.

9.2. Control del WIP y sistema pull

WIP, Work in Progress, es el número de elementos iniciados y no terminados. Controlarlo evita que se abra más trabajo del que el sistema puede absorber. Cuando existe capacidad, el siguiente estado «tira» de un elemento; no se empuja trabajo hacia una fase saturada. El sistema pull reduce colas, cambia el foco desde iniciar hacia terminar y hace visibles los cuellos de botella.

Los controles WIP pueden expresarse por columna, conjunto de estados, tipo de trabajo o sistema completo. La guía de 2025 permite flexibilidad en la representación, pero exige control explícito. Operar sistemáticamente por encima del control normaliza la sobrecarga; operar muy por debajo puede revelar falta de demanda, bloqueos o políticas inadecuadas. Las excepciones deben ser visibles y justificadas.

9.3. Gestión activa de elementos

Gestionar activamente implica controlar WIP, revisar la edad de los elementos, desbloquear trabajo y seleccionar nuevas tareas solo cuando existe señal de capacidad. El objetivo no es mantener ocupadas a todas las personas, sino facilitar que los elementos terminen. Ante un bloqueo, el equipo colabora para resolverlo en lugar de iniciar trabajo adicional que aumente la cola.

Las políticas explícitas indican cuándo un elemento puede entrar o salir de un estado, qué datos necesita, cómo se tratan urgencias y quién toma decisiones. Estas políticas aumentan transparencia y reducen negociaciones repetitivas. Deben revisarse cuando la evidencia muestre que perjudican flujo o valor.

9.4. Kanban y Scrum

Scrum y Kanban no son excluyentes. Scrum proporciona una cadencia de Sprint, accountabilities, eventos y artefactos; Kanban aporta prácticas y métricas para optimizar flujo. Un Scrum Team puede visualizar su flujo, controlar WIP, analizar cycle time y utilizar SLE sin abandonar Scrum. A esta combinación suele denominarse informalmente Scrumban, aunque no es un marco oficial de la Scrum Guide.

10. KANBAN: MÉTRICAS DE FLUJO, SLE Y ANÁLISIS

La Kanban Guide 2025 exige cuatro métricas mínimas: WIP, throughput, work item age y cycle time. Su significado depende de los puntos de inicio y final definidos en la DoW. Medir no es suficiente; los datos deben emplearse para gestionar elementos, revisar políticas y mejorar equilibrio entre efectividad, eficiencia y predictibilidad.

10.1. WIP, throughput, edad y cycle time

• WIP: número de elementos iniciados y no terminados. Es una medida instantánea del inventario dentro del sistema.
• Throughput: número exacto de elementos terminados por unidad de tiempo. No pondera puntos ni complejidad; requiere elementos con una granularidad razonablemente gestionable.
• Work Item Age: tiempo transcurrido desde que un elemento comenzó hasta el momento actual. Solo se aplica a elementos todavía abiertos y ayuda a detectar riesgo antes de incumplir expectativas.
• Cycle Time: tiempo transcurrido desde el inicio hasta la finalización de un elemento. Se observa sobre elementos terminados y forma una distribución, no un único promedio.

El lead time suele abarcar desde que se solicita algo hasta que se entrega, incluyendo espera previa al inicio. La Kanban Guide centra su métrica obligatoria en cycle time según la DoW, pero una organización puede medir lead time adicional. Para examen debe atenderse a la definición dada: si el tiempo empieza con la petición, es lead time; si empieza al comenzar trabajo, es cycle time.

10.2. Service Level Expectation

La SLE es una previsión del tiempo que debería tardar un elemento desde iniciado hasta terminado. Incluye un periodo y una probabilidad, por ejemplo: «el 85 % de los elementos termina en ocho días o menos». Debe basarse en cycle time histórico y visualizarse en la DoW. No es garantía individual ni acuerdo contractual de nivel de servicio; es una expectativa probabilística que apoya decisiones.

Cuando no existe histórico, puede utilizarse una estimación inicial hasta reunir datos. La SLE permite comparar la edad actual de un elemento con el comportamiento observado. Si una tarea de cinco días está cerca del percentil seleccionado y continúa bloqueada, el equipo puede actuar antes de que se retrase.

10.3. Diagramas y Ley de Little

El diagrama de flujo acumulado muestra cantidad de elementos por estado a lo largo del tiempo. La anchura horizontal de una banda se relaciona con tiempo; la vertical, con inventario. Una banda que se ensancha revela acumulación y posible cuello de botella. El scatterplot de cycle time representa duración de elementos terminados y permite observar percentiles, tendencias y valores atípicos.

La Ley de Little relaciona, en un sistema estable, inventario medio, tasa de salida y tiempo medio: WIP = Throughput × Cycle Time. No es una fórmula para manipular personas, sino una relación sistémica. Si el throughput permanece estable y se reduce WIP, tenderá a reducirse el cycle time. Para aplicarla, los promedios deben referirse al mismo límite del sistema y periodo, y el sistema debe ser razonablemente estable.

WIP medio = 12 elementos
Throughput medio = 3 elementos/semana
Cycle Time medio ≈ WIP / Throughput = 12 / 3 = 4 semanas

El promedio puede ocultar variabilidad. Para previsiones es preferible analizar distribuciones y percentiles o realizar simulaciones Monte Carlo. Una simulación toma muestras históricas de throughput o cycle time y calcula la probabilidad de terminar un conjunto antes de una fecha. Así se responde «con qué probabilidad» en lugar de prometer una fecha determinista.

11. LEAN APLICADO AL DESARROLLO DE SOFTWARE

Lean procede del estudio del sistema de producción de Toyota y se trasladó al desarrollo de software como una forma de pensar orientada a valor, flujo, calidad y aprendizaje. No es sinónimo de «hacer más con menos» mediante reducción indiscriminada de recursos. Su objetivo es eliminar actividad que no aporta valor, acortar ciclos, construir calidad y mejorar el sistema completo.

11.1. Siete principios de Lean Software Development

1. Eliminar desperdicio. Suprimir trabajo que consume capacidad sin aportar valor ni reducir riesgo necesario.
2. Amplificar el aprendizaje. Utilizar experimentos, retroalimentación, pruebas y entregas para convertir incertidumbre en conocimiento.
3. Decidir lo más tarde responsablemente posible. Mantener opciones abiertas hasta disponer de información, sin posponer negligentemente.
4. Entregar lo antes posible. Reducir lotes y tiempos de espera para obtener valor y aprendizaje.
5. Potenciar al equipo. Situar decisiones cerca del conocimiento y crear condiciones para la responsabilidad.
6. Construir integridad o calidad desde dentro. Prevenir defectos, mantener coherencia y automatizar controles.
7. Ver el conjunto. Optimizar el flujo de valor extremo a extremo y evitar mejoras locales perjudiciales.

11.2. Desperdicios en software

Los desperdicios no siempre son visibles como materiales. En conocimiento adoptan forma de trabajo parcialmente hecho, características no utilizadas, reaprendizaje, transferencias, esperas, cambios de tarea, defectos y sobreprocesamiento. El código no integrado es inventario; una funcionalidad que nadie usa es sobreproducción; una aprobación que espera semanas es demora; información que pasa entre múltiples equipos genera transferencias y pérdida de contexto.

La eliminación de desperdicio no justifica borrar documentación o controles por defecto. Una evidencia de seguridad, una revisión clínica o una prueba de recuperación puede no generar una función visible, pero reduce riesgo y forma parte del valor total. Lean pregunta qué necesidad satisface cada actividad y cómo realizarla con menos espera y error.

11.3. Mapa de flujo de valor

El value stream mapping representa el recorrido desde una necesidad hasta su entrega y operación. Distingue tiempo de proceso y tiempo de espera. En muchos sistemas, el trabajo activo ocupa una fracción pequeña del lead time; la mayor parte se pierde en colas, aprobaciones, dependencias y retrabajo. El mapa permite seleccionar mejoras sistémicas: automatizar un paso, reducir tamaño de lote, eliminar una transferencia o acercar competencias al equipo.

12. DEVOPS: CULTURA, AUTOMATIZACIÓN Y OPERACIÓN COMPARTIDA

DevOps es un enfoque sociotécnico que integra desarrollo y operación para mejorar el flujo de cambios desde la idea hasta producción, conservando estabilidad, seguridad y capacidad de recuperación. No es una herramienta, un puesto aislado ni un sinónimo de automatización. Surge frente a la separación en la que desarrollo optimiza cambios y operaciones optimiza estabilidad mediante incentivos contradictorios.

La responsabilidad compartida significa que quienes construyen comprenden comportamiento en producción y quienes operan participan en diseño, automatización y fiabilidad. Los equipos trabajan sobre un producto o servicio durante su ciclo de vida, reducen transferencias y utilizan telemetría para aprender. La frase «you build it, you run it» expresa esta orientación, aunque su aplicación debe ajustarse a guardias, capacidades y criticidad.

12.1. Modelo CALMS

CALMS resume cinco dimensiones: Culture, Automation, Lean, Measurement y Sharing. Cultura incluye confianza y colaboración; automatización reduce trabajo manual y variabilidad; Lean limita lotes y WIP; medición aporta evidencia; compartir distribuye conocimiento y responsabilidad. Adoptar solo una plataforma CI/CD sin modificar silos y políticas produce automatización local, no DevOps.

12.2. Prácticas técnicas

• Control de versiones: código, configuración, infraestructura y documentación evolucionan con trazabilidad.
• Integración continua: cambios pequeños se integran frecuentemente y se validan automáticamente.
• Entrega y despliegue automatizados: el proceso de construir, probar, empaquetar y promocionar artefactos es repetible.
• Infraestructura como código: entornos se describen declarativamente y se revisan como software.
• Observabilidad: métricas, logs y trazas permiten comprender estado interno desde salidas.
• Arquitectura desacoplada: equipos pueden cambiar y desplegar componentes con menor coordinación.
• Gestión de configuración y secretos: se separa código de configuración y se protegen credenciales.
• Respuesta a incidentes sin culpa: se aprende de fallos y se corrigen causas sistémicas.

12.3. Infraestructura como código y automatización

Infraestructura como código —IaC— representa recursos mediante archivos versionados. Permite reproducibilidad, revisión y detección de desviaciones. No basta con escribir scripts: el proceso debe ser idempotente, probado y sometido a controles. La configuración manual no registrada crea entornos «artesanales» imposibles de reproducir.

cambio pequeño → commit → compilación → pruebas → análisis → artefacto inmutable
       → despliegue automatizado en entorno → validación → promoción controlada

Los artefactos inmutables se construyen una vez y se promocionan entre entornos, evitando recompilar con resultados distintos. La separación de configuración permite utilizar el mismo artefacto con parámetros específicos. La trazabilidad enlaza requisito, commit, pipeline, artefacto, despliegue y evidencia.

12.4. Operación y aprendizaje

DevOps reduce el trabajo operativo manual o toil mediante automatización. Los incidentes se analizan con revisiones sin culpa, centradas en cómo las condiciones del sistema permitieron el fallo. Una acción correctiva útil modifica controles, diseño, observabilidad o procedimiento; buscar un culpable individual oculta causas y reduce transparencia.

13. INTEGRACIÓN CONTINUA, ENTREGA CONTINUA Y DESPLIEGUE CONTINUO

13.1. Integración continua

La integración continua —CI— es la práctica de integrar cambios en una línea principal con frecuencia y validarlos mediante una construcción y pruebas automatizadas. Su objetivo es detectar incompatibilidades pronto y mantener el sistema en estado saludable. Requiere commits pequeños, pipeline rápido, corrección prioritaria de fallos y reducción de ramas de larga duración.

CI no equivale a ejecutar una herramienta una vez al día. Si el código permanece semanas aislado, la integración deja de ser continua aunque exista servidor de automatización. La estrategia trunk-based development reduce divergencia mediante ramas cortas y feature flags. GitFlow puede ser útil en algunos ciclos de versiones, pero ramas largas aumentan coste de fusión y retrasan retroalimentación.

13.2. Entrega continua

La entrega continua —continuous delivery— mantiene el software en estado desplegable y automatiza la cadena hasta un punto en el que una decisión humana puede autorizar producción. Cada cambio que supera los controles podría liberarse, aunque no se libere inmediatamente. Requiere pruebas fiables, gestión de datos, entornos reproducibles y mecanismos de reversión.

13.3. Despliegue continuo

El despliegue continuo —continuous deployment— lleva automáticamente a producción cada cambio que supera el pipeline. Es una extensión de la entrega continua, no un sinónimo. Puede no ser apropiado en todos los sistemas por regulación, ventanas, criticidad o coordinación, pero sus prácticas —automatización, artefactos pequeños y validación— siguen aportando valor aunque exista aprobación final.

13.4. Estrategias de despliegue

El despliegue blue-green mantiene dos entornos equivalentes y conmuta tráfico; facilita reversión, pero duplica capacidad. El canary expone una versión a una parte pequeña de usuarios y amplía gradualmente según telemetría. El rolling deployment sustituye instancias por fases. Los feature flags separan despliegue de activación y permiten habilitar capacidades selectivamente.

Una reversión no siempre consiste en volver al binario anterior. Los cambios de base de datos deben ser compatibles y evolutivos. Técnicas como expand-and-contract añaden primero estructuras compatibles, migran uso y eliminan después lo antiguo. En sistemas con datos clínicos, la integridad y trazabilidad condicionan cualquier estrategia.

13.5. Pipeline como mecanismo de calidad

El pipeline puede incorporar compilación, pruebas unitarias, integración, análisis estático, dependencias, licencias, contenedores, infraestructura, rendimiento y pruebas dinámicas. Los controles deben proporcionar feedback rápido. Se organizan por coste: validaciones rápidas al principio y pruebas más pesadas después. Un pipeline lento o inestable incentiva saltarse controles y reduce frecuencia de integración.

14. MÉTRICAS DEVOPS, OBSERVABILIDAD Y FIABILIDAD

14.1. Métricas DORA

DORA utiliza actualmente cinco métricas de rendimiento de entrega de software. Tres describen throughput: change lead time, deployment frequency y failed deployment recovery time. Dos describen inestabilidad: change fail rate y deployment rework rate. El modelo evolucionó desde las cuatro métricas clásicas, sustituyendo el ambiguo MTTR por tiempo de recuperación de despliegues fallidos y añadiendo retrabajo de despliegue.

• Change lead time: tiempo desde que un cambio se confirma en control de versiones hasta que se despliega en producción.
• Deployment frequency: número de despliegues por periodo o tiempo entre ellos.
• Failed deployment recovery time: tiempo para recuperarse de un despliegue fallido que requiere intervención.
• Change fail rate: proporción de despliegues que exigen rollback, hotfix u otra intervención inmediata.
• Deployment rework rate: proporción de despliegues no planificados originados por incidentes en producción.

DORA destaca que velocidad y estabilidad no son necesariamente compensaciones. Los equipos de alto rendimiento tienden a mejorar ambas mediante cambios pequeños, automatización y aprendizaje. Las métricas deben aplicarse a una aplicación o servicio en su contexto, no utilizarse para competir entre sistemas diferentes ni convertirse en objetivos manipulables.

14.2. Observabilidad

La monitorización comprueba condiciones conocidas; la observabilidad permite investigar estados no anticipados mediante telemetría. Sus señales tradicionales son métricas, logs y trazas distribuidas. Deben complementarse con contexto, correlación y objetivos de servicio. Registrar grandes cantidades sin capacidad de consulta no genera observabilidad.

Las métricas de producto y técnicas se conectan. Una degradación de latencia puede aumentar abandono; un error en una integración puede bloquear un proceso. La telemetría se diseña durante desarrollo y se incluye en la Definition of Done, no se añade después de un incidente.

14.3. SLI, SLO y error budget

La ingeniería de fiabilidad de sitio —SRE— define indicadores de nivel de servicio —SLI—, objetivos —SLO— y presupuestos de error. Un SLI mide una propiedad, como porcentaje de solicitudes correctas o latencia. El SLO fija un objetivo para un periodo. El error budget es la cantidad de incumplimiento tolerada y permite equilibrar innovación y fiabilidad.

SLI: 99,93 % de solicitudes correctas en 30 días
SLO: al menos 99,90 %
Error budget consumido: 0,07 puntos porcentuales de 0,10 permitidos

Un SLA es un acuerdo externo con consecuencias y no debe confundirse con SLO interno ni con SLE de Kanban. La SLE predice tiempo de flujo de elementos; el SLO expresa fiabilidad de servicio; el SLA formaliza compromisos con usuarios o proveedores.

14.4. Seguridad psicológica y métricas

La calidad de datos depende de que las personas puedan mostrar fallos sin temor. Si las métricas se usan para castigar, se ocultarán incidentes y se manipularán definiciones. Las revisiones postincidente deben reconstruir secuencia, condiciones, señales y decisiones, y producir aprendizaje verificable. El propósito es reforzar el sistema.

15. DEVSECOPS Y DESARROLLO SEGURO

DevSecOps integra seguridad en la cultura, el flujo y la automatización de DevOps. Su objetivo no es añadir una fase de seguridad al pipeline, sino compartir responsabilidad y proporcionar controles tempranos, repetibles y proporcionales al riesgo. La seguridad sigue necesitando especialistas, gobierno e independencia donde proceda, pero deja de actuar exclusivamente como puerta final.

15.1. Shift left y shift right

Shift left desplaza actividades hacia etapas tempranas: modelado de amenazas, requisitos, diseño seguro, análisis de código y dependencias. Detectar un problema antes de construir reduce coste. Shift right utiliza controles en ejecución: observabilidad, pruebas en producción controladas, detección, respuesta y aprendizaje. Ambos son complementarios; ninguna validación previa elimina todo riesgo operativo.

15.2. NIST SSDF

NIST SP 800-218, Secure Software Development Framework versión 1.1, define prácticas de alto nivel integrables en cualquier SDLC. Se agrupan en preparar la organización, proteger el software, producir software bien asegurado y responder a vulnerabilidades. El marco proporciona vocabulario común para productores, compradores y proveedores, por lo que resulta útil también en contratación.

A agosto de 2026, SSDF v1.1 sigue siendo la publicación final de referencia de NIST SP 800-218. NIST ha publicado una revisión posterior como borrador de trabajo; por tanto, en una respuesta de examen debe distinguirse claramente una versión final de una revisión todavía no consolidada.

Preparar la organización incluye roles, formación, herramientas y entornos. Proteger el software comprende integridad del código, repositorios y artefactos. Producir software seguro incluye requisitos, diseño, revisión, pruebas y gestión de componentes. Responder abarca identificar, remediar y aprender de vulnerabilidades para evitar recurrencia.

15.3. Controles en la cadena

Una SBOM no demuestra por sí sola que el producto sea seguro; permite conocer componentes y responder ante vulnerabilidades. La firma y procedencia de artefactos ayudan a verificar integridad. La seguridad de la cadena de suministro exige proteger repositorios, identidades, runners, dependencias, registros y mecanismos de promoción.

15.4. Policy as code y puertas de calidad

Policy as code expresa reglas verificables: versiones mínimas, cifrado, exposición de red, criticidad de vulnerabilidades o segregación de funciones. Las puertas pueden bloquear un cambio o exigir excepción documentada. Para ser efectivas necesitan contexto: bloquear todas las vulnerabilidades sin considerar explotabilidad y riesgo genera fatiga y fomenta evasión.

15.5. Modelado de amenazas y privacidad

El modelado de amenazas identifica activos, fronteras de confianza, amenazas y mitigaciones durante diseño. Técnicas como STRIDE ayudan a estructurar preguntas sobre suplantación, manipulación, repudio, divulgación, denegación y elevación de privilegios. En datos personales debe incorporarse privacidad desde el diseño: minimización, limitación de finalidad, control de acceso, trazabilidad y conservación.

En un sistema sanitario, la confidencialidad es esencial, pero también integridad y disponibilidad. Un control que protege datos y provoca indisponibilidad clínica puede generar otro riesgo. DevSecOps busca decisiones basadas en riesgo y evidencia, no una acumulación indiferenciada de herramientas.

16. APLICACIÓN EN EL SECTOR PÚBLICO SANITARIO Y CRITERIOS DE ADOPCIÓN

La adopción ágil en una Administración sanitaria debe reconciliar adaptación con legalidad, trazabilidad, protección de datos, seguridad, continuidad asistencial y contratación. La agilidad no permite ignorar estos requisitos; ayuda a verificarlos de forma incremental. Cada entrega puede incorporar evidencias de accesibilidad, seguridad, interoperabilidad, rendimiento y aceptación funcional en lugar de concentrarlas al final.

16.1. Producto, gobernanza y responsables

Un producto digital necesita propósito, usuarios, indicadores, responsable de valor y equipo con capacidad de evolución. El Product Owner puede corresponder a una persona con autoridad funcional, pero debe integrarse en la gobernanza institucional. Los interesados aportan perspectivas clínicas, administrativas, técnicas, seguridad, privacidad, soporte y explotación. El backlog debe ordenar estas necesidades sin fragmentar el objetivo.

La gobernanza define límites: arquitectura corporativa, interoperabilidad, ENS, privacidad, accesibilidad, catálogo de tecnologías y gestión de cambios. Dentro de ellos, el equipo necesita autonomía para decidir implementación y secuencia. Si cada decisión técnica requiere una cadena de aprobaciones, el flujo se bloquea; si se eliminan controles esenciales, aumenta riesgo. La solución consiste en políticas claras, automatización y plataformas internas que incorporen caminos seguros por defecto.

16.2. Contratación y proveedores

Los contratos pueden estructurar entregables incrementales, criterios de aceptación, demostraciones, backlog trazable, calidad mínima y métricas de servicio. Debe distinguirse la gestión adaptable del detalle de una modificación ilícita del objeto contractual. Los límites, resultados y mecanismos de cambio se diseñan desde los pliegos.

La responsabilidad sobre producto no se externaliza completamente. La Administración conserva conocimiento, decisiones de prioridad, datos, arquitectura y capacidad de supervisión. Las métricas no deben incentivar volumen de puntos o incidencias cerradas, sino resultados, flujo, calidad y transferencia de conocimiento.

16.3. Selección del enfoque

16.4. Criterios de madurez

Una implantación madura muestra entregas pequeñas, backlog conectado con objetivos, Definition of Done exigente, pruebas automatizadas, telemetría, WIP controlado, mejora basada en datos y colaboración estable. Una implantación nominal muestra ceremonias, tableros y nuevas denominaciones, pero mantiene lotes grandes, silos, aprobaciones tardías y calidad diferida.

La transformación debe empezar por un flujo concreto, medir su estado y eliminar impedimentos. Imponer el mismo marco a todos los equipos puede ignorar diferencias entre desarrollo, infraestructura, soporte y datos. Los principios son comunes; la configuración debe responder al tipo de demanda y riesgo.

17. IDEAS CLAVE Y MAPA CONCEPTUAL

La agilidad combina orientación a valor, ciclos cortos de aprendizaje, equipos responsables y calidad técnica. El Manifiesto expresa preferencias, no prohibiciones. Scrum estructura el aprendizaje mediante Sprints, accountabilities, eventos y artefactos. Kanban optimiza flujo con DoW, control WIP, gestión activa y métricas. Lean elimina desperdicio y mejora el sistema. DevOps une construcción y operación; DevSecOps integra seguridad durante todo el ciclo.

• Un Sprint dura un mes o menos; contiene Planning, Daily, Review y Retrospective.
• Product Owner maximiza valor; Developers crean el Increment; Scrum Master responde de Scrum y efectividad.
• Product Backlog/Product Goal, Sprint Backlog/Sprint Goal e Increment/Definition of Done son las tres parejas.
• Kanban controla WIP y utiliza WIP, throughput, work item age y cycle time.
• La SLE combina tiempo y probabilidad; no es un SLA.
• Lean retrasa decisiones hasta el último momento responsable y evita características sin valor.
• CI integra y valida; continuous delivery mantiene desplegable; continuous deployment despliega automáticamente.
• DORA mide el sistema de entrega, no productividad individual.
• DevSecOps combina shift left, shift right, automatización, gobierno y respuesta.