Tema 41 – Desarrollo Ágil de Software – Oposiciones TFA Informática SAS

TEMA 41. DESARROLLO ÁGIL DE SOFTWARE. FILOSOFÍA Y PRINCIPIOS DEL DESARROLLO ÁGIL. EL MANIFIESTO ÁGIL. MÉTODOS DE DESARROLLO ÁGIL: SCRUM, KANBAN, LEAN. DEVOPS, DEVSECOPS

📋 Índice de contenidos

1. Contextualización
2. Exposición General
3. Desarrollo
4. Conclusiones
5. Casos prácticos
6. Cuestionario de preguntas
7. Mapa conceptual
8. Referencias normativas y bibliográficas

1. 🔍 CONTEXTUALIZACIÓN

El desarrollo de software ha evolucionado significativamente desde los métodos tradicionales basados en procesos secuenciales y documentación exhaustiva (conocidos como metodologías «pesadas» o en cascada) hacia enfoques más flexibles, adaptativos e iterativos. En el contexto de las organizaciones sanitarias como el Servicio Andaluz de Salud (SAS), donde la transformación digital juega un papel fundamental en la mejora de la atención sanitaria, la adopción de metodologías ágiles resulta esencial para desarrollar soluciones tecnológicas adaptadas a las necesidades cambiantes de profesionales y pacientes.

La evolución hacia metodologías ágiles está respaldada por marcos como la Estrategia de Transformación Digital del Sistema Nacional de Salud y el Plan de Acción de Transformación Digital de Andalucía, que fomentan la implementación de prácticas y metodologías que permitan el desarrollo eficiente de servicios sanitarios digitales. En el ámbito normativo español, esta transformación se enmarca en el Real Decreto 4/2010, de 8 de enero, por el que se regula el Esquema Nacional de Interoperabilidad, que establece el marco para el desarrollo, adopción y mantenimiento de sistemas de información interoperables.

2. 📝 EXPOSICIÓN GENERAL

El desarrollo ágil representa un paradigma que prioriza la entrega incremental, la colaboración continua con usuarios finales, la adaptabilidad a los cambios y la calidad técnica del producto. Surgido como respuesta a las limitaciones de los modelos tradicionales en cascada, el enfoque ágil ha revolucionado la forma en que se desarrollan aplicaciones en entornos complejos y cambiantes como el sanitario.

Este tema aborda exhaustivamente la filosofía y principios que fundamentan el desarrollo ágil, comenzando por el análisis del Manifiesto Ágil como piedra angular de este movimiento. Posteriormente, se analizan las metodologías ágiles más relevantes (SCRUM, KANBAN, LEAN) que proporcionan marcos concretos de implementación. Finalmente, se exploran los paradigmas DevOps y DevSecOps como evoluciones que extienden la agilidad a las operaciones y la seguridad, fundamentales en entornos críticos como los sanitarios donde la disponibilidad y protección de datos son imperativos.

3. 🔧 DESARROLLO

3.1. Filosofía y principios del desarrollo ágil

3.1.1. Fundamentos filosóficos del desarrollo ágil

El enfoque ágil surge como respuesta a las limitaciones identificadas en la gestión tradicional de proyectos software, particularmente el modelo en cascada, caracterizado por:

Planificación detallada y completa desde el inicio
Progresión secuencial por fases
Documentación exhaustiva
Resistencia al cambio en los requisitos
Escasa comunicación con el cliente durante el desarrollo

La filosofía ágil, por el contrario, se fundamenta en:

Empirismo: Basar las decisiones en la experiencia y el conocimiento adquirido durante el desarrollo.
Adaptabilidad: Capacidad para responder a cambios en lugar de seguir estrictamente un plan predefinido.
Valor incremental: Entregar funcionalidades que aporten valor al cliente de forma progresiva y temprana.
Mejora continua: Reflexión periódica sobre cómo ser más efectivos y ajustar el comportamiento.
Colaboración: Interacción constante entre desarrolladores y usuarios finales.

3.1.2. Principios fundamentales

Los 12 principios del desarrollo ágil, derivados del Manifiesto, constituyen guías fundamentales para implementar esta filosofía:

Satisfacción del cliente: La prioridad más alta es satisfacer al cliente a través de la entrega temprana y continua de software con valor.
Aceptación del cambio: Los cambios en los requisitos son bienvenidos, incluso en etapas tardías del desarrollo. Los procesos ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente.
Entrega frecuente: Se entrega software funcional frecuentemente, en periodos cortos (entre dos semanas y dos meses), con preferencia por las escalas de tiempo más cortas.
Colaboración entre negocio y desarrolladores: Stakeholders y desarrolladores trabajando juntos diariamente durante todo el proyecto.
Motivación y confianza: Construir proyectos en torno a individuos motivados, proporcionándoles el entorno y apoyo que necesitan, y confiando en ellos para conseguir el trabajo.
Comunicación cara a cara: El método más eficiente y efectivo de comunicar información dentro del equipo es la conversación cara a cara.
Software funcionando como medida de progreso: El software funcional es la principal medida de progreso.
Desarrollo sostenible: Los procesos ágiles promueven un desarrollo sostenible. Promotores, desarrolladores y usuarios deben mantener un ritmo constante indefinidamente.
Excelencia técnica: La atención continua a la excelencia técnica y al buen diseño mejora la agilidad.
Simplicidad: La simplicidad, definida como el arte de maximizar la cantidad de trabajo no realizado, es esencial.
Autoorganización: Las mejores arquitecturas, requisitos y diseños emergen de equipos autoorganizados.
Autorreflexión: El equipo reflexiona regularmente sobre cómo ser más efectivo, y ajusta y perfecciona su comportamiento.

📝 Nota: Estos principios están interrelacionados y conforman un ecosistema coherente que orienta la implementación práctica de la agilidad.

3.2. El Manifiesto Ágil

3.2.1. Origen e historia del Manifiesto Ágil

En febrero de 2001, diecisiete profesionales del desarrollo software se reunieron en Snowbird, Utah (EE.UU.) para discutir alternativas a los procesos de desarrollo tradicionales, caracterizados por su rigidez y excesiva documentación. Como resultado de este encuentro, formularon el «Manifiesto para el Desarrollo Ágil de Software», firmado por:

Kent Beck (Extreme Programming)
Mike Beedle
Arie van Bennekum
Alistair Cockburn (Crystal)
Ward Cunningham
Martin Fowler
James Grenning
Jim Highsmith
Andrew Hunt
Ron Jeffries
Jon Kern
Brian Marick
Robert C. Martin
Steve Mellor
Ken Schwaber (Scrum)
Jeff Sutherland (Scrum)
Dave Thomas

Este documento representa el punto de inflexión formal hacia un nuevo paradigma de desarrollo, unificando diversas corrientes que ya exploraban alternativas al enfoque tradicional.

3.2.2. Valores fundamentales del Manifiesto

El Manifiesto Ágil establece cuatro valores fundamentales que guían el desarrollo de software:

