1. Desarrollo ágil de software
🎯 Idea clave
- El desarrollo ágil de software es un enfoque metodológico que prioriza la entrega progresiva de valor mediante ciclos cortos y adaptativos.
- Su objetivo no es la rapidez superficial, sino la capacidad de responder eficazmente a cambios en requisitos, contexto o necesidades organizativas.
- Se basa en la colaboración continua entre equipos técnicos, usuarios y responsables funcionales para validar y ajustar el producto de forma temprana.
- No elimina la planificación ni la disciplina, sino que reorganiza el ciclo de vida del software en iteraciones realimentadas.
- La agilidad reduce el riesgo de equivocarse tarde al validar incrementos funcionales de manera frecuente y temprana.
- Es una familia de enfoques, no una metodología única, formalizada en el Manifiesto Ágil de 2001.
📚 Desarrollo
Definición y enfoque. El desarrollo ágil de software es un conjunto de prácticas y principios orientados a construir sistemas de información de forma iterativa e incremental. Su núcleo es la entrega frecuente de valor funcional al usuario, adaptándose a cambios en lugar de seguir un plan rígido predefinido. Este enfoque asume que los requisitos rara vez permanecen estables durante largos periodos, ya que la comprensión del problema mejora con el uso del producto y evolucionan las prioridades del negocio o del servicio público.
Diferencias con modelos tradicionales. A diferencia del desarrollo clásico en cascada (Waterfall), donde las fases (análisis, diseño, codificación, pruebas y despliegue) se ejecutan de forma secuencial y cerrada, el desarrollo ágil reorganiza estas actividades en ciclos cortos. Cada ciclo genera un incremento verificable del producto, permitiendo validar y corregir el rumbo antes de avanzar. Esta estructura reduce la distancia entre la identificación de una necesidad y su solución funcional, minimizando el coste de los errores detectados tardíamente.
Colaboración y retroalimentación. La agilidad otorga un papel central a la interacción constante entre los participantes del proyecto: equipos técnicos, responsables funcionales y usuarios finales. La comunicación fluida y la retroalimentación continua son herramientas clave para ajustar el producto a la realidad cambiante del entorno. Esta dinámica no trata el cambio como una incidencia, sino como un elemento inherente al proceso, integrándolo de manera natural en cada iteración.
Disciplina y calidad. La agilidad no equivale a improvisación ni a ausencia de control. Requiere disciplina en la priorización de tareas, pruebas sistemáticas, control técnico y documentación útil. La validación temprana del software en funcionamiento prevalece sobre la confianza exclusiva en planes iniciales o documentación exhaustiva, pero esto no implica prescindir de la arquitectura, la trazabilidad o los criterios de calidad. La adaptación disciplinada es su rasgo distintivo frente al caos organizativo.
Origen y marco teórico. El término ágil se popularizó con la publicación del Manifiesto Ágil en 2001, aunque sus raíces se remontan a metodologías previas como Scrum (1995), Extreme Programming (1996) o Crystal. Estas corrientes convergieron en torno a valores comunes, como la priorización de las personas y la colaboración, el software funcional sobre la documentación detallada, y la respuesta al cambio sobre el seguimiento estricto de un plan. Los principios Lean, desarrollados en el sistema de producción de Toyota, también influyeron en su filosofía de reducción de desperdicios y mejora continua.
Ventajas y riesgos. Las principales ventajas del desarrollo ágil son la adaptación rápida a cambios, la validación temprana de funcionalidades y la entrega progresiva de valor. Sin embargo, sus riesgos aparecen cuando se confunde con falta de método o se descuidan aspectos críticos como la arquitectura del sistema, la documentación necesaria o la calidad técnica. La agilidad exige un equilibrio entre flexibilidad y rigor para garantizar resultados sostenibles y escalables.
Aplicación en entornos públicos. En organizaciones como el Servicio Andaluz de Salud, el desarrollo ágil permite responder con mayor eficacia a necesidades cambiantes en sistemas de información sanitaria. La entrega incremental de funcionalidades facilita la validación temprana por parte de profesionales y usuarios, mejorando la alineación entre el producto final y los requisitos reales del servicio. Además, la colaboración estrecha entre perfiles técnicos y funcionales optimiza la utilidad y la adopción de las soluciones desarrolladas.
🧩 Elementos esenciales
- Enfoque iterativo e incremental: El desarrollo ágil organiza el trabajo en ciclos cortos (iteraciones) que generan incrementos funcionales y verificables del producto.
- Entrega frecuente de valor: Prioriza la producción de software operativo en plazos breves para validar y ajustar el producto de manera continua.
- Colaboración continua: Requiere interacción constante entre equipos técnicos, usuarios y responsables funcionales para alinear el desarrollo con las necesidades reales.
- Adaptación al cambio: Asume que los requisitos evolucionan y integra esta realidad como parte normal del proceso, en lugar de tratarla como una excepción.
- Retroalimentación temprana: Valida cada incremento con los usuarios para corregir desviaciones antes de avanzar en el desarrollo.
- Disciplina y planificación: Exige priorización de tareas, pruebas sistemáticas, control técnico y documentación útil, sin caer en la improvisación.
- Equipos autoorganizados: Fomenta la autonomía y la responsabilidad compartida dentro de los equipos para optimizar la eficiencia y la calidad.
- Software en funcionamiento: Da más peso a la entrega de productos operativos que a la documentación exhaustiva o a planes iniciales rígidos.
- Reducción de riesgos: Minimiza el coste de los errores al detectarlos y corregirlos en fases tempranas del desarrollo.
- Familia de métodos: No es una metodología única, sino un conjunto de enfoques (como Scrum, Kanban o Lean) que comparten una filosofía común.
- Manifiesto Ágil: Documento fundacional (2001) que formaliza los valores y principios del desarrollo ágil, como la colaboración, la adaptabilidad y la entrega de valor.
- Calidad técnica: Mantiene altos estándares en arquitectura, pruebas y documentación, evitando confundir agilidad con falta de rigor.
🧠 Recuerda
- El desarrollo ágil no es sinónimo de rapidez superficial, sino de capacidad de adaptación disciplinada.
- Prioriza la entrega de software funcional sobre la documentación exhaustiva o los planes rígidos.
- La colaboración continua entre equipos técnicos y usuarios es clave para alinear el producto con las necesidades reales.
- Cada iteración debe generar un incremento verificable y útil del producto.
- La agilidad no elimina la planificación, sino que la hace continua y adaptable.
- Los errores se detectan y corrigen antes, reduciendo costes y riesgos.
- Es una familia de métodos, no una única metodología, con raíces en el Manifiesto Ágil de 2001.
- Requiere disciplina en priorización, pruebas y control técnico para evitar la improvisación.
- La validación temprana con usuarios mejora la utilidad y la adopción del producto final.
- En entornos públicos, facilita la respuesta a necesidades cambiantes en sistemas críticos.
2. Filosofía y principios del desarrollo ágil
🎯 Idea clave
- La filosofía ágil prioriza la entrega continua de valor sobre el seguimiento rígido de planes preestablecidos.
- Se fundamenta en la adaptación al cambio, la colaboración estrecha entre equipos técnicos y funcionales, y la mejora constante del producto.
- Surge como respuesta a entornos complejos donde los requisitos evolucionan con rapidez, como en el ámbito sanitario.
- Promueve la iteratividad, la incrementalidad y la validación temprana para alinear las soluciones con necesidades reales.
- No elimina la planificación ni el control, sino que los organiza para permitir aprendizaje y corrección rápidos.
- En el Servicio Andaluz de Salud, esta filosofía se aplica para gestionar sistemas críticos con exigencias de interoperabilidad y seguridad.
📚 Desarrollo
Origen y propósito. La filosofía ágil nace como respuesta a los límites de los modelos secuenciales rígidos, como el desarrollo en cascada, en proyectos con requisitos cambiantes o alta incertidumbre. Su objetivo es organizar el trabajo para aprender pronto, validar frecuentemente y corregir con rapidez, manteniendo la solución alineada con las necesidades reales durante todo su ciclo de vida. Esta aproximación resulta especialmente útil en entornos complejos, como el del Servicio Andaluz de Salud, donde los sistemas digitales deben evolucionar ante cambios normativos, clínicos o tecnológicos.
Adaptación al cambio. Uno de los principios centrales del desarrollo ágil es la capacidad de integrar cambios como parte natural del proceso, en lugar de percibirlos como desviaciones costosas. En el SAS, donde las prioridades asistenciales y organizativas pueden variar con rapidez, esta flexibilidad permite ajustar las soluciones a nuevas demandas sin retrasos significativos. La entrega incremental de funcionalidades críticas evita la obsolescencia de los sistemas antes de su finalización completa.
Colaboración y participación. La filosofía ágil fomenta la colaboración continua entre perfiles técnicos y funcionales, facilitando la participación activa de profesionales clínicos y administrativos en la definición y validación de los sistemas. Esta proximidad reduce la distancia entre el equipo de desarrollo y los usuarios finales, mejorando la alineación del producto con las necesidades reales. En el SAS, esta práctica es clave para sistemas como Diraya o ClicSalud+, donde la retroalimentación de los usuarios impulsa su evolución.
Entrega de valor. El enfoque ágil prioriza la entrega temprana y frecuente de funcionalidades con valor tangible, en lugar de concentrar las entregas en hitos finales. Esto permite validar el producto en etapas tempranas y ajustarlo según la retroalimentación recibida. Para el SAS, esta práctica es especialmente relevante en sistemas críticos, donde una mejora funcional entregada a tiempo puede tener un impacto directo en la asistencia sanitaria o la gestión organizativa.
Mejora continua. La filosofía ágil no se limita a la entrega de software, sino que promueve la revisión constante del proceso y del producto. Los equipos evalúan regularmente su trabajo para identificar oportunidades de optimización, tanto en la calidad técnica como en la eficiencia operativa. En el contexto del SAS, esta mentalidad se traduce en la evolución continua de plataformas como ayudaDIGITAL o los sistemas de telemedicina, adaptándose a las necesidades cambiantes de profesionales y ciudadanos.
Rigor y control. Aunque el desarrollo ágil se asocia a flexibilidad, no implica ausencia de planificación o control. Por el contrario, exige una organización rigurosa del trabajo para garantizar entregas frecuentes, calidad técnica y seguridad. En el SAS, esta filosofía se complementa con marcos como DevSecOps, que integran la seguridad y la automatización desde etapas tempranas, asegurando que los sistemas cumplan con los estándares de interoperabilidad y continuidad requeridos.
Contexto institucional. La adopción de la filosofía ágil en el Servicio Andaluz de Salud no es un concepto teórico, sino una práctica institucional respaldada por marcos oficiales y documentación en entornos como Confluence. Esto refleja su relevancia para gestionar proyectos en un ecosistema digital complejo, donde la coordinación entre equipos, la visibilidad del progreso y la orientación al valor son esenciales para el éxito.
🧩 Elementos esenciales
- Iteratividad: El trabajo se organiza en ciclos cortos y repetitivos que permiten ajustar el producto según la retroalimentación recibida.
- Incrementalidad: Las funcionalidades se entregan de forma progresiva, añadiendo valor en cada iteración en lugar de esperar a una versión final completa.
- Colaboración: La participación activa de todos los interesados (técnicos, clínicos, administrativos) es clave para alinear el producto con las necesidades reales.
- Adaptación al cambio: Los cambios en los requisitos o prioridades se integran de forma natural, sin percibirlos como desviaciones costosas.
- Entrega temprana: Prioriza la puesta en producción de funcionalidades críticas en etapas tempranas, validando su utilidad antes de completar el sistema.
- Mejora continua: Tanto el producto como el proceso se revisan constantemente para optimizar su calidad y eficiencia.
- Equipos autorganizados: Los equipos tienen autonomía para decidir cómo abordar el trabajo, fomentando la responsabilidad y la creatividad.
- Transparencia: El progreso del proyecto es visible para todos los interesados, facilitando la toma de decisiones informadas.
- Ritmo sostenible: El trabajo se organiza para evitar la sobrecarga de los equipos, manteniendo un ritmo constante y productivo.
- Enfoque en el usuario: El producto se diseña y valida con la participación activa de los usuarios finales, asegurando su utilidad y usabilidad.
- Calidad integrada: La excelencia técnica y la seguridad se incorporan desde el inicio, no como fases posteriores.
- Flexibilidad: La planificación es adaptativa, permitiendo ajustes según las necesidades emergentes o los aprendizajes obtenidos.
🧠 Recuerda
- La filosofía ágil no es sinónimo de falta de planificación, sino de planificación adaptativa.
- Su objetivo principal es entregar valor de forma continua, no seguir un plan rígido.
- La colaboración entre equipos técnicos y funcionales es esencial para alinear el producto con las necesidades reales.
- La entrega incremental permite validar el producto en etapas tempranas y ajustarlo según la retroalimentación.
- La adaptación al cambio es una ventaja clave en entornos complejos como el sanitario.
- La mejora continua se aplica tanto al producto como al proceso de desarrollo.
- En el SAS, la filosofía ágil se aplica a sistemas críticos como Diraya o ClicSalud+.
- La transparencia y la visibilidad del progreso son pilares fundamentales.
- La seguridad y la calidad no se sacrifican, sino que se integran desde el inicio.
- Los equipos autorganizados tienen autonomía para decidir cómo abordar el trabajo.
- La filosofía ágil no es una receta única, sino un enfoque adaptable a cada contexto.
3. El manifiesto ágil
🎯 Idea clave
- El Manifiesto Ágil es el documento fundacional que unificó conceptualmente el desarrollo ágil de software.
- Fue publicado en febrero de 2001 por diecisiete profesionales del software en Snowbird, Utah.
- No es una norma jurídica ni una metodología cerrada, sino una declaración de valores y principios.
- Establece una jerarquía de prioridades que reordena la forma de entender el desarrollo de software.
- Su brevedad y carácter declarativo permiten su aplicación en cualquier contexto metodológico.
- Constituye la base filosófica de enfoques como Scrum, Kanban, Lean, DevOps o DevSecOps.
📚 Desarrollo
Origen y contexto. El Manifiesto por el Desarrollo Ágil de Software (Manifesto for Agile Software Development) fue redactado entre el 11 y el 13 de febrero de 2001 en Snowbird, Utah (Estados Unidos). Surgió como respuesta a los modelos tradicionales de desarrollo, como el en cascada, que resultaban rígidos e ineficaces en entornos complejos y cambiantes. Diecisiete profesionales del software, representantes de metodologías alternativas desarrolladas en las décadas de 1980 y 1990, se reunieron para sintetizar una filosofía común.
Naturaleza del documento. El Manifiesto Ágil no es una norma técnica, un reglamento obligatorio ni una metodología prescriptiva. Es una declaración breve —menos de 400 palabras en su versión original— que articula valores y principios para guiar el desarrollo de software. Su virtud radica en su flexibilidad: al no imponer herramientas, roles o ceremonias concretas, puede adaptarse a distintos contextos y métodos, desde Scrum hasta DevOps.
Valores como eje central. El documento establece cuatro valores comparativos que redefinen las prioridades en el desarrollo de software. Estos valores no niegan la importancia de elementos como la documentación, los contratos o la planificación, pero sitúan por encima de ellos aspectos como las personas, el software funcionando, la colaboración con el cliente y la adaptación al cambio. Esta estructura comparativa evita interpretaciones dogmáticas y subraya que la agilidad no implica ausencia de procesos, sino una reordenación de su importancia.
Principios operativos. Además de los valores, el Manifiesto incluye doce principios que desarrollan su filosofía. Estos principios, como la entrega temprana y continua de software valioso o la adaptación a los cambios incluso en etapas avanzadas, proporcionan un marco operativo sin imponer soluciones concretas. Su formulación genérica permite aplicarlos en proyectos de diversa naturaleza, incluidos los del ámbito sanitario o administrativo.
Impacto en el sector público. El Manifiesto Ágil ha influido en la transformación digital de diversas administraciones públicas europeas. En España, organismos como la AEAT, la Seguridad Social o el SEPE han incorporado prácticas ágiles en sus proyectos. En Andalucía, la Agencia Digital del SAS ha adoptado equipos ágiles, alineándose con esta filosofía para mejorar la eficiencia y la respuesta a las necesidades cambiantes de los usuarios.
Relación con metodologías ágiles. Aunque el Manifiesto no prescribe técnicas específicas, su marco conceptual es la base de metodologías como Scrum, Kanban o Lean. Estas metodologías desarrollan los valores y principios del Manifiesto, adaptándolos a contextos concretos. Por ejemplo, Scrum estructura iteraciones y roles, mientras que Kanban visualiza el flujo de trabajo, pero ambas beben de la misma filosofía ágil.
Relevancia para opositores. Para la categoría de Técnico/a Especialista en Informática del SAS, el Manifiesto Ágil es un contenido de alta probabilidad en los exámenes. Se recomienda memorizar la fecha de publicación (febrero de 2001), el lugar (Snowbird, Utah), el número de firmantes (diecisiete), los cuatro valores en su formulación literal y los principios más característicos, como el 1, 3, 7, 9, 10 y 12.
🧩 Elementos esenciales
- Fecha y lugar de publicación: Febrero de 2001 en Snowbird, Utah (Estados Unidos).
- Firmantes: Diecisiete profesionales del desarrollo de software.
- Naturaleza del documento: Declaración de valores y principios, no una norma ni metodología cerrada.
- Valores del Manifiesto: Cuatro comparaciones que priorizan personas, software funcionando, colaboración y adaptación al cambio.
- Principios del Manifiesto: Doce directrices operativas que desarrollan los valores sin imponer soluciones concretas.
- Flexibilidad: Su brevedad y carácter genérico permiten adaptarlo a distintos contextos y metodologías.
- Base filosófica: Fundamento de enfoques como Scrum, Kanban, Lean, DevOps o DevSecOps.
- Aplicación en el sector público: Inspirador de iniciativas ágiles en administraciones como la AEAT, la Seguridad Social o el SAS.
- Contenido clave para opositores: Fecha, lugar, firmantes, valores y principios numerados (especialmente 1, 3, 7, 9, 10 y 12).
- Estructura comparativa: No elimina elementos como documentación o planificación, pero les da menor prioridad.
- Fuente primaria: Texto original disponible en
agilemanifesto.org.
- Diferenciación: No es una metodología, sino un marco de valores que reorienta el desarrollo de software.
🧠 Recuerda
- El Manifiesto Ágil no es una norma jurídica ni una metodología prescriptiva.
- Fue creado en 2001 por diecisiete expertos en Snowbird, Utah.
- Establece cuatro valores y doce principios como base filosófica.
- Prioriza personas, software funcionante, colaboración y adaptación al cambio.
- No elimina la documentación, los contratos o la planificación, pero les da menor importancia.
- Es la base de metodologías como Scrum, Kanban o DevOps.
- Su flexibilidad permite aplicarlo en contextos sanitarios y administrativos.
- Para opositores, es clave memorizar fecha, lugar, firmantes, valores y principios.
- Los principios 1, 3, 7, 9, 10 y 12 son especialmente relevantes para exámenes.
- El texto original está disponible en
agilemanifesto.org.
4. Métodos de desarrollo ágil: SCRUM, KANBAN
🎯 Idea clave
- SCRUM es un marco de trabajo ligero diseñado para generar valor mediante soluciones adaptativas a problemas complejos, basado en iteraciones llamadas Sprints.
- KANBAN es una estrategia para optimizar el flujo de valor a través de un proceso, centrada en la visualización y gestión activa del trabajo.
- Ambos métodos comparten principios ágiles como la transparencia, la mejora continua y la entrega frecuente de valor, pero difieren en estructura y enfoque operativo.
- SCRUM define roles, eventos y artefactos formales, mientras que KANBAN no prescribe roles ni iteraciones fijas.
- La utilidad de estos métodos para Técnicos Especialistas en Informática radica en su aplicación práctica en desarrollo, mantenimiento y gestión de equipos.
- No deben confundirse ni mezclarse sin criterio, aunque pueden complementarse en enfoques híbridos como Scrumban.
📚 Desarrollo
Definición y origen. SCRUM y KANBAN son los dos métodos de desarrollo ágil más extendidos, materializando los valores y principios del Manifiesto Ágil en reglas operativas concretas. SCRUM fue formalizado en 1995 por Jeff Sutherland y Ken Schwaber, inspirado en estudios previos sobre desarrollo de productos. KANBAN, por su parte, deriva del sistema de producción de Toyota y se adapta al trabajo del conocimiento como estrategia de optimización de flujo.
Enfoque de SCRUM. SCRUM se define como un framework ligero que organiza el trabajo en iteraciones fijas llamadas Sprints, con una duración típica de 2 a 4 semanas. Cada Sprint incluye eventos formales como la planificación, las reuniones diarias (Daily Scrum), la revisión y la retrospectiva. Además, establece tres responsabilidades claras: Product Owner (responsable del valor del producto), Scrum Master (facilitador del proceso) y Developers (equipo de desarrollo). Su objetivo es entregar incrementos de valor de forma adaptativa en entornos complejos.
Enfoque de KANBAN. KANBAN, en cambio, es una estrategia que no impone iteraciones fijas ni roles específicos. Su núcleo se basa en visualizar el flujo de trabajo, gestionar activamente los elementos en curso (WIP) y mejorar continuamente el proceso mediante políticas explícitas y métricas como la Service Level Expectation. Se aplica sobre procesos existentes, lo que facilita su adopción en áreas como soporte, mantenimiento o gestión de demanda cambiante, sin requerir cambios organizativos profundos.
Diferencias estructurales. La principal diferencia radica en su estructura: SCRUM es más prescriptivo, con eventos y artefactos definidos (como el Product Backlog o el Sprint Backlog), mientras que KANBAN es flexible y evolutivo. SCRUM exige un compromiso de equipo en cada Sprint, mientras que KANBAN prioriza la predictibilidad y el flujo continuo. Sin embargo, ambos comparten prácticas como la visualización del trabajo (mediante tableros) y la limitación del trabajo en curso, aunque implementadas de forma distinta.
Similitudes clave. Ambos métodos promueven la transparencia, la colaboración y la entrega frecuente de valor. La mejora continua es un pilar en los dos, ya sea a través de las retrospectivas en SCRUM o del análisis de métricas en KANBAN. Además, son compatibles con otros enfoques ágiles y pueden combinarse en modelos híbridos como Scrumban, que integra la cadencia de SCRUM con el flujo continuo de KANBAN.
Aplicación en el ámbito profesional. Para Técnicos Especialistas en Informática, dominar SCRUM y KANBAN es esencial para organizar equipos, gestionar backlogs o flujos de trabajo, controlar riesgos y garantizar entregas incrementales. Estos métodos permiten interpretar cuestiones prácticas sobre priorización, visualización del trabajo y mejora de procesos, independientemente de si el SAS los aplica de forma estricta o adaptada.
Posición dentro del desarrollo ágil. SCRUM y KANBAN no son sinónimos del desarrollo ágil, sino métodos operativos que lo materializan. El Manifiesto Ágil establece los valores doctrinales, mientras que estos métodos ofrecen herramientas concretas para implementarlos. SCRUM se centra en la adaptación iterativa, y KANBAN en la optimización del flujo, pero ambos contribuyen a la entrega de valor en entornos cambiantes.
🧩 Elementos esenciales
- SCRUM como framework: Marco de trabajo ligero con roles (Product Owner, Scrum Master, Developers), eventos (Sprint Planning, Daily Scrum, Sprint Review, Retrospective) y artefactos (Product Backlog, Sprint Backlog, Increment).
- KANBAN como estrategia: Método de gestión del flujo basado en visualización, limitación del WIP y mejora continua, sin roles ni eventos prescritos.
- Iteraciones vs. flujo continuo: SCRUM trabaja en Sprints de duración fija; KANBAN opera en flujo continuo sin iteraciones obligatorias.
- Roles en SCRUM: Tres responsabilidades definidas para garantizar la entrega de valor y la adaptación al cambio.
- Visualización del trabajo: Ambos métodos usan tableros (físicos o digitales) para hacer visible el estado de las tareas.
- Limitación del trabajo en curso: SCRUM limita el trabajo mediante el Sprint Backlog; KANBAN lo hace con límites explícitos de WIP.
- Mejora continua: SCRUM la aborda en retrospectivas; KANBAN mediante el análisis de métricas y políticas explícitas.
- Adaptabilidad: SCRUM requiere cambios organizativos para su adopción; KANBAN se superpone a procesos existentes.
- Enfoque de producto vs. flujo: SCRUM es ideal para desarrollo de productos complejos; KANBAN para operaciones, soporte o mantenimiento.
- Scrumban: Variante híbrida que combina la estructura de SCRUM con el flujo continuo de KANBAN.
- Predictibilidad: KANBAN busca predecir plazos mediante métricas como la Service Level Expectation; SCRUM mediante la planificación de Sprints.
- Transparencia: Ambos métodos priorizan la visibilidad del trabajo y la colaboración del equipo.
🧠 Recuerda
- SCRUM y KANBAN no son lo mismo: el primero es un framework estructurado; el segundo, una estrategia de flujo.
- SCRUM define roles, eventos y artefactos; KANBAN no prescribe ninguno de estos elementos.
- Ambos métodos comparten principios ágiles como la transparencia y la mejora continua.
- SCRUM trabaja en iteraciones fijas (Sprints); KANBAN en flujo continuo.
- La visualización del trabajo y la limitación del WIP son prácticas comunes, aunque implementadas de forma distinta.
- KANBAN es más flexible y se adapta a procesos existentes sin cambios organizativos profundos.
- SCRUM es ideal para desarrollo de productos; KANBAN para operaciones o mantenimiento.
- Scrumban combina elementos de ambos métodos para mayor flexibilidad.
- Dominar estos métodos es útil para gestionar equipos, backlogs y flujos de trabajo en entornos tecnológicos.
- No deben mezclarse sin criterio, aunque pueden complementarse en enfoques híbridos.
5. LEAN
🎯 Idea clave
- LEAN es una filosofía de gestión orientada a maximizar el valor entregado al cliente mediante la eliminación sistemática del desperdicio.
- Su origen se remonta al Sistema de Producción Toyota, pero su aplicación en desarrollo de software fue formalizada por Mary y Tom Poppendieck.
- En el contexto ágil, LEAN no es un método de desarrollo en sí mismo, sino una base conceptual que inspira otros marcos como Scrum o Kanban.
- El concepto central de LEAN es la identificación y eliminación del desperdicio (muda), entendido como cualquier actividad que no aporta valor al cliente.
- LEAN promueve la mejora continua del sistema de trabajo, el flujo de valor y el aprendizaje organizacional.
- Su enfoque es transversal y puede aplicarse junto a otros métodos ágiles para optimizar procesos de desarrollo de software.
📚 Desarrollo
Filosofía de valor. LEAN se fundamenta en la creación de valor como objetivo primordial de cualquier proceso. En desarrollo de software, esto implica centrar el trabajo en aquellas funcionalidades o mejoras que realmente aporten beneficio al usuario final o al cliente. El valor no se limita a la entrega de código, sino que incluye aspectos como la usabilidad, la fiabilidad y la alineación con las necesidades reales del negocio.
Origen y adaptación al software. Aunque LEAN surgió en el ámbito industrial, su aplicación al desarrollo de software fue sistematizada por Mary y Tom Poppendieck en su obra Lean Software Development: An Agile Toolkit. Esta adaptación traslada los principios del pensamiento lean al trabajo del conocimiento, donde el desperdicio no se mide en materiales físicos, sino en tiempo, esfuerzo o recursos mal invertidos en actividades que no generan valor tangible.
Eliminación del desperdicio. El concepto de muda (desperdicio) es central en LEAN. En software, el desperdicio puede manifestarse en forma de código no utilizado, funcionalidades sobredimensionadas, esperas en procesos, burocracia innecesaria o retrabajo por falta de claridad en los requisitos. LEAN propone identificar estas fuentes de desperdicio y eliminarlas mediante la optimización del flujo de trabajo y la simplificación de procesos.
Mejora continua del sistema. LEAN no se limita a optimizar tareas individuales, sino que promueve la mejora del sistema en su conjunto. Esto implica analizar cómo interactúan los diferentes componentes del proceso de desarrollo, desde la captura de requisitos hasta la entrega del producto, para identificar cuellos de botella, ineficiencias o puntos de fricción. La mejora continua (kaizen) es un principio activo que requiere revisión constante y adaptación basada en datos y feedback.
Flujo de valor. LEAN enfatiza la importancia de visualizar y optimizar el flujo de valor, es decir, el conjunto de actividades que transforman una idea en un producto entregable. En desarrollo de software, esto puede traducirse en la gestión de backlogs, la priorización de tareas o la automatización de procesos repetitivos. El objetivo es reducir los tiempos de entrega y aumentar la capacidad de respuesta ante cambios en los requisitos o en el entorno.
Aprendizaje organizacional. LEAN fomenta una cultura de aprendizaje continuo, donde los errores se ven como oportunidades para mejorar y no como fallos individuales. En el contexto del desarrollo ágil, esto se alinea con principios como la retroalimentación temprana, la experimentación controlada y la adaptación iterativa. El aprendizaje no se limita al equipo de desarrollo, sino que involucra a toda la organización, incluyendo a stakeholders y clientes.
Complementariedad con otros métodos. LEAN no es un marco de trabajo cerrado, sino una filosofía que puede integrarse con otros métodos ágiles como Scrum o Kanban. Por ejemplo, Scrum puede estructurar el trabajo en iteraciones, mientras que LEAN proporciona los criterios para evaluar si cada iteración está generando valor real. Del mismo modo, Kanban puede visualizar el flujo de trabajo, y LEAN aporta las herramientas para identificar y eliminar desperdicios en ese flujo.
Aplicación en entornos públicos. En organizaciones como el Servicio Andaluz de Salud, LEAN puede ser especialmente útil para optimizar procesos de desarrollo de software en entornos con recursos limitados y alta demanda de eficiencia. La eliminación de desperdicios en la gestión de proyectos tecnológicos permite liberar recursos para priorizar iniciativas que mejoren la atención al ciudadano o la operatividad de los sistemas sanitarios.
🧩 Elementos esenciales
- Valor: Resultado legítimo de un proceso, medido desde la perspectiva del cliente o usuario final.
- Desperdicio (muda): Cualquier actividad, recurso o tiempo que no contribuye a generar valor para el cliente.
- Flujo de valor: Secuencia de actividades que transforman una idea en un producto o servicio entregable.
- Mejora continua (kaizen): Proceso de optimización constante basado en la identificación y eliminación de ineficiencias.
- Sistema de trabajo: Conjunto de procesos, herramientas y personas que interactúan para desarrollar software.
- Aprendizaje organizacional: Cultura que promueve la experimentación, el feedback y la adaptación como motores de mejora.
- Eliminación de desperdicios: Estrategia para identificar y suprimir actividades innecesarias, como retrabajo, esperas o funcionalidades sobredimensionadas.
- Pensamiento lean: Enfoque que prioriza la eficiencia, la simplicidad y la entrega de valor sobre la adherencia a procesos rígidos.
- Automatización: Herramienta clave para reducir desperdicios en tareas repetitivas y acelerar el flujo de valor.
- Feedback temprano: Mecanismo para validar hipótesis y ajustar el desarrollo antes de invertir recursos excesivos.
- Priorización: Proceso de selección de tareas basado en su contribución al valor entregado al cliente.
- Transversalidad: Capacidad de LEAN para integrarse con otros métodos ágiles sin sustituirlos.
🧠 Recuerda
- LEAN es una filosofía, no un método de desarrollo ágil en sentido estricto.
- Su objetivo principal es maximizar el valor entregado al cliente mediante la eliminación del desperdicio.
- El concepto de muda (desperdicio) es clave para identificar ineficiencias en los procesos de desarrollo.
- LEAN promueve la mejora continua del sistema de trabajo, no solo de tareas individuales.
- Puede aplicarse junto a otros marcos como Scrum o Kanban para optimizar resultados.
- En entornos públicos, LEAN ayuda a priorizar recursos en iniciativas con mayor impacto social.
- La visualización del flujo de valor es esencial para detectar cuellos de botella.
- El aprendizaje organizacional y la experimentación son pilares de la cultura lean.
- LEAN no sustituye a otros métodos, sino que los complementa con una lógica de eficiencia.
- Su aplicación en software fue formalizada por Mary y Tom Poppendieck.
6. DevOps, DevSecOps
🎯 Idea clave
- DevOps integra desarrollo y operaciones para acelerar la entrega de software con mayor calidad y colaboración.
- DevSecOps incorpora la seguridad como parte integral del ciclo de vida del desarrollo, no como una fase posterior.
- La seguridad en DevSecOps se desplaza hacia etapas tempranas (shift security left) para reducir costes y riesgos.
- En el sector sanitario, DevSecOps es esencial por la criticidad de los datos y la exigencia normativa.
- La Junta de Andalucía y el SAS adoptan DevSecOps mediante plataformas corporativas y automatización de procesos.
- La automatización de comprobaciones de seguridad y la trazabilidad son pilares de estos modelos en entornos públicos.
📚 Desarrollo
Definición y evolución. DevOps surge como una evolución de las metodologías ágiles para unificar desarrollo (Dev) y operaciones (Ops), eliminando barreras entre equipos y fomentando la entrega continua de software. Su objetivo es mejorar la colaboración, reducir tiempos de despliegue y aumentar la fiabilidad de los sistemas. DevSecOps amplía este enfoque al integrar la seguridad (Sec) como un componente transversal, asegurando que los controles de protección se apliquen desde el inicio del ciclo de vida del desarrollo.
Seguridad integrada. En DevSecOps, la seguridad no se limita a una fase final de auditoría, sino que se incorpora en cada etapa del pipeline de desarrollo. Esto incluye la automatización de pruebas de seguridad, el análisis de dependencias de terceros, el control de configuraciones sensibles y la revisión continua de vulnerabilidades. La premisa es que detectar y corregir problemas de seguridad en fases tempranas reduce costes y minimiza riesgos, especialmente en entornos con datos sensibles como el sanitario.
Aplicación en el SAS. El Servicio Andaluz de Salud (SAS) adopta DevSecOps como respuesta a la necesidad de evolucionar sus soluciones digitales de forma ágil y segura. Dada la criticidad de los sistemas que gestionan datos de salud y procesos clínicos, la seguridad no puede tratarse como un complemento, sino como un requisito inherente al diseño, desarrollo y operación. La Junta de Andalucía proporciona un ecosistema corporativo que facilita esta adopción, con herramientas como plataformas CI/CD, repositorios de código y normas como ADAFlow para la estrategia de ramificación.
Plataformas y herramientas. La Junta de Andalucía dispone de una plataforma corporativa CI/CD que integra herramientas para la integración y entrega continua, análisis estático de código, control de dependencias y verificación de imágenes. Estas infraestructuras permiten automatizar procesos, garantizar la trazabilidad y mantener un flujo de trabajo gobernado y medible. En el SAS, este enfoque se aplica a soluciones digitales corporativas y servicios críticos, donde la automatización y la colaboración estructurada son clave para mantener la disponibilidad y la seguridad.
Beneficios en entornos sanitarios. La adopción de DevSecOps en el sector sanitario responde a la necesidad de adaptarse a entornos dinámicos, donde los requisitos funcionales y normativos cambian con frecuencia. La entrega continua de mejoras, la validación temprana de cambios y la integración de la seguridad desde el diseño permiten al SAS responder con agilidad a nuevas necesidades asistenciales u organizativas, sin comprometer la protección de los datos ni la continuidad de los servicios.
Cultura y responsabilidad compartida. DevSecOps promueve una cultura en la que la seguridad es responsabilidad de todos los miembros del equipo, no solo de los especialistas. Desarrolladores, operadores y expertos en seguridad colaboran para identificar riesgos, implementar controles y aprender de incidentes. Esta filosofía se alinea con los principios ágiles y refuerza la idea de que la calidad y la seguridad son objetivos compartidos, no tareas aisladas.
Transición y adopción progresiva. La documentación oficial de la Junta de Andalucía destaca que la adopción de DevSecOps es un proceso evolutivo, no un cambio abrupto. Los equipos del SAS y otras organizaciones públicas incorporan gradualmente estas prácticas, apoyándose en herramientas corporativas y en la formación continua. Esta transición permite adaptar los modelos a las necesidades específicas de cada proyecto, manteniendo un equilibrio entre agilidad, seguridad y gobernanza.
🧩 Elementos esenciales
- DevOps: Metodología que integra desarrollo y operaciones para acelerar la entrega de software con mayor colaboración y automatización.
- DevSecOps: Extensión de DevOps que incorpora la seguridad como parte integral del ciclo de vida del desarrollo, no como una fase posterior.
- Shift security left: Principio de DevSecOps que consiste en integrar la seguridad en etapas tempranas del desarrollo para reducir riesgos y costes.
- Plataforma CI/CD: Infraestructura corporativa de la Junta de Andalucía que automatiza procesos de integración, entrega y despliegue continuo.
- Automatización de seguridad: Uso de herramientas para realizar comprobaciones de seguridad, análisis de dependencias y control de vulnerabilidades en el pipeline de desarrollo.
- ADAFlow: Norma corporativa andaluza que establece estrategias de ramificación y gestión de código en entornos DevOps.
- Trazabilidad: Capacidad de rastrear cambios, incidencias y procesos a lo largo del ciclo de vida del software, garantizando transparencia y control.
- Cultura colaborativa: Enfoque en el que desarrolladores, operadores y especialistas en seguridad trabajan conjuntamente para garantizar calidad y protección.
- Entornos sanitarios: Sector donde DevSecOps es especialmente relevante por la criticidad de los datos y las exigencias normativas (ENS, RGPD, NIS2).
- Evolución continua: Proceso gradual de adopción de DevSecOps en el SAS, apoyado en herramientas corporativas y formación de equipos.
- Gobernanza: Marco que asegura que los procesos de desarrollo y operación cumplan con estándares de calidad, seguridad y cumplimiento normativo.
- Herramientas integradas: Conjunto de utilidades (GitLab, repositorios de artefactos, análisis estático) que soportan el ciclo completo de desarrollo en el ecosistema andaluz.
🧠 Recuerda
- DevOps une desarrollo y operaciones para mejorar la entrega de software.
- DevSecOps añade la seguridad como parte integral del proceso, no como una fase final.
- La seguridad debe integrarse desde el diseño (shift security left).
- En el SAS, DevSecOps es clave por la sensibilidad de los datos sanitarios.
- La Junta de Andalucía proporciona plataformas corporativas para soportar DevSecOps.
- La automatización de pruebas y controles es esencial en estos modelos.
- La cultura colaborativa es un pilar de DevSecOps.
- La adopción de DevSecOps es progresiva y se adapta a las necesidades de cada proyecto.
- La trazabilidad y la gobernanza son fundamentales en entornos públicos.
- Las herramientas integradas facilitan la implementación de DevSecOps en el ecosistema andaluz.