Título oficial del programa: Desarrollo ágil de software. Filosofía y principios del desarrollo ágil. El manifiesto ágil. Métodos de desarrollo ágil: SCRUM, KANBAN. LEAN. DevOps, DevSecOps.
Definición y propósito. El desarrollo ágil de software es un conjunto de metodologías orientadas a la creación de sistemas de información mediante entregas frecuentes, aprendizaje continuo y colaboración estrecha. Su objetivo principal es reducir riesgos como la entrega de productos que no satisfacen las necesidades del usuario, retrasos o sobrecostes, mediante la incorporación constante de feedback y versiones funcionales del software.
Enfoque iterativo e incremental. A diferencia del modelo en cascada, donde las fases (análisis, diseño, codificación, pruebas) se ejecutan de forma secuencial, el desarrollo ágil trabaja en ciclos cortos llamados iteraciones o sprints. Cada iteración produce una versión operable del software, permitiendo ajustes basados en la retroalimentación de usuarios y stakeholders.
Flexibilidad y adaptabilidad. La agilidad se caracteriza por su capacidad para responder a cambios en requisitos, prioridades o contexto tecnológico. Esto no significa ausencia de planificación, sino una planificación adaptativa que evoluciona con el proyecto. La documentación se prioriza según su utilidad, evitando la exhaustividad innecesaria que no aporta valor.
Colaboración y transparencia. El desarrollo ágil fomenta la comunicación constante entre equipos multidisciplinares y partes interesadas, incluyendo clínicos, gestores y pacientes en el caso del SAS. La transparencia en el proceso y los artefactos (como el backlog de producto) es clave para alinear expectativas y garantizar que el software entregado responda a necesidades reales.
Valores y principios. Formalizados en el Manifiesto Ágil (2001), los valores del desarrollo ágil incluyen la priorización de individuos e interacciones sobre procesos y herramientas, software funcional sobre documentación exhaustiva, colaboración con el cliente sobre negociación contractual, y respuesta al cambio sobre seguimiento de un plan. Estos valores se concretan en doce principios que guían la práctica ágil.
Aplicación en el SAS. El Servicio Andaluz de Salud adopta metodologías ágiles para gestionar la evolución de sistemas críticos en un entorno marcado por cambios normativos, epidemiológicos y tecnológicos. La Agencia Digital de Andalucía respalda expresamente el uso de Scrum, destacando beneficios como la priorización del valor para el usuario, la flexibilidad ante cambios y la mejora de la calidad y fiabilidad del software.
Delimitación conceptual. Es importante distinguir el desarrollo ágil de conceptos erróneos como la improvisación o la falta de controles. La agilidad implica disciplina en la gestión del trabajo, trazabilidad de los cambios y cumplimiento de estándares de calidad. No elimina la documentación, sino que la adapta a lo estrictamente necesario para garantizar la operatividad y el mantenimiento del sistema.
Marco institucional. La Junta de Andalucía, a través de su Estrategia de Transformación Digital del Sistema Sanitario Público (2021-2026), promueve la adopción de metodologías ágiles para proyectos como la historia clínica digital o la telemedicina. Además, la Ley de Contratos del Sector Público permite la contratación de servicios bajo modelos ágiles, siempre que se garantice transparencia y competencia.
Has leído la base del tema. En la demo puedes convertirlo en preguntas justificadas de Técnico/a Especialista en Informática y repasar tus fallos.
Probar demo gratis con preguntas de este temaOrigen y propósito. El desarrollo ágil surge como respuesta a las limitaciones de los modelos tradicionales, como el en cascada, que resultaban inflexibles ante cambios en los requisitos. Su filosofía se centra en la entrega de valor de manera incremental, permitiendo ajustes continuos basados en la retroalimentación de los usuarios y las condiciones del entorno. Este enfoque busca reducir riesgos y garantizar que el software desarrollado responda a necesidades reales y cambiantes.
Colaboración y participación. Uno de los pilares fundamentales es la colaboración activa entre los miembros del equipo y los stakeholders, especialmente los clientes. A diferencia de los modelos tradicionales, donde la participación del cliente se limita a fases iniciales y finales, el desarrollo ágil integra su feedback de manera continua. Esto asegura que el producto final se alinee con las expectativas y requisitos operativos, evitando desviaciones costosas en etapas avanzadas.
Entrega incremental. El desarrollo ágil se estructura en iteraciones cortas, generalmente de 1 a 4 semanas, en las que se entrega software funcional. Cada iteración incluye planificación, desarrollo, pruebas y revisión, lo que permite validar avances de forma periódica. Este enfoque no solo facilita la detección temprana de errores, sino que también proporciona valor tangible en plazos reducidos, mejorando la satisfacción del cliente.
Flexibilidad y gestión del cambio. La capacidad de adaptarse a cambios en los requisitos, incluso en etapas avanzadas, es una característica distintiva del desarrollo ágil. Mientras que los modelos tradicionales penalizan las modificaciones por su impacto en costes y plazos, el enfoque ágil las integra como parte natural del proceso. Esto se logra mediante prácticas como la priorización dinámica de tareas y la revisión constante de prioridades.
Excelencia técnica y simplicidad. La filosofía ágil promueve la excelencia técnica como medio para garantizar la calidad del software. Esto incluye la adopción de buenas prácticas de desarrollo, como el refactoring, las pruebas automatizadas y la integración continua. Además, se valora la simplicidad, entendida como la optimización del trabajo necesario para alcanzar los objetivos, evitando sobrecargas de funcionalidades o documentación innecesaria.
Reflexión y mejora continua. Los equipos ágiles dedican tiempo a reflexionar sobre su desempeño y procesos, identificando oportunidades de mejora. Esta práctica, conocida como retrospectiva, se realiza al final de cada iteración y permite ajustar metodologías, herramientas y dinámicas de trabajo. La mejora continua es un principio clave que impulsa la eficiencia y la adaptación a nuevos desafíos.
Valores del Manifiesto Ágil. El desarrollo ágil se sustenta en cuatro valores fundamentales: individuos e interacciones sobre procesos y herramientas; software funcionando sobre documentación exhaustiva; colaboración con el cliente sobre negociación contractual; y respuesta al cambio sobre seguimiento de un plan. Estos valores guían las decisiones y prioridades en los proyectos, priorizando siempre la entrega de valor y la satisfacción del cliente.
Origen y contexto. El Manifiesto Ágil fue publicado en 2001 por diecisiete expertos en desarrollo de software, conocidos como la Agile Alliance. Surgió como respuesta a los modelos tradicionales, como el en cascada, que resultaban rígidos e ineficaces para proyectos con requisitos cambiantes. Su objetivo era formalizar un enfoque más flexible, centrado en la entrega de valor y la colaboración.
Valores fundamentales. El manifiesto se estructura en torno a cuatro valores esenciales. El primero, individuos e interacciones sobre procesos y herramientas, enfatiza que las personas y su comunicación son más importantes que los procedimientos o las herramientas técnicas. El segundo, software operativo sobre documentación exhaustiva, prioriza la funcionalidad del producto frente a la generación de documentos detallados. El tercero, colaboración con el cliente sobre negociación contractual, fomenta la participación activa del cliente durante todo el proyecto. El cuarto, respuesta al cambio sobre seguimiento de un plan, reconoce que la capacidad de adaptación es crucial en entornos dinámicos.
Principios operativos. Los doce principios del Manifiesto Ágil concretan cómo aplicar sus valores en la práctica. Entre ellos destacan la entrega temprana y continua de software con valor, la aceptación de cambios en los requisitos incluso en fases avanzadas, y la colaboración diaria entre responsables del negocio y desarrolladores. También se subraya la importancia de trabajar con individuos motivados, proporcionarles el entorno adecuado y fomentar la comunicación cara a cara como método más eficiente de transmisión de información.
Enfoque en la sostenibilidad. Uno de los principios clave es la promoción de un ritmo de desarrollo sostenible, donde promotores, desarrolladores y usuarios mantengan un equilibrio constante. Esto contrasta con los modelos tradicionales, que suelen generar picos de trabajo intensivo y estrés en las fases finales. La simplicidad y la excelencia técnica también son pilares, buscando maximizar la eficiencia y minimizar el trabajo innecesario.
Impacto en el sector público. En el contexto del Servicio Andaluz de Salud (SAS), el Manifiesto Ágil ha servido para impulsar proyectos con mayor participación de los profesionales clínicos y una adaptación más ágil a normativas cambiantes. Por ejemplo, la implementación de prototipos clínicos en lugar de especificaciones técnicas extensas refleja el valor de software operativo sobre documentación exhaustiva. Asimismo, la colaboración continua con los usuarios finales ha mejorado la aceptación de los sistemas desarrollados.
Relación con metodologías ágiles. Aunque el Manifiesto Ágil no prescribe una metodología concreta, sus valores y principios son la base de frameworks como Scrum o Kanban. Scrum, por ejemplo, materializa el principio de entregas frecuentes mediante sprints de 1 a 4 semanas, mientras que Kanban aplica el enfoque de mejora continua a través de la visualización del flujo de trabajo. Ambos métodos comparten el compromiso con la transparencia, la inspección y la adaptación, conceptos inherentes al manifiesto.
Diferencias con modelos tradicionales. Frente al modelo en cascada, que define requisitos al inicio y dificulta los cambios, el Manifiesto Ágil aboga por un enfoque iterativo e incremental. Mientras que el modelo tradicional entrega el software al final del proyecto, el ágil lo hace de forma frecuente y en plazos cortos, reduciendo riesgos y permitiendo ajustes basados en feedback real. Esta flexibilidad es especialmente valiosa en entornos complejos como el sanitario, donde las necesidades pueden evolucionar rápidamente.
Marco de trabajo Scrum. Scrum es un marco ágil diseñado para desarrollar y mantener productos complejos, especialmente en entornos donde los requisitos evolucionan con frecuencia. Se organiza en iteraciones llamadas sprints, que suelen durar entre dos y cuatro semanas, y cuyo objetivo es entregar un incremento de producto potencialmente utilizable. Scrum no es una metodología cerrada, sino un conjunto de prácticas, roles y artefactos que proporcionan estructura sin limitar la creatividad del equipo.
Roles en Scrum. El equipo Scrum está compuesto por tres responsabilidades principales: Developers (desarrolladores), Product Owner (dueño del producto) y Scrum Master. Los Developers son responsables de crear el incremento del producto durante el sprint. El Product Owner maximiza el valor del producto gestionando el Product Backlog y priorizando las necesidades. El Scrum Master actúa como facilitador, eliminando impedimentos y asegurando que el equipo siga los principios y prácticas de Scrum.
Eventos en Scrum. Scrum define una serie de eventos estructurados para garantizar la transparencia y la adaptación. El Sprint Planning marca el inicio del sprint, donde el equipo selecciona los elementos del Product Backlog que se compromete a completar. El Daily Scrum es una reunión diaria de sincronización, con una duración máxima de 15 minutos, donde los Developers planifican el trabajo del día. La Sprint Review permite al equipo presentar el incremento al Product Owner y otros stakeholders para obtener retroalimentación. Finalmente, la Sprint Retrospective es una oportunidad para reflexionar sobre el proceso y proponer mejoras.
Artefactos en Scrum. Los artefactos en Scrum son herramientas clave para la transparencia y el seguimiento del progreso. El Product Backlog es una lista ordenada de todo lo que se necesita en el producto, gestionada por el Product Owner. El Sprint Backlog contiene los elementos seleccionados del Product Backlog para el sprint actual, junto con el plan para entregarlos. El Incremento es el resultado tangible del sprint, que debe ser potencialmente entregable y cumplir con la Definition of Done (definición de terminado) acordada por el equipo.
Método Kanban. Kanban es un método ágil que se centra en la visualización del flujo de trabajo y la optimización del mismo. A diferencia de Scrum, no impone iteraciones fijas ni roles específicos, lo que lo hace especialmente útil en entornos con alta variabilidad, como el mantenimiento de sistemas o el soporte técnico. Kanban utiliza tableros visuales con columnas que representan las diferentes etapas del flujo de trabajo, permitiendo identificar cuellos de botella y mejorar la eficiencia.
Principios de Kanban. Kanban se basa en cuatro principios fundamentales: visualizar el flujo de trabajo, limitar el trabajo en progreso (WIP), gestionar el flujo y mejorar continuamente. La visualización del trabajo en un tablero Kanban permite a todos los miembros del equipo entender el estado actual de las tareas. Limitar el WIP evita la sobrecarga del equipo y mejora la productividad. La gestión del flujo se centra en optimizar el tiempo que tarda una tarea en pasar de inicio a fin. La mejora continua se logra mediante la reflexión y la adaptación constante del proceso.
Diferencias clave entre Scrum y Kanban. Mientras que Scrum es un marco prescriptivo con roles, eventos y artefactos definidos, Kanban es un método flexible que no impone estructuras rígidas. Scrum se organiza en sprints de duración fija, mientras que Kanban permite un flujo continuo de trabajo. Scrum prioriza la entrega incremental de valor en ciclos cortos, mientras que Kanban se enfoca en optimizar el flujo y reducir el tiempo de entrega. Ambos métodos son complementarios y pueden combinarse en función de las necesidades del proyecto.
Aplicación en el sector público. En el contexto del Servicio Andaluz de Salud (SAS), la aplicación de Scrum y Kanban puede mejorar la eficiencia en el desarrollo de sistemas de información. Scrum es ideal para proyectos con objetivos claros y requisitos que evolucionan, mientras que Kanban es más adecuado para entornos de soporte y mantenimiento, donde la demanda es variable y prioritaria. La transparencia y la adaptación continua son clave para garantizar la calidad y la seguridad en los sistemas del sector público.
Origen y filosofía. Lean surge en el ámbito industrial, específicamente en el Sistema de Producción de Toyota (TPS), desarrollado por Taiichi Ohno. Su propósito fundamental es maximizar el valor entregado al cliente eliminando sistemáticamente los desperdicios (muda), la sobrecarga (muri) y la variabilidad (mura). Aunque su origen es manufacturero, sus principios se han adaptado con éxito al desarrollo de software, dando lugar a Lean Software Development (LSD).
Enfoque en el valor. En el contexto del desarrollo ágil, Lean no se limita a ser un marco metodológico como Scrum o Kanban, sino que actúa como una filosofía de trabajo. Su núcleo se centra en identificar qué actividades generan valor real para el cliente y cuáles constituyen desperdicios, como esperas, retrabajos o funcionalidades no utilizadas. Este enfoque permite optimizar recursos y mejorar la calidad del producto final.
Mejora continua (kaizen). Uno de los pilares de Lean es la mejora continua, conocida como kaizen. Este principio implica la reflexión constante sobre los procesos, la identificación de oportunidades de mejora y la implementación de cambios incrementales. En el desarrollo de software, se traduce en prácticas como retrospectivas, análisis de flujo de trabajo y adaptación basada en datos y feedback continuo.
Principios de Lean Software Development. La adaptación de Lean al desarrollo de software se estructura en siete principios clave, propuestos por los Poppendieck. Estos incluyen eliminar desperdicios, amplificar el aprendizaje, tomar decisiones lo más tarde posible, entregar valor temprano, potenciar al equipo, crear integridad en el producto y visualizar el sistema completo. Estos principios no están respaldados por una norma ISO específica, pero se alinean con estándares de calidad como ISO 9001:2015 e ISO/IEC 25010:2011.
Relación con otros métodos ágiles. Lean es complementario a otros marcos ágiles. Por ejemplo, Kanban se basa directamente en principios Lean, como la visualización del flujo y la limitación del trabajo en curso (WIP). Scrum también incorpora elementos Lean, como la entrega incremental y las retrospectivas. Esta sinergia permite combinar enfoques para adaptarse a las necesidades específicas de cada proyecto, especialmente en entornos públicos como el Servicio Andaluz de Salud.
Aplicación en el sector público. En el ámbito de las administraciones públicas, Lean se utiliza para optimizar procesos de desarrollo de sistemas de información, reduciendo burocracia y mejorando la eficiencia. Su enfoque en la eliminación de desperdicios y la mejora continua resulta especialmente útil para proyectos con recursos limitados y requisitos cambiantes, como los del SAS. Además, se alinea con metodologías públicas como MÉTRICA v3, aunque con un enfoque más ágil y menos prescriptivo.
Errores comunes en la implementación. Adoptar Lean requiere más que reducir costes o instalar herramientas. Un error frecuente es identificar el desperdicio únicamente con la reducción de gastos, ignorando aspectos como las esperas, el retrabajo o las funcionalidades no utilizadas. Otro fallo es aplicar Lean de manera aislada, sin integrarlo con la cultura organizacional o con otros métodos ágiles, lo que limita su efectividad.
Definición de DevOps. DevOps es una filosofía que conecta el desarrollo de software (Dev) con las operaciones de TI (Ops) para mejorar la entrega de cambios. Su objetivo es reducir la fricción entre equipos, aumentar la fiabilidad de los despliegues y fomentar la responsabilidad compartida sobre el servicio. No se limita a herramientas, sino que abarca cultura, procesos y prácticas técnicas como la automatización y la observabilidad.
Evolución a DevSecOps. DevSecOps surge como una extensión de DevOps al incorporar la seguridad (Sec) como un pilar fundamental en todas las fases del ciclo de vida del desarrollo de software (SDLC). A diferencia de enfoques tradicionales, donde la seguridad se aplicaba al final del proceso, DevSecOps promueve la integración temprana de controles de seguridad, conocida como shift security left. Esto permite identificar y mitigar vulnerabilidades desde las primeras etapas, evitando bloqueos tardíos en el despliegue.
Prácticas clave de DevSecOps. Entre las prácticas más relevantes se incluyen el modelado de amenazas durante el diseño, el análisis estático de código (SAST), las pruebas dinámicas de seguridad (DAST), el análisis de composición de software (SCA) para detectar vulnerabilidades en dependencias, y las pruebas de penetración automatizadas. También destacan la gestión segura de secretos, como credenciales y claves API, y la implementación de security as code y compliance as code, donde las políticas de seguridad se versionan y aplican como código.
Automatización y pipelines CI/CD. La automatización es un elemento central en DevSecOps, permitiendo la ejecución repetible de pruebas y controles de seguridad en cada fase del pipeline de integración y despliegue continuo (CI/CD). Esto incluye el escaneo de contenedores e infraestructura para detectar configuraciones inseguras o vulnerabilidades en imágenes. Sin embargo, la automatización no elimina la necesidad de criterio humano, especialmente para evaluar riesgos y detener despliegues inseguros.
Responsabilidad compartida. En DevSecOps, la seguridad deja de ser responsabilidad exclusiva de un equipo aislado y pasa a ser una responsabilidad compartida entre desarrollo, operaciones y seguridad. Esto no implica que todos los miembros del equipo deban ser expertos en seguridad, sino que los controles y prácticas se integran en el flujo de trabajo con el apoyo de especialistas. La colaboración es clave para garantizar que la seguridad no sea un obstáculo, sino un facilitador de la entrega continua.
Métricas y observabilidad. La observabilidad es fundamental para cerrar el ciclo de mejora en DevOps y DevSecOps. Métricas como el tiempo de despliegue, la frecuencia de releases, el tiempo de recuperación y la tasa de resolución de vulnerabilidades permiten evaluar el impacto de los cambios. Herramientas de monitorización, registros, trazas y alertas ayudan a detectar degradaciones, confirmar mejoras y responder rápidamente a incidentes, convirtiendo cada cambio en una oportunidad de aprendizaje.
Diferencias con DevOps. Aunque DevOps y DevSecOps comparten el mismo pipeline CI/CD, su enfoque difiere. DevOps prioriza la velocidad y fiabilidad en la entrega de software, mientras que DevSecOps añade la seguridad como un requisito transversal. En DevOps, la seguridad suele añadirse como una capa final, mientras que en DevSecOps se integra desde el diseño (security by design). Las herramientas también varían: DevOps utiliza Jenkins o Kubernetes, mientras que DevSecOps incorpora herramientas como SonarQube, Snyk o OWASP ZAP.
Marco institucional. El Secure Software Development Framework (SSDF) 1.1 del NIST es una referencia institucional para DevSecOps, ya que organiza prácticas de desarrollo seguro integrables en distintos ciclos de vida. Aunque no prescribe una implementación específica para el Servicio Andaluz de Salud, proporciona un marco útil para estructurar controles de seguridad en entornos públicos.
Practica este tema de Técnico/a Especialista en Informática con test por tema SAS, preguntas justificadas por tema y simulacros tipo examen. No son preguntas oficiales del SAS: son práctica privada de OposAs para estudiar con criterio.
Acceder a la demoHas visto un tema abierto completo. En la demo puedes comprobar cómo encajan el temario, las preguntas justificadas y los simulacros dentro de OposAs.
Qué vas a probar
La idea no es solo leer un tema: es estudiar con continuidad y comprobar cómo se relaciona con el resto de herramientas.
Verás explicaciones de la correcta y de las incorrectas para estudiar con más criterio, no solo para memorizar.
Con tu nombre y tu email, eliges categoría y te enviamos el acceso por correo sin compromiso.
Solo tu email, tu nombre y apellidos (si quieres), elige categoría y prueba antes de decidir. Es gratis.
El acceso llega por email. Si usas Hotmail, Outlook, Live, MSN o Yahoo, revisa tambien Spam o Correo no deseado.
Despues de pulsar, mira tu correo. El enlace dura 1 hora.
Revisa tambien Spam o Correo no deseado.
Hemos enviado el enlace a . Abrelo antes de 1 hora. Si usas Hotmail, Outlook, Live, MSN o Yahoo, mira primero en Correo no deseado.
Estos son los requisitos principales para Técnico/a Especialista en Informática. OposAs resume los requisitos principales para orientarte; la convocatoria oficial vigente es siempre la referencia válida.
FP2 Rama Informática, Módulo Profesional Nivel 3, Técnico Superior en Administración de Sistemas Informáticos o Técnico Superior en Desarrollo de Aplicaciones Informáticas.
La convocatoria contempla equivalencia con tres años de funciones de la categoría en centros sanitarios del Sistema Nacional de Salud.
Contrasta el resumen antes de inscribirte.
Consulta siempre la convocatoria oficial vigente antes de inscribirte.
Fuera del código también hay música, discos y radio. La misma forma de hacer las cosas: con alma, pasión y criterio.
OposAs nació preparando una oposición del SAS y se ha convertido en una forma de practicar test, corregir fallos y estudiar con explicaciones claras.
OposAs está pensado para practicar test y aprender mientras corriges, sin tragarte textos interminables antes de empezar. Cuando fallas, la justificación te ayuda a entender la correcta y, sobre todo, las incorrectas: ahí suele estar el aprendizaje.
No hay una empresa detrás. Hay una persona que construyó desde cero una herramienta para que estudiar no se convierta en algo pesado, sino en un proceso más claro, practicable y llevadero.
De opositor a opositor, Serafín.