Individuos e interacciones sobre procesos y herramientas:
- Valoración del capital humano y sus interacciones
- Priorización de la comunicación efectiva dentro del equipo
- Las herramientas y procesos como facilitadores, no como restricciones
Software funcionando sobre documentación exhaustiva:
- El producto tangible y funcional como principal entregable
- Documentación suficiente pero no excesiva
- Código limpio y autoexplicativo como forma de documentación
Colaboración con el cliente sobre negociación contractual:
- Relación colaborativa continua, no adversarial
- Feedback frecuente para ajustar expectativas y resultados
- Contratos adaptables que permitan la evolución de requisitos
Respuesta ante el cambio sobre seguir un plan:
- Adaptabilidad como ventaja competitiva
- Planificación adaptativa e iterativa
- Capacidad de respuesta a nuevas necesidades o contextos

⚠️ Importante: Estos valores se expresan en el Manifiesto como comparativas donde, aunque se reconoce el valor de los elementos de la derecha, se valoran más los elementos de la izquierda.

3.2.3. Impacto y evolución del Manifiesto

Desde su creación, el Manifiesto Ágil ha tenido un profundo impacto en la industria del software:

Establecimiento de la agilidad como paradigma dominante en múltiples sectores
Evolución desde métodos específicos hacia integración de prácticas adaptadas a cada contexto
Expansión hacia otros ámbitos: gestión organizacional, marketing, recursos humanos
Desarrollo de certificaciones profesionales y estándares de implementación
Integración con otras disciplinas: UX, DevOps, Lean
Adaptación a contextos regulados como el sanitario, fundamentales para entidades como el SAS

En el contexto sanitario, la adaptación del Manifiesto Ágil ha permitido desarrollar soluciones que responden rápidamente a necesidades clínicas cambiantes, manteniendo altos estándares de seguridad y calidad exigidos por la normativa sanitaria.

3.3. Principales métodos de desarrollo ágil

3.3.1. SCRUM

SCRUM es un marco de trabajo ágil iterativo e incremental para gestionar el desarrollo de productos complejos. Fue formalizado por Ken Schwaber y Jeff Sutherland en la década de 1990.

a) Fundamentos y características principales

SCRUM se basa en tres pilares fundamentales:

Transparencia: Todos los aspectos significativos del proceso deben ser visibles para los responsables del resultado.
Inspección: Los usuarios de SCRUM deben inspeccionar frecuentemente los artefactos y el progreso para detectar desviaciones.
Adaptación: Si se determina que algún aspecto se desvía de límites aceptables, debe ajustarse el proceso o el material siendo procesado.

b) Roles en SCRUM

Product Owner: Responsable de maximizar el valor del producto resultante del trabajo del equipo de desarrollo. Gestiona el Product Backlog.
Scrum Master: Facilitador que asegura que el equipo sigue las prácticas y reglas de SCRUM. Elimina impedimentos y facilita eventos.
Equipo de Desarrollo: Profesionales multifuncionales responsables de entregar un incremento «Terminado» del producto al final de cada Sprint.

c) Artefactos de SCRUM

Product Backlog: Lista ordenada de todo lo que podría ser necesario en el producto. Es la única fuente de requisitos.
Sprint Backlog: Conjunto de elementos del Product Backlog seleccionados para el Sprint, más un plan para entregar el incremento de producto.
Incremento: Suma de todos los elementos del Product Backlog completados durante un Sprint y el valor de los incrementos de todos los Sprints anteriores.

d) Eventos de SCRUM

Sprint: Bloque de tiempo (time-box) de un mes o menos durante el cual se crea un incremento de producto «Terminado» utilizable y potencialmente desplegable.
Planificación del Sprint: Reunión para definir qué se entregará en el incremento resultante del próximo Sprint y cómo se conseguirá.
Scrum Diario: Evento de 15 minutos para que el equipo sincronice actividades y cree un plan para las próximas 24 horas.
Revisión del Sprint: Realizada al final del Sprint para inspeccionar el incremento y adaptar el Product Backlog si es necesario.
Retrospectiva del Sprint: Oportunidad para que el equipo se inspeccione a sí mismo y cree un plan de mejoras para el próximo Sprint.

e) Implementación en entornos sanitarios

En el contexto del SAS, SCRUM ha demostrado eficacia en proyectos como el desarrollo de módulos para la Historia Clínica Digital, donde:

Los Product Owners suelen ser profesionales sanitarios que conocen las necesidades clínicas
La entrega incremental permite validación continua por parte de los usuarios finales
Los Sprints cortos (2-3 semanas) facilitan la adaptación a cambios normativos
Las retrospectivas permiten mejorar continuamente la adaptación a entornos sanitarios altamente regulados

3.3.2. KANBAN

Kanban es un método visual para gestionar el trabajo a medida que avanza a través de un proceso, originado en el sistema de producción Toyota y adaptado al desarrollo de software por David J. Anderson.

a) Principios fundamentales

Visualizar el flujo de trabajo: Representación visual del trabajo y su proceso.
Limitar el trabajo en curso (WIP): Restricción de la cantidad de trabajo en progreso para evitar la sobrecarga.
Gestionar el flujo: Observación, medición y reporte del flujo para optimizarlo.
Hacer explícitas las políticas: Definir claramente las reglas y directrices del proceso.
Implementar ciclos de feedback: Colaboración y evolución experimental.
Mejorar colaborativamente: Uso de modelos y método científico para implementar mejoras.

b) Prácticas Kanban

Tablero Kanban: Herramienta visual que representa el flujo de trabajo con columnas para cada estado (Por hacer, En progreso, Terminado, etc.).
Tarjetas (Cards): Representación visual de los elementos de trabajo.
Límites de WIP: Restricciones numéricas sobre la cantidad de elementos en cada columna.
Carriles (Swimlanes): Categorización horizontal para diferentes tipos o clases de trabajo.
Métricas y análisis: Lead time, cycle time, throughput (rendimiento) y diagramas de flujo acumulativo.

c) Métricas Kanban

Lead Time: Tiempo total desde que se solicita una tarea hasta que se entrega.
Cycle Time: Tiempo que tarda una tarea desde que se comienza a trabajar en ella hasta que se completa.
Throughput: Número de elementos completados por unidad de tiempo.
Diagramas de Flujo Acumulativo (CFD): Representación gráfica del trabajo en sus diversos estados a lo largo del tiempo.

d) Diferencias con SCRUM

Aunque ambos son métodos ágiles, existen diferencias significativas:

Aspecto	SCRUM	KANBAN
Iteraciones	Timeboxed (Sprints)	Flujo continuo
Roles	Definidos (PO, SM, Equipo)	No prescribe roles específicos
Entregas	Al final de cada Sprint	Continua, según demanda
Cambios	No permitidos durante el Sprint	Pueden incorporarse en cualquier momento
Métricas	Velocidad	Lead/Cycle time, Throughput
WIP	Limitado por la capacidad del Sprint	Limitado explícitamente por estado

e) Aplicación en entornos sanitarios

En el contexto del SAS, Kanban ha sido efectivo en:

Gestión de incidencias y soporte de sistemas de información clínicos
Mantenimiento evolutivo de aplicaciones sanitarias
Gestión de peticiones de desarrollo menores
Procesos de validación y certificación de software médico

3.3.3. LEAN Software Development

Lean Software Development es una adaptación de los principios de Lean Manufacturing al desarrollo de software, formalizada por Mary y Tom Poppendieck en 2003.

a) Principios fundamentales

Eliminar desperdicios: Identificar y eliminar todo lo que no añade valor al cliente (código no utilizado, procesos innecesarios, características superfluas).
Amplificar el aprendizaje: Usar ciclos cortos de feedback e integrar el aprendizaje en el proceso.
Decidir lo más tarde posible: Mantener las opciones abiertas hasta tener información suficiente para tomar decisiones.
Entregar tan rápido como sea posible: Reducir el tiempo desde la concepción hasta la entrega.
Empoderar al equipo: Proporcionar autonomía y responsabilidad a quienes hacen el trabajo.
Construir integridad: Tanto integridad percibida (experiencia global desde la perspectiva del cliente) como integridad conceptual (coherencia del sistema).
Ver el conjunto: Optimizar el sistema completo, no partes aisladas.

b) Desperdicios (Muda) en el desarrollo software

Los siete desperdicios adaptados al contexto de desarrollo:

Trabajo parcialmente hecho: Código no integrado, no testeado, o no desplegado.
Procesos adicionales: Documentación excesiva, aprobaciones innecesarias.
Características extra: Funcionalidades no requeridas o no utilizadas.
Cambio de tareas: Multitarea ineficiente, interrupciones.
Esperas: Dependencias sin resolver, aprobaciones pendientes.
Movimiento: Búsqueda de información, comunicación ineficiente.
Defectos: Bugs, errores no detectados tempranamente.

c) Herramientas y técnicas Lean

Value Stream Mapping: Visualización del flujo de valor para identificar desperdicios.
A3 Problem Solving: Método estructurado para resolver problemas en una sola hoja A3.
5 Whys: Técnica de preguntas para identificar la causa raíz de un problema.
Kaizen: Mejora continua mediante pequeños cambios incrementales.
Poka-Yoke: Mecanismos a prueba de errores para prevenir defectos.
Andon: Sistemas de señalización para visualizar problemas y solicitar ayuda.

d) Métricas Lean

Lead Time: Tiempo total desde la solicitud hasta la entrega.
Cycle Time: Tiempo de procesamiento efectivo.
Takt Time: Ritmo al que se deben producir las entregas para satisfacer la demanda.
Porcentaje de Valor Añadido: Proporción de actividades que agregan valor respecto al total.
Eficiencia del Flujo: Relación entre el tiempo de valor añadido y el lead time total.

e) Aplicación en proyectos sanitarios

En el ámbito sanitario, Lean ha demostrado ser efectivo para:

Optimización de procesos de desarrollo de software para equipos médicos
Reducción de errores en sistemas críticos mediante la implementación de Poka-Yoke
Mejora continua en aplicaciones de gestión clínica
Eliminación de desperdicios en sistemas de información hospitalarios

3.4. DevOps y DevSecOps

3.4.1. DevOps: Integración de Desarrollo y Operaciones

DevOps es un conjunto de prácticas que combina el desarrollo de software (Dev) y las operaciones de TI (Ops) con el objetivo de acortar el ciclo de vida del desarrollo y proporcionar entrega continua de software de alta calidad.

a) Principios fundamentales

Cultura de colaboración: Eliminar silos entre equipos de desarrollo y operaciones.
Automatización: Minimizar el trabajo manual repetitivo y propenso a errores.
Medición: Recopilar y analizar datos para mejorar continuamente.
Compartir: Intercambiar conocimientos, herramientas y éxitos/fracasos.
Mejora continua: Iterar constantemente para optimizar procesos y herramientas.

b) El ciclo de vida DevOps

El ciclo de vida DevOps se representa frecuentemente como un «infinito» (símbolo ∞) que incluye:

Plan: Planificación del producto y gestión de tareas.
Code: Desarrollo, revisión de código y versión de control.
Build: Compilación e integración continua.
Test: Pruebas automatizadas (unitarias, integración, rendimiento, seguridad).
Release: Gestión de versiones y aprobaciones.
Deploy: Implementación en entornos de producción.
Operate: Operaciones de infraestructura y gestión de configuración.
Monitor: Monitorización de rendimiento y experiencia de usuario.

c) Prácticas y técnicas clave

Integración Continua (CI): Integración frecuente del código en un repositorio común, con verificaciones automatizadas.
Entrega Continua (CD): Automatización que permite que las compilaciones validadas estén listas para liberación.
Despliegue Continuo: Extensión de CD donde cada cambio que pasa las pruebas automatizadas se despliega automáticamente a producción.
Infraestructura como Código (IaC): Gestión de infraestructura mediante código y versiones.
Monitorización y Logging: Recopilación centralizada de datos para análisis y resolución de problemas.
Microservicios: Arquitectura que descompone aplicaciones en servicios independientes y desplegables.
Gestión de la Configuración: Control automático de configuraciones de sistemas y aplicaciones.

d) Herramientas DevOps

El ecosistema DevOps incluye numerosas herramientas, agrupadas por categorías:

Control de versiones: Git, GitLab, GitHub, Bitbucket
CI/CD: Jenkins, GitLab CI, GitHub Actions, CircleCI, Azure DevOps
Configuración e IaC: Ansible, Puppet, Chef, Terraform
Contenedores y orquestación: Docker, Kubernetes, OpenShift
Monitorización: Prometheus, Grafana, ELK Stack, Datadog
Gestión de artefactos: Nexus, Artifactory, Docker Registry
Colaboración: Jira, Confluence, Slack, Teams

e) Implementación en entornos sanitarios

En el contexto del SAS, DevOps presenta desafíos específicos:

Estrictos requisitos de validación regulatoria para cambios en producción
Necesidad de alta disponibilidad para sistemas críticos (24/7)
Gestión de datos sensibles y cumplimiento normativo (GDPR, LOPD-GDD)
Entornos heterogéneos con sistemas legados

Ejemplos de implementación en el SAS incluyen:

Pipelines de CI/CD para aplicaciones móviles de seguimiento de pacientes
Automatización de pruebas para sistemas de prescripción electrónica
IaC para despliegue consistente de entornos de Historia Clínica Digital
Monitorización avanzada de sistemas de citas y gestión hospitalaria

3.4.2. DevSecOps: Integración de la Seguridad

DevSecOps extiende el concepto DevOps incorporando la seguridad como un componente esencial desde el inicio del ciclo de desarrollo («shift-left security»).

a) Fundamentos y principios

Seguridad desde el diseño: Incorporar la seguridad desde las fases iniciales del desarrollo.
Automatización de seguridad: Integrar pruebas de seguridad automatizadas en pipelines CI/CD.
Responsabilidad compartida: La seguridad es responsabilidad de todos, no solo del equipo de seguridad.
Mejora continua: Aprendizaje constante y adaptación a nuevas amenazas.
Transparencia: Visibilidad de los riesgos de seguridad para todo el equipo.

b) Prácticas clave

SAST (Static Application Security Testing): Análisis estático del código para identificar vulnerabilidades.
DAST (Dynamic Application Security Testing): Pruebas dinámicas para encontrar vulnerabilidades en aplicaciones en ejecución.
IAST (Interactive Application Security Testing): Combinación de técnicas estáticas y dinámicas durante la ejecución de pruebas.
SCA (Software Composition Analysis): Análisis de dependencias para identificar componentes vulnerables.
Gestión de secretos: Protección de credenciales, claves API y otros secretos.
Hardening de contenedores: Fortalecimiento de seguridad en imágenes y despliegues de contenedores.
Políticas como código: Definición y aplicación automatizada de políticas de seguridad.

c) El ciclo de vida DevSecOps

DevSecOps integra la seguridad en cada fase del ciclo DevOps:

Plan: Modelado de amenazas, requisitos de seguridad.
Code: Análisis estático, revisiones de seguridad por pares.
Build: Análisis de composición de software, escaneo de vulnerabilidades.
Test: Pruebas de penetración automatizadas, análisis dinámico.
Release: Validación de conformidad, firmas digitales.
Deploy: Configuraciones seguras, escaneo de imágenes de contenedores.
Operate: Gestión de actualizaciones de seguridad, configuración segura.
Monitor: Detección de intrusiones, análisis de comportamiento.

d) Herramientas DevSecOps

SAST: SonarQube, Checkmarx, Fortify, Veracode
DAST: OWASP ZAP, Burp Suite, Acunetix
SCA: Snyk, Black Duck, OWASP Dependency-Check
Gestión de secretos: HashiCorp Vault, AWS Secrets Manager, Azure Key Vault
Seguridad en contenedores: Clair, Trivy, Anchore
Cumplimiento y políticas: Open Policy Agent, Chef InSpec, Compliance as Code

e) Implementación en el ámbito sanitario

En entornos sanitarios como el SAS, DevSecOps es crítico debido a:

Normativa específica (Esquema Nacional de Seguridad, LOPD-GDD, GDPR)
Alta sensibilidad de datos clínicos y personales
Necesidad de mantener la disponibilidad de sistemas críticos
Crecientes amenazas de ciberseguridad contra el sector sanitario

Ejemplos de implementación en el SAS:

Análisis automatizado de código en aplicaciones de gestión de pacientes
Pruebas de penetración continuas en portales de pacientes
Validación de cumplimiento normativo como parte del pipeline
Gestión segura de secretos para APIs de interoperabilidad sanitaria
Monitorización de seguridad en tiempo real para detección de amenazas

4. 🏁 CONCLUSIONES

El desarrollo ágil de software representa un cambio paradigmático en la forma de conceptualizar, diseñar, implementar y mantener aplicaciones informáticas. A través de los principios y valores establecidos en el Manifiesto Ágil, y mediante la implementación de marcos de trabajo como SCRUM, KANBAN y LEAN, las organizaciones sanitarias pueden responder con mayor agilidad y eficacia a las crecientes demandas tecnológicas del sector.

La evolución desde metodologías puramente ágiles hacia enfoques DevOps y DevSecOps refleja la necesidad de integrar de manera holística los aspectos operativos y de seguridad en el ciclo de vida del desarrollo. Esta integración resulta particularmente relevante en el contexto sanitario, donde la disponibilidad continua de los sistemas y la protección de datos sensibles son imperativos ineludibles.

Los desafíos actuales del sector sanitario público, caracterizados por la transformación digital acelerada, la interoperabilidad y la personalización de la atención, requieren de profesionales capaces de implementar estos marcos de trabajo adaptándolos a las particularidades regulatorias y operativas del ámbito sanitario. El Técnico de Función Administrativa especializado en Informática debe dominar estos conceptos para liderar eficazmente la modernización tecnológica de organizaciones como el Servicio Andaluz de Salud.

La aplicación exitosa de estas metodologías no depende únicamente del conocimiento técnico, sino también de la capacidad para fomentar un cambio cultural que promueva la colaboración entre equipos, la transparencia en los procesos y la aceptación del cambio como constante. El futuro del desarrollo de software en el sector sanitario estará marcado por la continua evolución de estas metodologías, integrando nuevas tendencias como la inteligencia artificial, el aprendizaje automático y la computación en la nube.

5. 💼 CASOS PRÁCTICOS

Caso 1: Implementación de SCRUM en el desarrollo de un módulo de telemedicina

El SAS decidió desarrollar un nuevo módulo de telemedicina para su Historia Clínica Digital para facilitar consultas remotas durante la pandemia COVID-19. Se implementó SCRUM con las siguientes características:

Equipo: 7 desarrolladores, 1 Scrum Master, 1 Product Owner (médico especialista)
Duración de Sprints: 2 semanas
Product Backlog: 78 historias de usuario priorizadas
Velocidad media: 25 puntos de historia por sprint

Desafíos encontrados:

Requisitos cambiantes debido a la evolución normativa sobre telemedicina
Integración con sistemas legados de videoconferencia
Estrictos requisitos de seguridad y privacidad

Resultados de la aplicación de SCRUM:

Entregar una primera versión funcional en 8 semanas
Adaptar rápidamente el producto a cambios normativos
Incorporar feedback de profesionales sanitarios en cada sprint
Gestionar eficazmente los requisitos técnicos de seguridad

Caso 2: Implementación de DevSecOps en el sistema de prescripción electrónica

El sistema de prescripción electrónica del SAS requería una modernización que permitiera actualizaciones más frecuentes manteniendo los altos estándares de seguridad requeridos. Se implementó DevSecOps con los siguientes elementos:

Pipeline CI/CD: Integración de Jenkins con SonarQube y OWASP ZAP
Infraestructura como Código: Terraform para la definición de entornos
Contenedores: Dockerización de componentes con escaneo automático de vulnerabilidades
Automatización de pruebas: Pruebas unitarias, integración, rendimiento y seguridad

Resultados obtenidos:

Reducción del tiempo de despliegue de 2 semanas a 3 días
Detección temprana de vulnerabilidades de seguridad (shift-left)
Mejora en la trazabilidad de cambios y cumplimiento normativo
Mayor estabilidad del sistema en producción

6. ❓ CUESTIONARIO DE PREGUNTAS

Pregunta 1 (Actualizada 2025)

¿Cuál de los siguientes NO es uno de los valores fundamentales expresados en el Manifiesto Ágil?

A) Individuos e interacciones sobre procesos y herramientas

B) Software funcionando sobre documentación exhaustiva

C) Planificación detallada sobre respuesta al cambio

D) Colaboración con el cliente sobre negociación contractual

✅ Respuesta correcta: C

📌 Explicación:

La opción C invierte uno de los valores del Manifiesto Ágil, que en realidad establece «Respuesta ante el cambio sobre seguir un plan»
Las opciones A, B y D son valores expresados literalmente en el Manifiesto Ágil

📌 Referencia: Manifiesto Ágil (2001)

Pregunta 2 (Actualizada 2025)

En el contexto de Kanban, ¿qué significa el término «WIP»?

A) Work Integration Process

B) Work In Progress

C) Workflow Improvement Protocol

D) Weekly Iteration Planning

✅ Respuesta correcta: B

📌 Explicación:

WIP significa «Work In Progress» (Trabajo En Progreso), que representa las tareas que están siendo realizadas actualmente
Limitar el WIP es uno de los principios fundamentales de Kanban para evitar la sobrecarga y mejorar el flujo
Las demás opciones son términos inventados que no corresponden a conceptos de Kanban

📌 Referencia: Anderson, D. J. (2010). Kanban: Successful Evolutionary Change for Your Technology Business

Pregunta 3 (Actualizada 2025)

¿Cuál de los siguientes NO es un evento oficial en el marco de trabajo SCRUM?

A) Sprint Planning

B) Daily Standup

C) Sprint Retrospective

D) Weekly Status Report

✅ Respuesta correcta: D

📌 Explicación:

El «Weekly Status Report» (Informe Semanal de Estado) no es un evento oficial de SCRUM
Los eventos oficiales de SCRUM son: Sprint Planning, Daily Scrum (o Daily Standup), Sprint Review y Sprint Retrospective
SCRUM no contempla informes de estado periódicos como parte de su marco, ya que la transparencia se logra a través de los otros eventos y artefactos

📌 Referencia: Schwaber, K. & Sutherland, J. (2020). The Scrum Guide

Pregunta 4 (Actualizada 2025)

En DevSecOps, ¿qué significa el concepto «shift-left» aplicado a la seguridad?

A) Mover la responsabilidad de seguridad al equipo de operaciones

B) Incorporar la seguridad desde las primeras fases del ciclo de desarrollo

C) Desplazar los controles de seguridad a servidores ubicados geográficamente a la izquierda

D) Reducir la prioridad de los requisitos de seguridad en el backlog

✅ Respuesta correcta: B

📌 Explicación:

«Shift-left» se refiere a mover actividades que tradicionalmente se realizaban tarde en el ciclo de desarrollo (a la «derecha» en la representación temporal) hacia etapas más tempranas (a la «izquierda»)
En seguridad, implica incorporar pruebas y controles de seguridad desde las fases iniciales del desarrollo, en lugar de aplicarlas solo antes del despliegue
Este enfoque permite detectar y solucionar problemas de seguridad cuando son más económicos de resolver

📌 Referencia: NIST Special Publication 800-160 Vol. 1, Systems Security Engineering

Pregunta 5 (Actualizada 2025)

¿Cuál de los siguientes es un tipo de «desperdicio» (muda) según la metodología Lean Software Development?

A) Rotación de personal

B) Características extra

C) Comunicación cara a cara

D) Feedback del cliente

✅ Respuesta correcta: B

📌 Explicación:

«Características extra» (funcionalidades no requeridas por el cliente) es uno de los siete desperdicios identificados en Lean Software Development
Corresponde al desperdicio de «sobreproducción» en la manufactura Lean tradicional
Implementar características que no aportan valor al cliente consume recursos sin generar retorno
Las otras opciones no son consideradas desperdicios en Lean: la rotación de personal es un factor organizacional, mientras que la comunicación cara a cara y el feedback del cliente son prácticas valiosas

📌 Referencia: Poppendieck, M. & Poppendieck, T. (2003). Lean Software Development: An Agile Toolkit

Pregunta 6 (Actualizada 2025)

¿Qué característica define mejor el concepto de «iteración» en el desarrollo ágil?

A) Un conjunto de requisitos que deben ser implementados en secuencia

B) Un período de tiempo fijo donde se desarrolla un incremento de producto potencialmente entregable

C) Una reunión donde el equipo planifica todas las tareas del proyecto

D) Una técnica para documentar los requisitos del usuario

✅ Respuesta correcta: B

📌 Explicación:

Una iteración es un período de tiempo fijo (timeboxed) durante el cual el equipo trabaja para desarrollar un incremento de funcionalidad
Al final de cada iteración, el resultado debe ser potencialmente entregable, aunque no necesariamente completo
Las iteraciones permiten obtener feedback temprano y frecuente sobre el producto
En Scrum, las iteraciones se denominan Sprints

📌 Referencia: Rubin, K. (2022). Essential Scrum: A Practical Guide to the Most Popular Agile Process

Pregunta 7 (Actualizada 2025)

En el contexto de SCRUM, ¿cuál es la responsabilidad principal del Product Owner?

A) Gestionar el trabajo diario del equipo de desarrollo

B) Maximizar el valor del producto y gestionar el Product Backlog

C) Eliminar impedimentos y facilitar los eventos de Scrum

D) Asegurar que el proceso de desarrollo siga las mejores prácticas técnicas

✅ Respuesta correcta: B

📌 Explicación:

El Product Owner es responsable de maximizar el valor del producto resultante del trabajo del equipo
Para ello, gestiona el Product Backlog, definiendo, ordenando y priorizando los elementos
También es responsable de asegurar que el Product Backlog sea transparente, visible y entendible por todos
Las otras responsabilidades mencionadas corresponden al Scrum Master (C) o al equipo de desarrollo (A, D)

📌 Referencia: Schwaber, K. & Sutherland, J. (2020). The Scrum Guide

Pregunta 8 (Actualizada 2025)

¿Qué técnica se utiliza en DevOps para garantizar que los entornos de desarrollo, prueba y producción sean consistentes?

A) Deployment Pipeline

B) Infrastructure as Code (IaC)

C) Blue-Green Deployment

D) Canary Release

✅ Respuesta correcta: B

📌 Explicación:

Infrastructure as Code (IaC) permite definir la infraestructura mediante archivos de configuración versionables
Esto garantiza que los entornos sean consistentes y reproducibles, ya que se crean a partir del mismo código
Reduce errores humanos en la configuración manual de servidores
Las otras opciones son técnicas de DevOps pero no se centran específicamente en la consistencia de entornos:
- Deployment Pipeline es el proceso automatizado de entrega de software
- Blue-Green Deployment es una técnica para reducir el tiempo de inactividad durante despliegues
- Canary Release es una técnica para reducir el riesgo al liberar nuevas versiones gradualmente

📌 Referencia: Morris, K. (2021). Infrastructure as Code: Managing Servers in the Cloud (2nd ed.). O’Reilly Media

Pregunta 9 (Actualizada 2025)

En relación a las Historias de Usuario en metodologías ágiles, ¿qué significa el acrónimo INVEST?

A) Integrated, Natural, Valued, Easy, Simple, Testable

B) Independent, Negotiable, Valuable, Estimable, Small, Testable

C) Incremental, New, Verified, Established, Secure, Traceable

D) Informative, Notable, Verifiable, Explicit, Strategic, Timely

✅ Respuesta correcta: B

📌 Explicación:

INVEST es un acrónimo que describe las características que debe tener una buena historia de usuario:
Independent: La historia debe poder implementarse de forma independiente de otras historias
Negotiable: Los detalles deben ser negociables, no un contrato rígido
Valuable: Debe proporcionar valor al cliente o usuario
Estimable: El equipo debe poder estimar el esfuerzo necesario para implementarla
Small: Debe ser lo suficientemente pequeña para planificarla y desarrollarla con precisión
Testable: Debe incluir criterios de aceptación que permitan verificar su correcta implementación

📌 Referencia: Wake, B. (2003). INVEST in Good Stories, and SMART Tasks. XP123

Pregunta 10 (Actualizada 2025)

En Kanban, ¿qué métrica indica el tiempo que tarda un elemento desde que se comienza a trabajar en él hasta que se completa?

A) Lead Time

B) Cycle Time

C) Throughput

D) Takt Time

✅ Respuesta correcta: B

📌 Explicación:

Cycle Time mide específicamente el tiempo desde que se comienza a trabajar en un elemento hasta que se completa
Lead Time es una métrica diferente que mide el tiempo desde que se solicita un elemento hasta que se entrega (incluye el tiempo de espera)
Throughput mide la cantidad de elementos completados por unidad de tiempo
Takt Time es un concepto de Lean que indica el ritmo al que se deben producir las entregas para satisfacer la demanda

📌 Referencia: Anderson, D. J. & Carmichael, A. (2021). Essential Kanban Condensed. Lean Kanban University Press

Pregunta 11 (Actualizada 2025)

¿Qué práctica de Extreme Programming (XP) se refiere a escribir primero las pruebas y luego el código que las satisface?

A) Pair Programming

B) Continuous Integration

C) Test-Driven Development (TDD)

D) Refactoring

✅ Respuesta correcta: C

📌 Explicación:

Test-Driven Development (TDD) es una práctica de XP donde se escribe una prueba que falla antes de escribir el código mínimo necesario para pasarla
El ciclo de TDD consta de tres pasos: Rojo (escribir una prueba que falla), Verde (escribir código que pasa la prueba) y Refactor (mejorar el código manteniendo las pruebas en verde)
Pair Programming se refiere a dos programadores trabajando juntos en el mismo ordenador
Continuous Integration implica integrar el código frecuentemente en un repositorio compartido
Refactoring consiste en mejorar el diseño del código sin cambiar su comportamiento

📌 Referencia: Beck, K. (2002). Test-Driven Development: By Example. Addison-Wesley

Pregunta 12 (Actualizada 2025)

¿Cuál es la principal diferencia entre Entrega Continua (Continuous Delivery) y Despliegue Continuo (Continuous Deployment) en DevOps?

A) La Entrega Continua implica integración automática, mientras que el Despliegue Continuo no

B) La Entrega Continua asegura que el código está listo para producción pero requiere aprobación manual para el despliegue, mientras que el Despliegue Continuo automatiza todo el proceso hasta producción

C) La Entrega Continua se aplica solo a entornos de desarrollo, mientras que el Despliegue Continuo incluye entornos de prueba

D) La Entrega Continua es una práctica de DevOps, mientras que el Despliegue Continuo es una práctica de DevSecOps

✅ Respuesta correcta: B

📌 Explicación:

En Entrega Continua (Continuous Delivery), el software está siempre listo para producción, pero se requiere una decisión humana para el despliegue final
En Despliegue Continuo (Continuous Deployment), cada cambio que pasa todas las pruebas automatizadas se despliega automáticamente en producción sin intervención humana
Ambas prácticas comparten la automatización de pruebas e integración, pero difieren en la automatización del paso final a producción
El Despliegue Continuo es una extensión de la Entrega Continua que elimina la aprobación manual

📌 Referencia: Humble, J. & Farley, D. (2010). Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation. Addison-Wesley

Pregunta 13 (Actualizada 2025)

Según la Guía SCRUM 2020, ¿cuántos roles formales existen en SCRUM?

A) Dos (Scrum Master y Product Owner)

B) Tres (Scrum Master, Product Owner y Development Team)

C) Tres (Scrum Master, Product Owner y Developers)

D) Cuatro (Scrum Master, Product Owner, QA Lead y Developers)

✅ Respuesta correcta: C

📌 Explicación:

La Guía Scrum 2020 establece tres roles formales, denominados como «accountabilities» (responsabilidades):
1. Scrum Master: Responsable de la eficacia del equipo y la implementación de Scrum
2. Product Owner: Responsable de maximizar el valor del producto
3. Developers: Responsables de crear cualquier aspecto de un Incremento usable
Es importante destacar que el término «Development Team» fue reemplazado por «Developers» en la actualización de 2020, enfatizando que es un único equipo con diversas habilidades

📌 Referencia: Schwaber, K. & Sutherland, J. (2020). The Scrum Guide

Pregunta 14 (Actualizada 2025)

¿Qué práctica de seguridad en DevSecOps analiza los componentes de terceros utilizados en una aplicación para identificar vulnerabilidades conocidas?

A) DAST (Dynamic Application Security Testing)

B) SAST (Static Application Security Testing)

C) SCA (Software Composition Analysis)

D) RASP (Runtime Application Self-Protection)

✅ Respuesta correcta: C

📌 Explicación:

Software Composition Analysis (SCA) escanea específicamente las dependencias y componentes de terceros (librerías, frameworks, etc.) en busca de vulnerabilidades conocidas
SCA utiliza bases de datos de vulnerabilidades como la National Vulnerability Database (NVD) para identificar componentes con riesgos de seguridad
SAST analiza el código fuente estáticamente sin ejecutarlo para encontrar vulnerabilidades en el código propio
DAST prueba la aplicación en ejecución para encontrar vulnerabilidades desde la perspectiva de un atacante
RASP protege la aplicación mientras se ejecuta, detectando y bloqueando ataques en tiempo real

📌 Referencia: Sonatype (2023). State of the Software Supply Chain Report

Pregunta 15 (Actualizada 2025)

En metodologías ágiles, ¿qué diagrama se utiliza para visualizar y analizar si el trabajo está progresando según lo planeado, mostrando la relación entre trabajo pendiente y tiempo?

A) Diagrama de Gantt

B) Diagrama de Ishikawa

C) Diagrama Burndown

D) Diagrama PERT

✅ Respuesta correcta: C

📌 Explicación:

El Diagrama Burndown muestra la relación entre el trabajo pendiente (eje Y) y el tiempo (eje X), permitiendo visualizar el progreso real vs. el ideal
Es una herramienta fundamental en Scrum para monitorizar el avance durante un Sprint
Permite identificar rápidamente si el equipo está adelantado, a tiempo o retrasado respecto al plan
Los otros diagramas mencionados son herramientas de gestión de proyectos pero no son específicos de metodologías ágiles:
- Diagrama de Gantt: Herramienta de planificación secuencial tradicional
- Diagrama de Ishikawa: También conocido como diagrama de espina de pescado, para análisis de causa-raíz
- Diagrama PERT: Técnica de evaluación y revisión de programas para análisis de tareas

📌 Referencia: Rubin, K. (2022). Essential Scrum: A Practical Guide to the Most Popular Agile Process

Pregunta 16 (Actualizada 2025)

¿Cuál de las siguientes prácticas NO es un principio de la filosofía Lean aplicada al desarrollo de software?

A) Eliminar desperdicios

B) Amplificar el aprendizaje

C) Documentación exhaustiva de requisitos

D) Decidir lo más tarde posible

✅ Respuesta correcta: C

📌 Explicación:

La «documentación exhaustiva de requisitos» contradice directamente los principios Lean, que buscan minimizar el trabajo innecesario
Lean considera la documentación excesiva como un tipo de desperdicio cuando no aporta valor directo al cliente
Los principios de Lean Software Development son:
- Eliminar desperdicios
- Amplificar el aprendizaje
- Decidir lo más tarde posible
- Entregar tan rápido como sea posible
- Empoderar al equipo
- Construir integridad
- Ver el conjunto

📌 Referencia: Poppendieck, M. & Poppendieck, T. (2003). Lean Software Development: An Agile Toolkit

Pregunta 17 (Actualizada 2025)

En el contexto de DevOps, ¿qué tipo de pruebas verifican que los componentes individuales de una aplicación funcionan correctamente de forma aislada?

A) Pruebas de integración

B) Pruebas unitarias

C) Pruebas de aceptación

D) Pruebas de sistema

✅ Respuesta correcta: B

📌 Explicación:

Las pruebas unitarias verifican el funcionamiento correcto de componentes individuales de código de forma aislada
Son la base de la pirámide de pruebas en DevOps, generalmente automatizadas y rápidas de ejecutar
Las otras opciones corresponden a diferentes niveles de prueba:
- Pruebas de integración: Verifican la interacción correcta entre componentes
- Pruebas de aceptación: Validan que el sistema cumple con los requisitos del usuario
- Pruebas de sistema: Evalúan el sistema completo en un entorno que simula producción

📌 Referencia: Humble, J. & Farley, D. (2010). Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation

Pregunta 18 (Actualizada 2025)

¿Qué característica diferencia fundamentalmente a KANBAN de SCRUM?

A) KANBAN se basa en iteraciones fijas, mientras que SCRUM utiliza flujo continuo

B) KANBAN requiere roles específicos, mientras que SCRUM no prescribe roles

C) KANBAN utiliza flujo continuo, mientras que SCRUM se basa en iteraciones fijas (Sprints)

D) KANBAN no permite cambios durante el proceso, mientras que SCRUM es más flexible

✅ Respuesta correcta: C

📌 Explicación:

KANBAN se basa en un flujo de trabajo continuo, sin iteraciones timeboxed, donde los elementos avanzan a través del tablero a su propio ritmo
SCRUM estructura el trabajo en Sprints, que son iteraciones de tiempo fijo (generalmente de 1 a 4 semanas)
Esta diferencia fundamental afecta cómo se planifica, se entregan y se introducen cambios en ambos métodos:
- En KANBAN, los elementos pueden ser priorizados y cambiados en cualquier momento
- En SCRUM, una vez que comienza un Sprint, el alcance está fijado y no debe cambiarse

📌 Referencia: Anderson, D. J. (2010). Kanban: Successful Evolutionary Change for Your Technology Business

Pregunta 19 (Actualizada 2025)

En DevSecOps, ¿qué tipo de herramienta se utiliza para gestionar y proteger secretos como contraseñas, claves API y certificados durante el ciclo de vida del desarrollo?

A) Container Registry

B) Configuration Management Database (CMDB)

C) Secrets Management

D) Identity and Access Management (IAM)

✅ Respuesta correcta: C

📌 Explicación:

Secrets Management es el tipo de herramienta diseñada específicamente para el almacenamiento seguro, distribución y rotación de secretos como contraseñas, tokens, claves API y certificados
Ejemplos de estas herramientas incluyen HashiCorp Vault, AWS Secrets Manager y Azure Key Vault
Estas soluciones evitan prácticas inseguras como hardcodear credenciales en el código fuente o en archivos de configuración
Las otras opciones tienen propósitos diferentes:
- Container Registry: Almacena y gestiona imágenes de contenedores
- CMDB: Almacena información sobre los componentes de infraestructura y sus relaciones
- IAM: Gestiona identidades y permisos de acceso a recursos

📌 Referencia: NIST (2023). Security and Privacy Controls for Information Systems and Organizations, SP 800-53 Rev. 5

Pregunta 20 (Actualizada 2025)

¿Cuál es la principal ventaja de utilizar microservicios en arquitecturas DevOps?

A) Simplificación del despliegue al tener una única aplicación monolítica

B) Menor complejidad en la comunicación entre componentes

C) Facilidad para escalar, desplegar y mantener componentes de forma independiente

D) Reducción de la necesidad de herramientas de automatización

✅ Respuesta correcta: C

📌 Explicación:

La principal ventaja de los microservicios es la capacidad de escalar, desplegar y mantener componentes de forma independiente, sin afectar al resto del sistema
Esto permite:
- Ciclos de desarrollo y entrega más rápidos para características específicas
- Escalado selectivo de servicios según la demanda
- Mayor resiliencia, ya que el fallo de un servicio no necesariamente afecta a todo el sistema
- Equipos autónomos trabajando en diferentes servicios con tecnologías potencialmente diferentes
Las otras opciones son incorrectas:
- Los microservicios son más complejos de desplegar que las aplicaciones monolíticas
- La comunicación entre servicios añade complejidad
- Los microservicios aumentan (no reducen) la necesidad de automatización

📌 Referencia: Newman, S. (2021). Building Microservices (2nd ed.). O’Reilly Media

Pregunta 21 (Actualizada 2025)

¿Qué significa el acrónimo «DoD» en el contexto de SCRUM?

A) Department of Development

B) Definition of Done

C) Duration of Development

D) Deployment on Demand

✅ Respuesta correcta: B

📌 Explicación:

DoD significa «Definition of Done» (Definición de Terminado) en SCRUM
Es un acuerdo formal entre el equipo sobre los criterios que debe cumplir un incremento para considerarse completado
Funciona como una lista de verificación que asegura la calidad y completitud del trabajo
Puede incluir criterios como:
- Pruebas unitarias y de integración completadas
- Código revisado por pares
- Documentación actualizada
- Criterios de aceptación satisfechos
- Aprobación por parte del Product Owner

📌 Referencia: Schwaber, K. & Sutherland, J. (2020). The Scrum Guide

Pregunta 22 (Actualizada 2025)

En el contexto de Lean Software Development, ¿qué significa el principio «Decidir lo más tarde posible»?

A) Posponer todas las decisiones hasta el final del proyecto

B) Evitar la toma de decisiones para reducir la responsabilidad del equipo

C) Mantener las opciones abiertas y tomar decisiones basadas en hechos cuando se tenga más información

D) Delegar todas las decisiones técnicas al cliente

✅ Respuesta correcta: C

📌 Explicación:

El principio «Decidir lo más tarde posible» se refiere a mantener las opciones abiertas y tomar decisiones cuando se tenga más información relevante disponible
No significa procrastinar o evitar decisiones, sino tomarlas en el momento óptimo
Permite responder mejor a cambios e incertidumbres del proyecto
Es similar al concepto de «last responsible moment» (último momento responsable), que implica:
- Identificar decisiones irreversibles
- Retrasar estas decisiones hasta el último momento responsable
- Mientras tanto, explorar alternativas y recopilar información

📌 Referencia: Poppendieck, M. & Poppendieck, T. (2003). Lean Software Development: An Agile Toolkit

Pregunta 23 (Actualizada 2025)

¿Qué técnica de estimación ágil utiliza secuencias de Fibonacci (1, 2, 3, 5, 8, 13, …) para asignar tamaños relativos a las tareas?

A) Planning Poker

B) T-Shirt Sizing

C) Dot Voting

D) Bucket System

✅ Respuesta correcta: A

📌 Explicación:

Planning Poker es una técnica de estimación consensuada donde cada miembro del equipo selecciona una carta con un valor de la secuencia de Fibonacci para estimar una historia de usuario
La secuencia de Fibonacci se utiliza porque refleja la incertidumbre creciente a medida que aumenta el tamaño de las tareas
El proceso incluye:
- Discusión inicial de la historia de usuario
- Selección simultánea de cartas por parte de todos los miembros del equipo
- Discusión de las diferencias significativas en las estimaciones
- Re-estimación hasta alcanzar consenso
Las otras técnicas mencionadas utilizan diferentes escalas:
- T-Shirt Sizing: Utiliza tallas de camiseta (XS, S, M, L, XL)
- Dot Voting: Sistema de votación visual con puntos adhesivos
- Bucket System: Agrupación de historias en «cubos» de tamaño similar

📌 Referencia: Cohn, M. (2019). Agile Estimating and Planning. Pearson Education

Pregunta 24 (Actualizada 2025)

En DevOps, ¿qué tipo de pruebas automatizadas verifican que los cambios en el código no han introducido nuevos errores en funcionalidades previamente operativas?

A) Pruebas A/B

B) Pruebas de regresión

C) Pruebas de carga

D) Pruebas exploratorias

✅ Respuesta correcta: B

📌 Explicación:

Las pruebas de regresión verifican específicamente que los cambios nuevos no han afectado negativamente a funcionalidades existentes que previamente funcionaban correctamente
Son fundamentales en pipelines de CI/CD para garantizar que el desarrollo iterativo no degrada la calidad del sistema
Generalmente consisten en un conjunto de pruebas automatizadas que se ejecutan después de cada cambio significativo
Las otras opciones son diferentes tipos de pruebas:
- Pruebas A/B: Comparan dos versiones diferentes para determinar cuál funciona mejor (usadas en optimización)
- Pruebas de carga: Verifican el rendimiento del sistema bajo diferentes niveles de uso
- Pruebas exploratorias: Pruebas manuales no guionizadas para encontrar errores que las pruebas automatizadas podrían no detectar

📌 Referencia: Forsgren, N., Humble, J., & Kim, G. (2018). Accelerate: The Science of Lean Software and DevOps

Pregunta 25 (Actualizada 2025)

¿Qué herramienta o mecanismo se utiliza en SCRUM para hacer visible y transparente el progreso diario del equipo?

A) Sprint Retrospective

B) Daily Scrum

C) Sprint Review

D) Burndown Chart

✅ Respuesta correcta: B

📌 Explicación:

El Daily Scrum (o Daily Standup) es una reunión diaria de 15 minutos donde cada miembro del equipo comparte:
- Qué hizo ayer para contribuir al objetivo del Sprint
- Qué hará hoy
- Si tiene algún impedimento
Esta reunión sincroniza las actividades del equipo y crea un plan para las próximas 24 horas
Aunque el Burndown Chart también muestra progreso, no es un evento de sincronización diaria
Los otros eventos tienen diferentes propósitos:
- Sprint Retrospective: Identificar mejoras en el proceso (al final del Sprint)
- Sprint Review: Inspección del incremento y adaptación del Product Backlog (al final del Sprint)

📌 Referencia: Schwaber, K. & Sutherland, J. (2020). The Scrum Guide

7. 🗺️ MAPA CONCEPTUAL

🚨 DESARROLLO ÁGIL DE SOFTWARE 🚨

📜 FILOSOFÍA Y PRINCIPIOS ÁGILES

🔴 Fundamentos filosóficos
- Empirismo
- Adaptabilidad
- Valor incremental
- Mejora continua
- Colaboración
🔴 12 Principios fundamentales
- Satisfacción del cliente
- Aceptación del cambio
- Entrega frecuente
- Colaboración
- Motivación y confianza
- Comunicación cara a cara
- Software funcionando como medida
- Desarrollo sostenible
- Excelencia técnica
- Simplicidad
- Autoorganización
- Autorreflexión

📝 MANIFIESTO ÁGIL (2001)

🔴 Valores fundamentales
- Individuos e interacciones > procesos y herramientas
- Software funcionando > documentación exhaustiva
- Colaboración con cliente > negociación contractual
- Respuesta al cambio > seguir un plan
🔴 Evolución e impacto
- Adopción en múltiples sectores
- Integración con otras disciplinas
- Adaptación a contextos regulados

🛠️ MÉTODOS ÁGILES

🔴 SCRUM
- Roles (PO, SM, Dev Team)
- Eventos (Sprint, Daily, Review, Retrospective)
- Artefactos (Product/Sprint Backlog, Incremento)
🔴 KANBAN
- Visualizar el flujo
- Limitar WIP
- Métricas (Lead/Cycle Time, Throughput)
🔴 LEAN
- 7 Principios
- 7 Desperdicios (Muda)
- Técnicas (Value Stream Mapping, Kaizen)

🔄 EVOLUCIÓN

🔴 DevOps
- Ciclo de vida (Plan, Code, Build, Test, Release, Deploy, Operate, Monitor)
- CI/CD (Integración y Entrega Continua)
- Infraestructura como Código
🔴 DevSecOps
- «Shift-left security»
- Pruebas de seguridad (SAST, DAST, SCA)
- Seguridad como responsabilidad compartida

8. 📚 REFERENCIAS NORMATIVAS Y BIBLIOGRÁFICAS

Normativa

Real Decreto 4/2010, de 8 de enero, por el que se regula el Esquema Nacional de Interoperabilidad en el ámbito de la Administración Electrónica.
Ley Orgánica 3/2018, de 5 de diciembre, de Protección de Datos Personales y garantía de los derechos digitales.
Real Decreto 311/2022, de 3 de mayo, por el que se regula el Esquema Nacional de Seguridad.
Reglamento (UE) 2016/679 (GDPR), relativo a la protección de las personas físicas en lo que respecta al tratamiento de datos personales.
Estrategia de Transformación Digital del Sistema Nacional de Salud (actualización 2023).

Bibliografía

Beck, K., Beedle, M., Bennekum, A., et al. (2001). Manifiesto por el Desarrollo Ágil de Software. Agile Alliance.
Schwaber, K., & Sutherland, J. (2020). The Scrum Guide: The Definitive Guide to Scrum. Scrum.org.
Anderson, D. J. (2010). Kanban: Successful Evolutionary Change for Your Technology Business. Blue Hole Press.
Poppendieck, M., & Poppendieck, T. (2003). Lean Software Development: An Agile Toolkit. Addison-Wesley Professional.
Kim, G., Debois, P., Willis, J., & Humble, J. (2021). The DevOps Handbook: How to Create World-Class Agility, Reliability, & Security in Technology Organizations (2nd ed.). IT Revolution Press.
Forsgren, N., Humble, J., & Kim, G. (2018). Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations. IT Revolution Press.
OWASP Foundation. (2023). OWASP DevSecOps Maturity Model. OWASP.org.
Leffingwell, D. (2018). SAFe 5.0 Distilled: Achieving Business Agility with the Scaled Agile Framework. Addison-Wesley Professional.
Humble, J., & Farley, D. (2010). Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation. Addison-Wesley Professional.
Davis, J., & Daniels, K. (2016). Effective DevOps: Building a Culture of Collaboration, Affinity, and Tooling at Scale. O’Reilly Media.