TEI – Tema 15. Desarrollo ágil de software. Filosofía y principios del desarrollo ágil. El manifiesto ágil. Métodos de desarrollo ágil: SCRUM, KANBAN. LEAN. DevOps, DevSecOps.

Técnico/a Especialista Informática Servicio Andaluz de Salud JUNTA DE ANDALUCÍA
Esteban Castro
Tema 15 – Desarrollo Ágil de Software | Oposiciones SAS

⚡ TEMA 15 ⚡

Desarrollo Ágil de Software: Filosofía, Principios y Métodos
SCRUM • KANBAN • LEAN • DevOps • DevSecOps
Oposiciones Técnico/a Especialista en Informática – Servicio Andaluz de Salud

📋 Índice de Contenidos

  1. Introducción y Contextualización
  2. Filosofía y Principios del Desarrollo Ágil
  3. El Manifiesto Ágil
  4. SCRUM: Marco de Trabajo Ágil
  5. KANBAN: Gestión Visual del Flujo
  6. LEAN Software Development
  7. DevOps: Cultura de Colaboración
  8. DevSecOps: Seguridad Integrada
  9. Casos Prácticos en el SAS
  10. Cuestionario de Autoevaluación (30 Preguntas)
  11. Mapa Conceptual
  12. Conclusiones y Estrategia de Estudio
  13. Referencias Normativas y Bibliográficas

1. Introducción y Contextualización 🎯

¡Hola, opositor/a!

Este es uno de los temas más importantes y actuales del temario. No es casualidad: el SAS está en plena transformación digital y las metodologías ágiles son el motor de este cambio. Desde la evolución continua de Diraya hasta el desarrollo de nuevas apps móviles para pacientes, todo se está haciendo con Scrum, Kanban, DevOps…

¿Por qué te cuento esto? Porque en el examen te van a caer preguntas técnicas muy concretas sobre estos métodos. Y no solo conceptos teóricos, sino casos prácticos aplicados al SAS. Así que vamos a trabajarlo a fondo.

1.1. Relevancia para el Técnico Especialista en Informática del SAS

Como Técnico Especialista en Informática del SAS, tu trabajo no se limita a mantener sistemas heredados. El SAS está migrando activamente hacia:

  • Desarrollo iterativo e incremental en aplicaciones críticas como Diraya
  • Ciclos de entrega continuos (CI/CD) para apps móviles de pacientes
  • Equipos multidisciplinares que incluyen desarrolladores, operaciones y seguridad
  • Automatización de despliegues en infraestructuras cloud híbridas
  • Integración de seguridad desde el diseño (shift-left security)

Todo esto requiere dominar las metodologías ágiles. No es opcional: es tu día a día.

1.2. Contexto Histórico: Del Waterfall al Agile

Para entender realmente el valor del desarrollo ágil, necesitas saber de dónde venimos:

Modelo en Cascada (Waterfall) Desarrollo Ágil
Planificación exhaustiva al inicio Planificación adaptativa continua
Requisitos fijos y documentación extensa Requisitos cambiantes, documentación mínima
Entregas al final del proyecto (meses/años) Entregas incrementales frecuentes (semanas)
Cambios costosos y difíciles Cambios bienvenidos en cualquier momento
Cliente ve el producto al final Cliente colabora continuamente
Equipos especializados y separados Equipos multidisciplinares integrados
⚠️ IMPORTANTE PARA EL EXAMEN:

Las preguntas sobre la diferencia entre metodologías tradicionales y ágiles son MUY frecuentes. Memoriza bien esta tabla.

1.3. ¿Por qué el SAS Apuesta por Agile?

El sector sanitario presenta desafíos únicos que hacen imprescindibles las metodologías ágiles:

  1. Cambios normativos frecuentes: El RGPD, la Ley de Protección de Datos, el ENS… Las normativas cambian y los sistemas deben adaptarse rápido.
  2. Necesidades clínicas en evolución: Los profesionales sanitarios necesitan nuevas funcionalidades en Diraya constantemente. No pueden esperar 2 años a una gran release.
  3. Integración con múltiples sistemas: Diraya debe interoperar con receta electrónica, con el sistema de citas, con laboratorios… La coordinación entre equipos es crítica.
  4. Alta disponibilidad requerida: Los sistemas sanitarios no pueden «caerse». Los despliegues deben ser frecuentes pero seguros.
  5. Seguridad crítica: Los datos de salud son sensibles. La seguridad debe estar integrada desde el inicio (DevSecOps).
✅ Caso Real del SAS:

Durante la pandemia COVID-19, el SAS desarrolló en tiempo récord el módulo de gestión de vacunación en Diraya. ¿Cómo fue posible? Equipos Scrum trabajando en sprints de 2 semanas, con entregas incrementales, DevOps para despliegues diarios, y colaboración continua con los profesionales sanitarios. Sin metodologías ágiles, hubiera sido imposible.

1.4. Relación con Otros Temas del Temario

Este tema no es un «tema aislado». Se conecta directamente con:

  • Tema 14 (Ciclo de Vida del Software): Las metodologías ágiles son modelos de ciclo de vida iterativo-incremental
  • Tema 16 (Construcción de Sistemas): Las pruebas en Agile son continuas y automatizadas
  • Tema 17 (Herramientas de Desarrollo): Git, Jenkins, Docker… son herramientas clave para Agile/DevOps
  • Tema 35-36 (Seguridad): DevSecOps integra seguridad en el ciclo ágil
  • Tema 12 (ITIL): ITIL 4 incorpora principios ágiles en la gestión de servicios TI

2. Filosofía y Principios del Desarrollo Ágil 🧘

Antes de meternos en SCRUM, Kanban, DevOps… necesitas entender la filosofía que sustenta todo esto. Porque las metodologías ágiles no son solo «formas de trabajar»: son una mentalidad, una cultura.

2.1. La Filosofía Ágil: Mindset, No Framework

Lo primero que debes comprender: Agile no es una metodología, es una filosofía. SCRUM es una metodología. Kanban es una metodología. DevOps es una cultura. Pero Agile es el mindset (mentalidad) que sustenta todo.

¿Qué significa esto en la práctica?

  1. Personas sobre procesos: Un equipo cohesionado es más valioso que un proceso perfecto
  2. Software funcionando sobre documentación: Mejor entregar valor real que documentos extensos
  3. Colaboración con el cliente sobre negociación contractual: El cliente es parte del equipo, no un adversario
  4. Respuesta al cambio sobre seguir un plan: La adaptación es más valiosa que la rigidez
💡 TIP PARA EL EXAMEN:

Estos 4 valores son los pilares del Manifiesto Ágil. Son pregunta segura en el test. Pero ojo: no memmorices literalmente, entiende el concepto. Te pondrán trampas tipo «la documentación no es necesaria en Agile» (FALSO: es necesaria, pero no es lo MÁS importante).

2.2. Principios Fundamentales del Desarrollo Ágil

Más allá de los 4 valores, existen principios operativos que guían el trabajo ágil. Vamos a verlos aplicados al contexto del SAS:

Principio 1: Entrega Continua de Valor

En el SAS: En lugar de esperar 6 meses para lanzar una gran actualización de Diraya con 50 funcionalidades nuevas, se entregan incrementos cada 2-3 semanas con 2-3 funcionalidades funcionando. Los médicos empiezan a usarlas de inmediato y dan feedback.

Principio 2: Bienvenida al Cambio

En el SAS: Imagina que a mitad del desarrollo del módulo de vacunación COVID, cambia el protocolo de vacunación y ahora hay que registrar datos adicionales. En Waterfall, esto sería un cambio costosísimo. En Agile, se adapta el Sprint siguiente y listo.

Principio 3: Entregas Frecuentes

En el SAS: Los despliegues en Diraya se hacen semanalmente en ventanas de mantenimiento. DevOps permite automatizar estos despliegues con riesgo mínimo.

Principio 4: Colaboración Diaria

En el SAS: El Product Owner (normalmente un médico o enfermero con conocimiento clínico) trabaja codo con codo con el equipo de desarrollo. No es alguien que entrega requisitos y se va: está cada día disponible.

Principio 5: Equipos Motivados y Autónomos

En el SAS: Los equipos Scrum del SAS tienen autonomía para decidir cómo implementar las historias de usuario. No hay un «jefe» que les dice cómo programar. Confía en ellos y dales las herramientas que necesitan.

Principio 6: Conversación Cara a Cara

En el SAS: Las Daily Standup Meetings (reuniones diarias de 15 minutos) son presenciales o por videoconferencia. No se sustituyen por emails. La comunicación directa es más eficiente.

Principio 7: Software Funcionando como Medida de Progreso

En el SAS: No se mide el progreso por «documentos entregados» o «líneas de código escritas». Se mide por funcionalidades desplegadas en producción que los usuarios pueden usar.

Principio 8: Desarrollo Sostenible

En el SAS: No hay «crunch time» permanente. Los sprints son de 2-3 semanas con ritmo constante. No se puede pedir al equipo que trabaje 60 horas/semana indefinidamente. Eso quema a la gente y genera errores.

Principio 9: Excelencia Técnica

En el SAS: Code reviews, testing automatizado, estándares de código, arquitectura limpia… La calidad técnica no se sacrifica por la velocidad. De hecho, la calidad técnica es lo que permite la velocidad sostenible.

Principio 10: Simplicidad

En el SAS: No desarrolles funcionalidades «por si acaso». Solo lo que el usuario necesita ahora. YAGNI (You Aren’t Gonna Need It) es un principio ágil fundamental.

Principio 11: Equipos Auto-organizados

En el SAS: El equipo Scrum decide internamente quién hace qué tarea. No hay un «project manager» asignando tareas. El equipo se auto-organiza.

Principio 12: Reflexión y Mejora Continua

En el SAS: Al final de cada Sprint, hay una Retrospectiva donde el equipo analiza qué salió bien, qué salió mal, y qué van a mejorar en el próximo Sprint. Es el kaizen (mejora continua) aplicado al desarrollo software.

⚠️ CRÍTICO PARA EL EXAMEN:

Son 12 principios del Manifiesto Ágil. Memorízalos bien porque te pueden preguntar cuál de las siguientes afirmaciones NO es un principio ágil. Las trampas típicas son:

  • «La documentación exhaustiva es prioritaria» (FALSO)
  • «El software debe funcionar antes de entregarlo» (VERDADERO)
  • «Los requisitos no pueden cambiar una vez iniciado el proyecto» (FALSO)
  • «La comunicación cara a cara es la más efectiva» (VERDADERO)

3. El Manifiesto Ágil 📜

En febrero de 2001, 17 desarrolladores de software se reunieron en Snowbird, Utah (EE.UU.). Estaban hartos de los métodos tradicionales pesados y rígidos. De esa reunión salió el Manifiesto por el Desarrollo Ágil de Software.

Este manifiesto no es «teoría bonita»: es la base de todo lo que vas a estudiar en este tema y lo que aplicas cada día en el SAS.

3.1. Los Cuatro Valores del Manifiesto

El manifiesto establece 4 valores. Y ojo con la redacción, porque es importante:

Valor 1: Individuos e interacciones sobre procesos y herramientas

Lo que SÍ significa: Un equipo cohesionado, comunicativo y colaborativo es más valioso que tener las mejores herramientas o el proceso más perfecto.

Lo que NO significa: «Los procesos y herramientas no importan». Sí importan, pero son secundarios respecto a las personas.

Ejemplo SAS: Mejor un equipo de Diraya con buena comunicación usando Jira básico, que un equipo disfuncional con la mejor suite de gestión del mundo.

Valor 2: Software funcionando sobre documentación exhaustiva

Lo que SÍ significa: Entregar código que funciona y aporta valor al usuario es más importante que generar documentación extensa.

Lo que NO significa: «No hace falta documentación». La documentación es necesaria, pero debe ser concisa y útil.

Ejemplo SAS: En el desarrollo de la app móvil de ClicSalud+, es más valioso tener la funcionalidad de pedir cita funcionando que tener 200 páginas de especificaciones técnicas sin código.

Valor 3: Colaboración con el cliente sobre negociación contractual

Lo que SÍ significa: El cliente (Product Owner, usuarios finales) es parte activa del equipo y colabora continuamente. No es alguien contra quien «defenderse» contractualmente.

Lo que NO significa: «No hace falta contrato». Los contratos siguen siendo necesarios (sobre todo en la administración pública), pero la colaboración prevalece sobre la rigidez contractual.

Ejemplo SAS: Los médicos que usan Diraya son los «clientes internos». Participan activamente en las Sprint Reviews, dan feedback, priorizan funcionalidades. No están «al otro lado».

Valor 4: Respuesta ante el cambio sobre seguir un plan

Lo que SÍ significa: La capacidad de adaptarse a cambios (requisitos nuevos, cambios normativos, nuevas tecnologías) es más valiosa que ceñirse rígidamente a un plan inicial.

Lo que NO significa: «No hace falta planificar». La planificación es necesaria, pero debe ser adaptativa, no rígida.

Ejemplo SAS: Durante COVID, los planes de 2020 quedaron obsoletos en marzo. Los equipos ágiles pivotaron rápidamente a desarrollar módulos de triaje, telemedicina, vacunación… Los equipos Waterfall seguirían con el plan original mientras el mundo cambiaba.

3.2. Los Doce Principios del Manifiesto

Los 4 valores se concretan en 12 principios operativos. Vamos a verlos con ejemplos del SAS:

# Principio Aplicación en el SAS
1 Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor. Despliegues semanales de mejoras incrementales en Diraya que los médicos pueden usar de inmediato.
2 Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente. Si cambia la normativa de receta electrónica, el equipo adapta el Sprint en curso sin drama.
3 Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo más corto posible. Sprints de 2 semanas en los equipos de Diraya, con demo al final de cada Sprint.
4 Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto. El médico Product Owner participa en las Daily Standups y está disponible diariamente para resolver dudas.
5 Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo. Los equipos tienen autonomía técnica, herramientas adecuadas (servidores de desarrollo, licencias), y apoyo de la dirección TIC.
6 El método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre sus miembros es la conversación cara a cara. Daily Standups presenciales de 15 minutos cada mañana. Nada de «seguimiento por email».
7 El software funcionando es la medida principal de progreso. No se mide el progreso por «horas trabajadas» o «documentos escritos». Se mide por funcionalidades en producción.
8 Los procesos Ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida. Sprints de 2 semanas con carga de trabajo sostenible. No hay «death marches» permanentes.
9 La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad. Code reviews obligatorios, testing automatizado, arquitectura limpia, refactoring continuo.
10 La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial. Principio YAGNI: no desarrollar funcionalidades «por si acaso». Solo lo que el usuario necesita ahora.
11 Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-organizados. El equipo decide la arquitectura técnica de cada historia de usuario. No hay un «arquitecto jefe» imponiendo decisiones.
12 A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a continuación ajustar y perfeccionar su comportamiento en consecuencia. Sprint Retrospective al final de cada Sprint: ¿qué mejorar? Kaizen aplicado.
🚨 TRAMPA DE EXAMEN:

Cuidado con preguntas tipo: «¿Cuál de los siguientes NO es un principio del Manifiesto Ágil?»

  • ❌ «La documentación exhaustiva garantiza la calidad» → NO es un principio ágil
  • ✅ «El software funcionando es la medida principal de progreso» → SÍ es un principio ágil (el #7)
  • ❌ «Los requisitos deben estar completamente definidos antes de iniciar el desarrollo» → NO es ágil (Waterfall)
  • ✅ «Aceptamos que los requisitos cambien, incluso en etapas tardías» → SÍ es el principio #2

3.3. Firmantes del Manifiesto

Los 17 firmantes originales del Manifiesto Ágil incluyen a figuras muy relevantes en el mundo del software:

  • Kent Beck – Creador de Extreme Programming (XP) y Test-Driven Development (TDD)
  • Ken Schwaber y Jeff Sutherland – Co-creadores de SCRUM
  • Martin Fowler – Experto en refactoring y arquitectura de software
  • Robert C. Martin (Uncle Bob) – Autor de «Clean Code»
  • Alistair Cockburn – Creador de Crystal metodology

Estos nombres son importantes porque cada uno contribuyó con metodologías específicas (SCRUM, XP, Crystal…) que luego se englobaron bajo el paraguas «Agile».

4. SCRUM: Marco de Trabajo Ágil 🏉

SCRUM es el marco de trabajo ágil más utilizado en el mundo. En el SAS, la mayoría de los equipos de desarrollo de Diraya, apps móviles, y nuevos proyectos trabajan con SCRUM.

Importante: SCRUM no es una «metodología», es un marco de trabajo (framework). ¿Cuál es la diferencia? Una metodología te dice exactamente qué hacer paso a paso. Un marco de trabajo te da las reglas del juego, pero tú decides cómo jugar.

4.1. ¿Qué es SCRUM?

SCRUM es un marco de trabajo iterativo e incremental para gestionar proyectos complejos. Se basa en ciclos de trabajo cortos llamados Sprints (normalmente 2-4 semanas) donde se entrega un incremento de producto potencialmente desplegable.

Origen del nombre: «Scrum» viene del rugby, donde el «scrum» es esa formación donde todo el equipo trabaja junto para avanzar el balón. Es una metáfora perfecta: todo el equipo trabaja junto para avanzar el producto.

4.2. Los Tres Pilares de SCRUM

1. Transparencia

Todos los aspectos del proceso deben ser visibles para todos los responsables del resultado. El tablero Scrum, los gráficos burndown, el estado de las tareas… todo es visible.

En el SAS: Tablero Jira público donde cualquiera puede ver el estado de desarrollo de Diraya.

2. Inspección

Los aspectos del proceso deben inspeccionarse frecuentemente para detectar variaciones indeseables. No esperas al final del proyecto para ver si vas bien.

En el SAS: Daily Standups diarias para inspeccionar progreso. Sprint Review para inspeccionar el incremento con los stakeholders.

3. Adaptación

Si detectas que el proceso se desvía, debes ajustarlo lo antes posible. No esperas a «ver qué pasa».

En el SAS: En la Retrospectiva, el equipo decide cambios concretos para el próximo Sprint.

4.3. Los Roles en SCRUM

SCRUM define 3 roles y solo 3. No hay «project managers», no hay «team leaders». Esos roles no existen en SCRUM.

4.3.1. Product Owner (PO)

Es la voz del cliente dentro del equipo. Tiene la autoridad para decidir QUÉ se construye y en qué ORDEN.

Responsabilidades del PO:

  • Gestionar el Product Backlog (la lista priorizada de funcionalidades pendientes)
  • Priorizar las historias de usuario según valor de negocio
  • Aceptar o rechazar el trabajo completado en cada Sprint
  • Estar disponible para el equipo para resolver dudas sobre requisitos
  • Participar activamente en Sprint Planning y Sprint Review
💡 En el SAS:

En un equipo de desarrollo de Diraya, el Product Owner podría ser un médico de familia con conocimiento profundo de los procesos clínicos y las necesidades de los usuarios finales. Esta persona decide si es más importante desarrollar primero la funcionalidad de receta electrónica o la de solicitud de pruebas diagnósticas.

❌ Error Común:

Pensar que el PO es el «jefe» del equipo. NO. El PO decide el QUÉ, pero el equipo decide el CÓMO. El PO no puede decir «tienes que programar esto en Java con esta arquitectura». Eso lo decide el equipo.

4.3.2. Scrum Master (SM)

Es el facilitador del proceso Scrum. Su misión es asegurar que el equipo entiende y sigue las reglas de Scrum, y eliminar impedimentos que bloqueen al equipo.

Responsabilidades del SM:

  • Facilitar todas las ceremonias Scrum (Daily, Planning, Review, Retrospective)
  • Eliminar impedimentos que bloqueen al equipo (problemas técnicos, organizativos, etc.)
  • Proteger al equipo de interrupciones externas durante el Sprint
  • Entrenar al equipo en prácticas ágiles
  • Fomentar la mejora continua
💡 En el SAS:

El Scrum Master del equipo de Diraya detecta que el equipo está bloqueado porque no tienen acceso al entorno de preproducción. En lugar de decir «bueno, ya lo resolverá alguien», el SM escala el problema, coordina con sistemas, y consigue el acceso en 24 horas. Eso es eliminar impedimentos.

❌ Error Común:

Pensar que el Scrum Master es el «project manager» rebautizado. NO. El SM no asigna tareas, no controla horarios, no «gestiona» al equipo. Facilita y elimina obstáculos. Nada más.

4.3.3. Development Team (Equipo de Desarrollo)

Son los profesionales que hacen el trabajo de entregar el incremento de producto. En software, incluye desarrolladores, testers, DBAs, etc.

Características del Development Team:

  • Auto-organizado: Deciden internamente quién hace qué y cómo
  • Multifuncional: Tienen todas las habilidades necesarias para entregar el incremento (no dependen de equipos externos)
  • No hay sub-equipos: No hay «equipo frontend» y «equipo backend». Todos son Development Team
  • No hay títulos individuales: Todos son «desarrolladores», no hay «senior developer» o «junior developer» en Scrum (aunque en la práctica sí los hay por temas salariales)
  • Tamaño recomendado: 3-9 personas. Menos de 3 no hay masa crítica. Más de 9 la coordinación se vuelve compleja
💡 En el SAS:

Un Development Team para Diraya podría incluir: 3 desarrolladores Java, 1 desarrollador frontend (Angular), 1 DBA, 1 QA/tester, 1 DevOps. Entre todos entregan el incremento funcionando en cada Sprint, sin depender de equipos externos.

4.4. Los Artefactos de SCRUM

Los «artefactos» son los elementos tangibles que Scrum produce. Son 3:

4.4.1. Product Backlog

Es la lista ordenada de todo lo que se conoce que es necesario en el producto. Es dinámica: crece y cambia constantemente.

Características:

  • Ordenado por prioridad (lo más importante arriba)
  • Evoluciona continuamente (se añaden, eliminan, refinan elementos)
  • Los elementos del Product Backlog se llaman Product Backlog Items (PBIs). Normalmente son Historias de Usuario
  • El Product Owner es el dueño del Product Backlog
Ejemplo de Product Backlog de Diraya: 1. [ALTA] Historia: Como médico quiero poder ver el historial de medicación del paciente para prescribir de forma segura Prioridad: CRÍTICA | Estimación: 13 puntos 2. [ALTA] Historia: Como enfermero quiero poder registrar constantes vitales en tablet para agilizar la consulta Prioridad: ALTA | Estimación: 8 puntos 3. [MEDIA] Historia: Como administrativo quiero poder modificar citas con más flexibilidad para atender cambios urgentes Prioridad: MEDIA | Estimación: 5 puntos 4. [BAJA] Historia: Como paciente quiero poder descargar mis informes en PDF desde ClicSalud+ para llevarlos a otras consultas Prioridad: BAJA | Estimación: 3 puntos

Refinamiento del Product Backlog:

Es una actividad continua donde el equipo y el PO añaden detalles, estimaciones y orden a los elementos del Product Backlog. No es una ceremonia formal, pero suele hacerse mid-sprint.

4.4.2. Sprint Backlog

Es el conjunto de elementos del Product Backlog seleccionados para el Sprint, más un plan para entregarlos.

Características:

  • Se crea en la Sprint Planning
  • Es propiedad del Development Team (no del PO ni del SM)
  • Puede modificarse durante el Sprint (si el equipo descubre que hace falta más/menos trabajo)
  • Incluye las historias de usuario Y las tareas técnicas necesarias para completarlas
Ejemplo de Sprint Backlog (Sprint 45 – Diraya): OBJETIVO DEL SPRINT: Implementar visualización de historial de medicación Historia 1: Ver historial de medicación del paciente – Tarea 1.1: Crear tabla BD para almacenar historial medicación (3h) [Juan] – Tarea 1.2: Desarrollar API REST para consultar historial (5h) [María] – Tarea 1.3: Diseñar componente UI para visualización (4h) [Pedro] – Tarea 1.4: Integrar componente con API (3h) [Pedro] – Tarea 1.5: Pruebas unitarias (2h) [María] – Tarea 1.6: Pruebas de integración (3h) [Luis] Total: 20 horas Historia 2: Filtrar medicación por fecha y tipo – Tarea 2.1: Añadir filtros a API (4h) [María] – Tarea 2.2: Implementar filtros en UI (3h) [Pedro] – Tarea 2.3: Pruebas (2h) [Luis] Total: 9 horas TOTAL SPRINT: 29 horas de 80 horas disponibles del equipo

4.4.3. Incremento

Es la suma de todos los Product Backlog Items completados durante el Sprint y todos los Sprints anteriores. Al final de cada Sprint, el Incremento debe estar en condición «Done» (hecho) y potencialmente desplegable.

Definición de «Done» (DoD):

Es el acuerdo del equipo sobre qué significa que algo está «terminado». Es crítica porque elimina ambigüedades.

Ejemplo de «Definition of Done» en el SAS: Una historia de usuario está «Done» cuando: ✅ Código desarrollado y cumple los requisitos ✅ Código revisado por otro desarrollador (code review) ✅ Pruebas unitarias escritas y pasando (coverage >80%) ✅ Pruebas de integración pasando ✅ Documentación técnica actualizada ✅ Cumple estándares de seguridad ENS-MEDIO ✅ Desplegado en entorno de preproducción ✅ Validado por el Product Owner ✅ Sin bugs bloqueantes abiertos
⚠️ IMPORTANTE PARA EL EXAMEN:

Pregunta típica: «¿Cuál es el resultado de un Sprint de SCRUM?»

Respuesta correcta: Un Incremento (no «Sprint Backlog», no «Producto», no «Pila del Sprint» – esa es traducción mal hecha de Sprint Backlog).

4.5. Las Ceremonias (Eventos) de SCRUM

SCRUM define 5 eventos formales (time-boxed, es decir, con tiempo máximo definido):

4.5.1. Sprint

Es el contenedor de todos los demás eventos. Tiene duración fija (1-4 semanas, típicamente 2 semanas) y en cuanto termina uno, empieza otro.

Reglas del Sprint:

  • Durante el Sprint NO se hacen cambios que pongan en peligro el objetivo del Sprint
  • La calidad no disminuye
  • El alcance puede clarificarse y renegociarse entre el PO y el Development Team
  • Un Sprint puede cancelarse (solo el PO puede hacerlo), pero es muy raro y costoso
💡 En el SAS:

Los equipos de Diraya trabajan en Sprints de 2 semanas. Sprint 1: 4-17 enero. Sprint 2: 18-31 enero. Y así sucesivamente. Sin vacíos entre sprints.

4.5.2. Sprint Planning (Planificación del Sprint)

Es la reunión donde el equipo decide QUÉ se va a hacer en el Sprint y CÓMO se va a hacer.

Duración máxima: 8 horas para un Sprint de 1 mes (proporcionalmente menos para Sprints más cortos; para Sprint de 2 semanas: 4 horas máximo)

Participantes: Todo el Scrum Team (PO + SM + Development Team)

Preguntas que se responden:

  1. ¿Qué puede entregarse en el Incremento resultante del Sprint? (El PO presenta las historias de usuario más prioritarias del Product Backlog, y el equipo decide cuántas puede comprometerse a completar)
  2. ¿Cómo se conseguirá hacer el trabajo necesario? (El Development Team descompone las historias en tareas técnicas y estima esfuerzo)

Salida de la Sprint Planning:

  • El Sprint Goal (objetivo del Sprint): Una frase que resume el propósito del Sprint
  • El Sprint Backlog: Las historias seleccionadas + tareas técnicas
Ejemplo Sprint Planning – Equipo Diraya: Sprint Goal: «Permitir a los médicos visualizar el historial completo de medicación de los pacientes» Historias Seleccionadas: – Historia 1: Ver historial de medicación (13 puntos) – Historia 2: Filtrar medicación por fecha y tipo (8 puntos) Total: 21 puntos (dentro de la velocidad del equipo: 20-25 puntos/sprint) Plan de Trabajo: [Descomposición en tareas técnicas como vimos antes]

4.5.3. Daily Scrum (Reunión Diaria)

Es una reunión diaria de máximo 15 minutos donde el Development Team sincroniza su trabajo y planifica las próximas 24 horas.

Características:

  • Duración: Máximo 15 minutos, a la misma hora y lugar cada día
  • Participantes: Development Team (obligatorio). PO y SM pueden asistir pero no participan activamente
  • Formato típico: Cada miembro responde 3 preguntas:
    1. ¿Qué hice ayer que ayudó al equipo a cumplir el Sprint Goal?
    2. ¿Qué voy a hacer hoy para ayudar al equipo a cumplir el Sprint Goal?
    3. ¿Hay algún impedimento que me bloquea o bloquea al equipo?
  • NO es una reunión de reporte al jefe: Es una reunión del equipo para el equipo
💡 En el SAS:

El equipo de Diraya hace la Daily Scrum cada día a las 9:15 AM, de pie (standing meeting) frente al tablero Jira. Dura 10-12 minutos. Si surge un tema complejo, se marca para discutirlo DESPUÉS de la Daily (no durante).

❌ Errores Comunes en la Daily:
  • Convertirla en reunión de reporte al Scrum Master (NO es eso)
  • Entrar en debates técnicos profundos (eso se hace después)
  • Que dure más de 15 minutos (time-box estricto)
  • Que cada uno hable mirando al SM en lugar de al equipo

4.5.4. Sprint Review (Revisión del Sprint)

Es la reunión al final del Sprint donde el equipo muestra el Incremento (el trabajo completado) a los stakeholders y obtiene feedback.

Duración máxima: 4 horas para un Sprint de 1 mes (para Sprint de 2 semanas: 2 horas)

Participantes: Scrum Team + Stakeholders invitados (usuarios, dirección, otros equipos…)

Qué se hace:

  1. El Product Owner explica qué elementos del Product Backlog se completaron («Done») y cuáles no
  2. El Development Team hace una demo del Incremento funcionando (no PowerPoint, código funcionando real)
  3. Los stakeholders dan feedback
  4. El Product Owner discute el Product Backlog y proyecta fechas de entrega basándose en el progreso
  5. El grupo colabora sobre qué hacer a continuación (input para la siguiente Sprint Planning)
✅ Ejemplo Sprint Review en el SAS:

Sprint Review del equipo de Diraya. Asisten: el equipo Scrum, 3 médicos de familia (usuarios finales), el responsable TIC del área sanitaria, y representantes de calidad asistencial.

El equipo hace una demo en vivo mostrando cómo ahora los médicos pueden ver el historial completo de medicación de un paciente, filtrar por fechas, y exportar a PDF. Los médicos prueban la funcionalidad allí mismo y dan feedback inmediato: «Genial, pero necesitamos también ver las alergias medicamentosas junto a la medicación». El PO anota esto como nueva historia de usuario para futuros Sprints.

⚠️ CRÍTICO PARA EL EXAMEN:

Pregunta típica: «¿Qué ocurre en la Sprint Review?»

Respuesta correcta: «Se presenta el incremento del producto terminado y se obtiene retroalimentación de los interesados (stakeholders)».

NO confundir con: Sprint Retrospective (esa es sobre el PROCESO, no sobre el PRODUCTO)

4.5.5. Sprint Retrospective (Retrospectiva del Sprint)

Es la reunión donde el equipo reflexiona sobre su propio proceso de trabajo y define mejoras concretas para el próximo Sprint.

Duración máxima: 3 horas para un Sprint de 1 mes (para Sprint de 2 semanas: 1.5 horas)

Participantes: Solo el Scrum Team (PO + SM + Development Team). Los stakeholders NO participan (es una reunión interna)

Cuándo ocurre: Después de la Sprint Review y antes de la siguiente Sprint Planning

Qué se analiza:

  • ¿Qué salió bien en el Sprint?
  • ¿Qué salió mal o podría mejorar?
  • ¿Qué vamos a hacer diferente en el próximo Sprint?

Salida: Al menos 1 mejora concreta que el equipo implementará en el próximo Sprint

Ejemplo Retrospectiva – Equipo Diraya (Sprint 45): 🟢 QUÉ SALIÓ BIEN: – Las code reviews fueron más rápidas (mismo día) – La comunicación con el PO fue excelente – Cumplimos el Sprint Goal completo 🟠 QUÉ PODEMOS MEJORAR: – Las pruebas de integración nos llevaron más tiempo del esperado – Hubo 2 días con problemas en el entorno de desarrollo (nos bloqueó) – Las estimaciones fueron demasiado optimistas ✅ ACCIONES PARA EL PRÓXIMO SPRINT: 1. Acción: Crear scripts de pruebas de integración automatizadas Responsable: María 2. Acción: Solicitar al SM que escale el tema de estabilidad del entorno de desarrollo Responsable: SM 3. Acción: Añadir un 20% de buffer a las estimaciones (lecciones aprendidas) Responsable: Todo el equipo
⚠️ IMPORTANTE PARA EL EXAMEN:

Sprint Review vs Sprint Retrospective – Diferencia clave:

  • Sprint Review: Sobre el PRODUCTO (incremento). Asisten stakeholders.
  • Sprint Retrospective: Sobre el PROCESO (forma de trabajar). Solo el Scrum Team.

Esta es una pregunta CLÁSICA de examen. Memoriza bien la diferencia.

4.6. Métricas en SCRUM

SCRUM utiliza varias métricas para medir el progreso y la salud del proyecto:

4.6.1. Velocity (Velocidad)

Es la cantidad de trabajo (medida en story points) que un equipo puede completar en un Sprint. Se calcula promediando los últimos 3-5 Sprints.

Equipo Diraya – Velocidad: Sprint 43: 18 puntos completados Sprint 44: 22 puntos completados Sprint 45: 20 puntos completados Sprint 46: 21 puntos completados Sprint 47: 19 puntos completados Velocidad promedio: (18+22+20+21+19)/5 = 20 puntos/sprint Uso: En la Sprint Planning, el equipo sabe que puede comprometerse a ~20 puntos de historia de usuario.

4.6.2. Burndown Chart (Gráfico de Quemado)

Gráfico que muestra el trabajo restante (eje Y) frente al tiempo (eje X). Idealmente, la línea baja de forma constante hasta llegar a cero al final del Sprint.

Burndown Chart – Sprint 47 Diraya (2 semanas = 10 días laborables) Día | Puntos Restantes | Ideal —–|——————-|——- 0 | 20 | 20 1 | 20 | 18 2 | 18 | 16 3 | 15 | 14 4 | 15 | 12 5 | 12 | 10 6 | 12 | 8 7 | 9 | 6 8 | 5 | 4 9 | 2 | 2 10 | 0 | 0 ✅ El equipo terminó todo el trabajo comprometido

4.6.3. Burnup Chart (Gráfico de Acumulación)

Muestra el trabajo completado (eje Y) frente al tiempo (eje X). Útil para proyectos largos con múltiples Sprints.

4.6.4. Cumulative Flow Diagram (CFD)

Este gráfico es más típico de Kanban, pero algunos equipos Scrum también lo usan. Muestra el estado de las historias de usuario a lo largo del tiempo (To Do, In Progress, Done).

4.7. SCRUM en el SAS: Casos Reales

📋 Caso Práctico 1: Implementación de SCRUM en el Desarrollo de Diraya

Contexto: El equipo de desarrollo de Diraya (Historia Digital de Salud) necesita añadir un módulo de gestión de vacunación para la campaña de gripe 2024.

Configuración del Equipo Scrum:

  • Product Owner: Dra. Carmen López, médico de familia con 15 años de experiencia
  • Scrum Master: Pedro Martínez, Técnico Especialista TIC con formación como Scrum Master Certificado
  • Development Team (7 personas):
    • 3 desarrolladores Java/Spring Boot
    • 1 desarrollador frontend (Angular)
    • 1 DBA (Oracle)
    • 1 QA/Tester
    • 1 DevOps Engineer

Sprint 1 (2 semanas): Registro Básico de Vacunación

Sprint Goal: «Permitir a las enfermeras registrar la administración de vacunas de gripe con datos mínimos obligatorios»

Sprint Backlog:

  • Historia 1: Como enfermera quiero poder registrar que he administrado una vacuna de gripe a un paciente (8 puntos)
  • Historia 2: Como enfermera quiero poder consultar el historial de vacunaciones de un paciente (5 puntos)
  • Historia 3: Como médico quiero poder ver alertas si un paciente tiene contraindicaciones para la vacuna (8 puntos)

Resultados Sprint 1:

  • ✅ Se completaron las 3 historias (21 puntos)
  • ✅ Sprint Review: Los enfermeros probaron la funcionalidad y dieron feedback positivo
  • ✅ Sprint Retrospective: El equipo decidió mejorar las pruebas automatizadas para el siguiente Sprint

Ventajas del Enfoque SCRUM:

  • La funcionalidad básica estuvo disponible en 2 semanas (vs 3-4 meses con Waterfall)
  • El feedback temprano de las enfermeras permitió ajustar la interfaz antes de seguir desarrollando
  • La colaboración diaria con la Product Owner (Dra. López) evitó malentendidos sobre requisitos clínicos

5. KANBAN: Gestión Visual del Flujo 📊

Si SCRUM es como el rugby (trabajo en equipo por sprints), KANBAN es como una cadena de producción optimizada. Viene de Toyota y su sistema de manufactura Just-In-Time.

KANBAN no es una metodología de desarrollo de software per se: es un método de gestión del flujo de trabajo. Y es muy popular en el SAS para equipos de operaciones, soporte, y mantenimiento.

5.1. ¿Qué es KANBAN?

KANBAN (看板 en japonés, literalmente «tarjeta visual») es un método para gestionar el trabajo basado en:

  1. Visualizar el trabajo: Todo el trabajo se representa en un tablero visual
  2. Limitar el Work In Progress (WIP): Solo puedes tener un número limitado de tareas «en progreso» simultáneamente
  3. Gestionar el flujo: Mides y optimizas el tiempo que tarda cada tarea en completarse
  4. Mejorar continuamente: Experimentas con cambios y mides resultados

5.2. Diferencias Clave entre SCRUM y KANBAN

Aspecto SCRUM KANBAN
Iteraciones Sprints de tiempo fijo (1-4 semanas) Flujo continuo (no hay sprints)
Roles 3 roles definidos (PO, SM, Dev Team) No prescribe roles específicos
Cambios No se cambia el Sprint Backlog durante el Sprint Se pueden añadir tareas en cualquier momento
Métrica Principal Velocity (puntos por Sprint) Lead Time / Cycle Time (tiempo por tarea)
Tablero Se resetea cada Sprint Persistente (flujo continuo)
Límites WIP Indirecto (tamaño del Sprint Backlog) Explícito (máx. X tareas en cada columna)
Estimación Obligatoria (story points) Opcional
Mejor Para Desarrollo de producto con releases Mantenimiento, soporte, operaciones
💡 ¿Cuándo usar SCRUM y cuándo KANBAN en el SAS?
  • SCRUM: Desarrollo de nuevas funcionalidades de Diraya, proyectos con entregables claros
  • KANBAN: Equipo de ayudaDIGITAL (Service Desk), mantenimiento correctivo de sistemas, migraciones
  • SCRUMBAN (híbrido): Equipos de mantenimiento evolutivo que combinan nuevas funcionalidades con corrección de bugs

5.3. Los 6 Principios de KANBAN

1. Visualizar el Flujo de Trabajo

Representa todo el trabajo en un tablero Kanban con columnas que representan estados.

Tablero Kanban básico: | BACKLOG | TO DO | IN PROGRESS | TESTING | DONE | |———|——-|————-|———|——| | [10] | [5] | [3/3] | [2/2] | | ↑WIP límite ↑WIP límite

2. Limitar el Work In Progress (WIP)

Establecer un límite máximo de tareas que pueden estar simultáneamente en cada columna. Esto previene sobrecarga y mejora el flujo.

En el SAS: El equipo de ayudaDIGITAL limita a máximo 5 incidencias «En Resolución» simultáneamente por técnico. Si hay 5, no se puede tomar una sexta hasta terminar alguna.

3. Gestionar el Flujo

Medir y optimizar el tiempo que tarda cada trabajo en pasar de «inicio» a «fin» (Lead Time).

4. Hacer las Políticas Explícitas

Definir claramente cuándo una tarea puede moverse de una columna a otra (Definition of Done para cada estado).

Políticas explícitas – Tablero Kanban ayudaDIGITAL: Una incidencia pasa de TO DO a IN PROGRESS cuando: ✅ Está asignada a un técnico específico ✅ El técnico tiene disponibilidad (WIP no alcanzado) ✅ Se ha confirmado con el usuario el problema Una incidencia pasa de IN PROGRESS a TESTING cuando: ✅ La solución está implementada ✅ El técnico ha hecho pruebas básicas ✅ Se ha documentado la solución en la base de conocimiento Una incidencia pasa de TESTING a DONE cuando: ✅ El usuario ha validado la solución ✅ La documentación está completa ✅ Se ha actualizado la CMDB si procede

5. Implementar Bucles de Feedback

Reuniones regulares para revisar métricas y ajustar el proceso.

6. Mejorar Colaborativamente, Evolucionar Experimentalmente

Kaizen: mejora continua basada en datos.

5.4. Métricas Clave en KANBAN

5.4.1. Lead Time

Es el tiempo total desde que se hace una petición hasta que se entrega. Es lo que le importa al cliente.

Ejemplo Lead Time – ayudaDIGITAL: Incidencia #12345: «No puedo acceder a Diraya desde mi PC» – Reportada: Lunes 9:00 – Asignada: Lunes 9:30 – Iniciada resolución: Lunes 10:00 – Resuelta: Lunes 11:30 – Verificada por usuario: Lunes 12:00 Lead Time: 3 horas (desde reporte hasta verificación)

5.4.2. Cycle Time

Es el tiempo desde que se empieza a trabajar en algo hasta que se termina. Excluye el tiempo de espera.

Usando el ejemplo anterior: Cycle Time: 2 horas (desde inicio resolución 10:00 hasta verificación 12:00) La diferencia (Lead Time – Cycle Time = 1 hora) es tiempo de espera.

5.4.3. Cumulative Flow Diagram (CFD)

Es el diagrama estrella de KANBAN. Muestra el estado de las tareas a lo largo del tiempo.

⚠️ CRÍTICO PARA EL EXAMEN:

Pregunta típica: «¿Qué tipo de diagrama se utiliza comúnmente en Kanban para visualizar el flujo de trabajo y el tiempo de ciclo?»

Respuesta correcta: Diagrama de Flujo Acumulativo (CFD)

NO ES: Diagrama de Gantt (ese es de gestión tradicional), ni diagrama de casos de uso (ese es de UML)

5.4.4. Throughput

Número de tareas completadas por unidad de tiempo (ej: incidencias resueltas por día).

5.5. KANBAN en el SAS: Caso Práctico

📋 Caso Práctico 2: KANBAN en el Service Desk del SAS (ayudaDIGITAL)

Contexto: El Service Desk del SAS (ayudaDIGITAL) recibe unas 200 incidencias diarias de los 100,000+ usuarios del SAS (médicos, enfermeros, administrativos…).

Problemas Previos (Antes de KANBAN):

  • Los técnicos tenían asignadas 15-20 incidencias simultáneamente → multitasking caótico
  • No había visibilidad de dónde estaban «atascadas» las incidencias
  • El tiempo medio de resolución era alto y muy variable
  • Los usuarios se quejaban de falta de seguimiento

Implementación de KANBAN:

1. Diseño del Tablero Kanban:

Tablero KANBAN ayudaDIGITAL: ┌──────────┬──────────┬──────────────┬──────────────┬──────────┬────────┐ │ BACKLOG │ TRIAJE │ PENDIENTE │ EN CURSO │ VERIFIC. │ DONE │ │ │ (10) │ ASIGNACIÓN │ (WIP: 15) │ (WIP: 5) │ │ │ │ │ (20) │ │ │ │ └──────────┴──────────┴──────────────┴──────────────┴──────────┴────────┘ Políticas: – TRIAJE: Categorizar urgencia y complejidad (máx. 10 en triaje) – PENDIENTE ASIGNACIÓN: Priorizadas y listas para tomar (máx. 20) – EN CURSO: Técnico trabajando activamente (WIP: máx. 3 por técnico) – VERIFICACIÓN: Usuario validando solución (WIP: máx. 5 globales) – DONE: Cerrada y documentada

2. Establecimiento de Límites WIP:

  • Cada técnico puede tener máximo 3 incidencias «En Curso» simultáneamente
  • Si ya tiene 3, debe terminar una antes de tomar otra
  • Esto reduce el multitasking y mejora la concentración

3. Clases de Servicio (Priorización):

Clase SLA Ejemplos
🚨 Crítica Respuesta: 15 min
Resolución: 4 horas		 Caída de Diraya en Hospital, error en receta electrónica
⚠️ Alta Respuesta: 1 hora
Resolución: 8 horas		 Usuario sin acceso a sistema crítico, fallo impresora quirófano
🟠 Media Respuesta: 4 horas
Resolución: 24 horas		 Lentitud en app móvil, problemas de rendimiento
🟢 Baja Respuesta: 8 horas
Resolución: 72 horas		 Consultas, peticiones de formación, mejoras estéticas

Resultados Tras 6 Meses de KANBAN:

  • ✅ Lead Time promedio: De 48 horas → 18 horas (reducción 62%)
  • ✅ Cycle Time promedio: De 32 horas → 12 horas
  • ✅ Throughput: De 150 incidencias/día → 220 incidencias/día (misma plantilla)
  • ✅ Satisfacción usuario: De 6.2/10 → 8.5/10
  • ✅ Reducción de incidencias reabiertas: De 15% → 6%

Factores de Éxito:

  • Límites WIP estrictos evitaron el multitasking excesivo
  • Visualización del flujo permitió detectar cuellos de botella rápidamente
  • Métricas (CFD, Lead Time) guiaron mejoras continuas
  • Clases de servicio aseguraron que las incidencias críticas tuvieran prioridad

6. LEAN Software Development 🎯

LEAN viene del Toyota Production System (manufactura de coches). Mary y Tom Poppendieck lo adaptaron al desarrollo de software en 2003.

La filosofía LEAN se resume en: «Maximizar el valor eliminando el desperdicio».

6.1. Los 7 Principios de LEAN Software Development

Principio 1: Eliminar el Desperdicio (Eliminate Waste)

Todo lo que no añade valor al cliente es desperdicio y debe eliminarse.

7 Tipos de Desperdicio en Software (Muda):

  1. Trabajo Parcialmente Hecho: Código no integrado, features no desplegadas
  2. Funcionalidades Extra: Desarrollar cosas «por si acaso» que el usuario no pidió (viola YAGNI)
  3. Re-aprendizaje: Falta de documentación que obliga a «redescubrir» decisiones
  4. Traspaso de Mano: Handoffs entre equipos separados (diseño → desarrollo → QA → ops)
  5. Retrasos: Esperas por aprobaciones, esperas por entornos, esperas por despliegues
  6. Multi-tarea: Cambiar constantemente de tarea (cada cambio tiene coste de contexto)
  7. Defectos: Bugs que requieren retrabajar código

En el SAS: Eliminar reuniones innecesarias, reducir documentación excesiva, automatizar despliegues para evitar esperas, integración continua para detectar defectos temprano.

Principio 2: Amplificar el Aprendizaje (Amplify Learning)

El desarrollo de software es un proceso de aprendizaje continuo. Maximiza las oportunidades de aprender.

Prácticas:

  • Prototipos rápidos y feedback temprano
  • Code reviews como oportunidad de aprendizaje
  • Pair programming
  • Retrospectivas para aprender de errores
  • Ciclos cortos de feedback (CI/CD)

En el SAS: Cuando se desarrolla una nueva funcionalidad de Diraya, primero se hace un prototipo (mockup) y se valida con médicos antes de programar. Eso es amplificar el aprendizaje.

Principio 3: Decidir lo Más Tarde Posible (Decide as Late as Possible)

Retrasar decisiones importantes hasta tener más información. Pero sin caer en parálisis por análisis.

Ejemplo: No decidas la arquitectura de base de datos al inicio del proyecto. Desarrolla la funcionalidad con una BD simple, y cuando tengas datos reales de uso, decides si necesitas NoSQL, sharding, etc.

En el SAS: No decidir upfront si la nueva app móvil será nativa o híbrida. Primero desarrolla un MVP con tecnología flexible, mide uso real, y entonces decides basándote en datos reales de rendimiento y adopción.

Principio 4: Entregar lo Más Rápido Posible (Deliver as Fast as Possible)

La velocidad de entrega es crítica. Cuanto antes entregas, antes obtienes feedback y puedes adaptarte.

Prácticas:

  • CI/CD para despliegues frecuentes
  • Automatización de testing
  • MVPs (Minimum Viable Products)
  • Feature toggles para activar/desactivar funcionalidades sin redesplegar

En el SAS: Despliegues semanales de Diraya en lugar de releases trimestrales. Pipelines CI/CD automatizados que permiten desplegar en 30 minutos en lugar de 3 días.

Principio 5: Empoderar al Equipo (Empower the Team)

Los equipos auto-organizados toman mejores decisiones que los managers externos. Confía en el equipo y dales autonomía.

En el SAS: El equipo de desarrollo de Diraya decide qué tecnologías usar (Spring Boot vs Jakarta EE), cómo estructurar el código, qué patrones de diseño aplicar. No hay un «arquitecto jefe» imponiéndolo.

Principio 6: Construir Integridad (Build Integrity In)

La calidad no se «añade» al final: se construye desde el principio.

Prácticas:

  • Test-Driven Development (TDD)
  • Integración continua
  • Refactoring continuo
  • Code reviews
  • Pair programming
  • Definición de «Done» estricta

En el SAS: Todo código nuevo en Diraya debe tener >80% cobertura de tests unitarios, pasar análisis estático (SonarQube), y ser revisado por otro desarrollador antes de merge.

Principio 7: Ver el Todo (See the Whole)

Optimizar el todo, no las partes. Una optimización local puede perjudicar al sistema completo.

Ejemplo: Optimizar el código de un microservicio para que sea super rápido, pero eso hace que genere tantas llamadas a la BD que colapsa el sistema completo. Optimización local → perjudicio global.

En el SAS: Pensar en Diraya no como «módulos independientes» sino como un ecosistema. Una mejora en el módulo de farmacia debe considerar el impacto en receta electrónica, en la historia clínica, en el sistema de facturación…

⚠️ IMPORTANTE PARA EL EXAMEN:

Pregunta típica: «¿Cuál de los siguientes NO es un principio fundamental del Lean Software Development?»

Trampa común: «Maximizar la documentación exhaustiva» → NO es un principio Lean (al contrario, Lean busca eliminar desperdicio, y documentación excesiva es desperdicio)

Los 7 principios sí son: Eliminar desperdicio, Amplificar aprendizaje, Decidir tarde, Entregar rápido, Empoderar equipo, Construir integridad, Ver el todo.

6.2. Value Stream Mapping (VSM)

Es una técnica LEAN para mapear el flujo de valor: desde que se pide una funcionalidad hasta que se entrega al usuario.

Value Stream Map – Nueva Funcionalidad en Diraya: [PETICIÓN] → [ANÁLISIS] → [DISEÑO] → [DEV] → [QA] → [DESPLIEGUE] → [USUARIO] (2 días) (3 días) (2 días) (5 días) (3 días) (1 día) ↓ ↓ ↓ ↓ ↓ Tiempo de Tiempo de trabajo: 16 días espera: 8 días Lead Time Total: 24 días Value-Added Time: 16 días (67%) Non-Value-Added Time: 8 días (33%) ← Objetivo: reducir esto Acciones de mejora: – Automatizar despliegues (reducir 1 día → 2 horas) – Integrar testing en desarrollo (reducir handoff QA) – Implementar CI/CD (reducir tiempo espera aprobaciones)

7. DevOps: Cultura de Colaboración 🔄

DevOps no es una metodología ni una herramienta: es una cultura. Es la unión de Development (Desarrollo) y Operations (Operaciones).

Históricamente, estos dos mundos estaban separados y en conflicto:

  • Developers: «Queremos desplegar funcionalidades nuevas rápido»
  • Operations: «Queremos estabilidad y disponibilidad, nada de cambios»

DevOps rompe ese muro y hace que ambos trabajen juntos con un objetivo común: entregar valor rápido Y de forma estable.

7.1. Los Tres Caminos de DevOps (The Three Ways)

Primer Camino: El Flujo (Flow)

Optimizar el flujo de trabajo desde desarrollo hasta producción, reduciendo tiempos de ciclo.

Prácticas:

  • CI/CD (Integración Continua / Despliegue Continuo)
  • Automatización de builds, tests, despliegues
  • Infraestructura como Código (IaC)
  • Contenedores (Docker, Kubernetes)

En el SAS: Pipeline CI/CD para Diraya donde cada commit al repositorio Git dispara automáticamente: build → tests unitarios → tests integración → despliegue a preproducción. Si todo OK, despliegue a producción con un click.

Segundo Camino: Feedback

Crear ciclos de feedback rápidos desde producción hacia desarrollo.

Prácticas:

  • Monitorización continua (Prometheus, Grafana, ELK Stack)
  • Logging centralizado
  • Alertas automáticas
  • A/B testing
  • Feature flags para experimentación

En el SAS: Dashboard de Grafana mostrando métricas en tiempo real de Diraya: tiempo de respuesta, errores, uso de CPU/memoria. Si el tiempo de respuesta sube >2 segundos, alerta automática al equipo DevOps.

Tercer Camino: Aprendizaje y Experimentación Continua

Fomentar una cultura de experimentación, aprendizaje de fallos, y mejora continua.

Prácticas:

  • Postmortems sin culpa (blameless postmortems)
  • Chaos Engineering (inyectar fallos controlados para probar resiliencia)
  • Game days (simulacros de desastres)
  • Time dedicado a mejora técnica (20% time)

En el SAS: Cuando cae un servidor de Diraya, se hace un postmortem donde NO se busca culpables sino causas raíz y mejoras. «¿Qué podemos automatizar para que esto no vuelva a pasar?»

7.2. Prácticas Clave de DevOps

7.2.1. Integración Continua (CI – Continuous Integration)

Los desarrolladores integran su código en el repositorio central múltiples veces al día. Cada integración dispara un build automatizado y tests.

Beneficios:

  • Detectar errores de integración temprano (no al final del Sprint)
  • Reducir conflictos de merge
  • Tener siempre una versión desplegable
Pipeline CI típico en el SAS: 1. Developer hace commit a Git 2. GitLab CI detecta el commit 3. Se ejecuta: – Build del código (Maven/Gradle) – Tests unitarios (JUnit) – Análisis estático código (SonarQube) – Tests de integración 4. Si todo OK → Deploy automático a DEV 5. Si algo falla → Notificación Slack al equipo

7.2.2. Despliegue Continuo (CD – Continuous Deployment)

Todo cambio que pasa los tests se despliega automáticamente a producción. Sin intervención manual.

Continuous Delivery vs Continuous Deployment:

  • Continuous Delivery: Los cambios están listos para producción, pero el despliegue requiere aprobación manual
  • Continuous Deployment: Todo cambio aprobado por tests se despliega automáticamente sin intervención humana

En el SAS: Por temas de seguridad y criticidad, Diraya usa Continuous Delivery (no Deployment). Los cambios llegan automáticamente a preproducción, pero el paso a producción requiere aprobación del responsable técnico y se hace en ventanas de mantenimiento.

7.2.3. Infraestructura como Código (IaC)

La infraestructura (servidores, redes, balanceadores…) se define en código y se versiona como cualquier otro código.

Herramientas: Terraform, Ansible, Puppet, Chef

Ejemplo Terraform – Crear servidor para Diraya: resource «aws_instance» «diraya_app_server» { ami = «ami-0c55b159cbfafe1f0» instance_type = «t3.xlarge» tags = { Name = «diraya-app-prod-01» Environment = «production» Criticality = «HIGH» Owner = «SAS-TIC» } monitoring = true security_groups = [«sg-diraya-app»] } # Este código se versiona en Git, se revisa, y se aplica automáticamente

Beneficios IaC en el SAS:

  • Reproducibilidad: Crear entornos idénticos (DEV, TEST, PROD) con un comando
  • Versionado: Si un cambio rompe algo, rollback al commit anterior
  • Documentación: La infraestructura está documentada en el código
  • Auditoría: Todo cambio de infraestructura queda registrado en Git

7.2.4. Monitorización y Observabilidad

No basta con desplegar rápido: hay que saber QUÉ está pasando en producción en tiempo real.

3 Pilares de la Observabilidad:

  1. Logs: Registros de eventos (ELK Stack: Elasticsearch, Logstash, Kibana)
  2. Métricas: Datos numéricos (Prometheus, Grafana)
  3. Traces: Seguimiento de requests (Jaeger, Zipkin)

En el SAS:

  • Logs: Todos los logs de Diraya (aplicación, BD, sistema operativo) centralizados en ELK Stack. Si un usuario reporta un error, el técnico busca en Kibana los logs de esa transacción.
  • Métricas: Grafana muestra dashboards con: usuarios conectados, tiempo respuesta promedio, requests/segundo, uso CPU/RAM/disco de cada servidor.
  • Traces: Si una consulta a Diraya tarda 5 segundos, el tracing muestra dónde se va el tiempo: 0.1s API Gateway, 0.2s aplicación, 4.5s base de datos, 0.2s respuesta. Ahí está el cuello de botella.

7.2.5. ChatOps

Ejecutar operaciones DevOps desde herramientas de chat (Slack, Microsoft Teams).

Ejemplo ChatOps en el SAS: Canal Slack #diraya-ops: @devopsbot status diraya-prod Bot: ✅ Diraya PROD – Todo OK – Servidores: 4/4 activos – Uptime: 99.98% (último mes) – Tiempo respuesta: 387ms (avg) – Usuarios activos: 2,347 @devopsbot deploy diraya v2.45.3 to staging Bot: 🚀 Desplegando Diraya v2.45.3 a STAGING… [==========> ] 60% Bot: ✅ Despliegue completado. Tests pasando. URL: https://diraya-staging.sspa.es @devopsbot rollback diraya prod Bot: ⚠️ Solicitando confirmación de rollback a v2.45.2 Responde «CONFIRMAR ROLLBACK» en los próximos 30s

7.3. DevOps en el SAS: Métricas y KPIs

Las 4 métricas clave de DevOps (según el libro «Accelerate»):

Métrica Qué Mide Objetivo SAS Situación Actual
Deployment Frequency Frecuencia de despliegues a producción Semanal Quincenal (mejorando)
Lead Time for Changes Tiempo desde commit hasta producción < 24 horas 72 horas
Mean Time to Restore (MTTR) Tiempo para recuperarse de un fallo < 1 hora 2-3 horas
Change Failure Rate % de despliegues que causan fallos < 5% 8% (mejorando)

Estas métricas clasifican a las organizaciones en:

  • Elite Performers: Despliegues bajo demanda, Lead Time <1 hora, MTTR <1 hora, Change Failure Rate <5%
  • High Performers: Despliegues diarios/semanales
  • Medium Performers: Despliegues mensuales
  • Low Performers: Despliegues semestrales/anuales

El SAS está en proceso de transición de Medium a High Performer.

⚠️ IMPORTANTE PARA EL EXAMEN:

Pregunta típica: «En relación a DevOps, indique cuál de las siguientes afirmaciones es correcta:»

  • ✅ «Los equipos lanzan versiones de software en ciclos cortos» (CORRECTO)
  • ❌ «Están perfectamente separados los procesos de desarrollo y de operaciones» (FALSO – DevOps los UNE)
  • ❌ «En el proceso de entrega de software se evita el uso de automatización» (FALSO – DevOps depende de automatización)
  • ❌ «Cada equipo trabaja internamente sin compartir ni dar visibilidad» (FALSO – DevOps requiere transparencia y colaboración)

8. DevSecOps: Seguridad Integrada 🔒

DevSecOps es la evolución natural de DevOps: integrar la seguridad desde el inicio del ciclo de desarrollo, no como un «checkpoint» al final.

El término viene de: Development + Security + Operations

8.1. ¿Por Qué DevSecOps es Crítico en el SAS?

El SAS gestiona datos de categoría especial según el RGPD: datos de salud. Las consecuencias de una brecha de seguridad son graves:

  • Legales: Sanciones de hasta 20 millones € o 4% de la facturación global (RGPD)
  • Reputacionales: Pérdida de confianza de pacientes y profesionales
  • Asistenciales: Si un ransomware bloquea Diraya, se paraliza la atención sanitaria
  • Normativas: Incumplimiento del ENS-MEDIO (obligatorio para el SAS)

Por eso la seguridad NO puede ser un afterthought. Debe estar integrada desde el minuto 1.

8.2. Shift-Left Security

El concepto clave de DevSecOps es «Shift-Left»: mover la seguridad hacia la izquierda del ciclo de desarrollo (hacia el inicio).

Modelo Tradicional (Security at the End): [DISEÑO] → [DEV] → [QA] → [SECURITY AUDIT] → [PRODUCCIÓN] ↑ AQUÍ se detectan vulnerabilidades (caro y lento arreglarlas) Modelo DevSecOps (Shift-Left): [DISEÑO SEGURO] → [DEV + Tests Sec] → [QA + Pentesting] → [PRODUCCIÓN + Monitoreo] ↑ ↑ ↑ ↑ Threat SAST/DAST Pentesting WAF + IDS/IPS Modeling Dependency automatizado + Monitoreo Checks

8.3. Prácticas de DevSecOps

8.3.1. Threat Modeling (Modelado de Amenazas)

En la fase de diseño, identificar amenazas potenciales y diseñar controles.

Metodología STRIDE (Microsoft):

  • Spoofing (Suplantación)
  • Tampering (Manipulación)
  • Repudiation (Repudio)
  • Information Disclosure (Divulgación de información)
  • Denial of Service (Denegación de servicio)
  • Elevation of Privilege (Elevación de privilegios)

Ejemplo en el SAS: Al diseñar el módulo de receta electrónica, se hace threat modeling identificando:

  • Amenaza: Médico suplantado prescribe medicación peligrosa (Spoofing)
  • Control: Autenticación multifactor + certificado digital
  • Amenaza: Modificación de dosis en tránsito (Tampering)
  • Control: Firma digital de la receta + HTTPS con TLS 1.3

8.3.2. Secure Coding Standards

Estándares de codificación segura que el equipo sigue:

  • OWASP Top 10: Las 10 vulnerabilidades web más críticas
  • SANS Top 25: Los 25 errores de software más peligrosos
  • CWE (Common Weakness Enumeration): Catálogo de debilidades de software
Ejemplo de Inseguro vs Seguro – Diraya: ❌ INSEGURO (SQL Injection): String query = «SELECT * FROM pacientes WHERE dni = ‘» + userInput + «‘»; // Si userInput = «‘ OR ‘1’=’1» → devuelve TODOS los pacientes ✅ SEGURO (Prepared Statements): PreparedStatement stmt = conn.prepareStatement( «SELECT * FROM pacientes WHERE dni = ?» ); stmt.setString(1, userInput); // Escapea automáticamente, previene SQL Injection

8.3.3. SAST (Static Application Security Testing)

Análisis estático del código para detectar vulnerabilidades sin ejecutarlo.

Herramientas: SonarQube, Checkmarx, Fortify, Veracode

En el SAS: Cada commit a Diraya pasa por SonarQube que busca:

  • SQL Injections
  • XSS (Cross-Site Scripting)
  • Hard-coded passwords
  • Uso de algoritmos criptográficos débiles (MD5, SHA1)
  • Path Traversal
  • Deserialización insegura

Si SonarQube detecta una vulnerabilidad CRÍTICA, el build falla automáticamente.

8.3.4. DAST (Dynamic Application Security Testing)

Análisis dinámico: probar la aplicación en ejecución simulando ataques.

Herramientas: OWASP ZAP, Burp Suite, Acunetix

En el SAS: Cada viernes por la noche, OWASP ZAP escanea automáticamente la versión de Diraya en preproducción, simulando ataques típicos (SQL injection, XSS, CSRF…). El lunes por la mañana, el equipo revisa el informe y prioriza fixes.

8.3.5. Dependency Scanning

Escanear dependencias (librerías de terceros) en busca de vulnerabilidades conocidas.

Herramientas: OWASP Dependency-Check, Snyk, WhiteSource

Ejemplo Real – Log4Shell (CVE-2021-44228): Diciembre 2021: Se descubre vulnerabilidad crítica en Log4j 2.x (librería de logging muy usada en Java) SAS Response con DevSecOps: 1. Dependency-Check detecta Log4j vulnerable en Diraya 2. Alerta automática al equipo 3. Se actualiza Log4j 2.15 → 2.17.1 (parcheado) 4. Tests automáticos verifican que nada se rompe 5. Deploy urgente a producción en 48 horas Sin DevSecOps: Hubiéramos tardado semanas en identificar qué sistemas usaban Log4j vulnerable

8.3.6. Container Security

Si usas Docker/Kubernetes, escanear imágenes de contenedores.

Herramientas: Trivy, Clair, Anchore

En el SAS: Antes de subir una imagen Docker de Diraya al registro, Trivy la escanea buscando:

  • Vulnerabilidades en el sistema operativo base (Alpine Linux, Ubuntu…)
  • Vulnerabilidades en las librerías incluidas
  • Secretos hard-coded en la imagen
  • Configuraciones inseguras

8.3.7. Secrets Management

NUNCA hard-codear contraseñas, API keys, certificados en el código.

Herramientas: HashiCorp Vault, AWS Secrets Manager, Azure Key Vault

❌ INSEGURO: // Directo en el código (NUNCA hagas esto) String dbPassword = «P@ssw0rd123»; connection.connect(dbUrl, dbUser, dbPassword); ✅ SEGURO: // Recuperar del gestor de secretos en runtime String dbPassword = vaultClient.getSecret(«diraya/db/password»); connection.connect(dbUrl, dbUser, dbPassword); // El secreto nunca está en el código ni en Git

8.3.8. Infrastructure Security (ENS Compliance)

En el SAS, cumplir el Esquema Nacional de Seguridad (ENS) es obligatorio. DevSecOps ayuda a automatizar controles ENS:

Control ENS Automatización DevSecOps
mp.si.2: Gestión de configuraciones seguras IaC (Terraform/Ansible) con configuraciones auditadas
op.exp.8: Registro de la actividad Logging centralizado (ELK Stack) + retención 2 años
op.exp.10: Protección de claves criptográficas HashiCorp Vault + HSM para claves críticas
op.acc.5: Mecanismo de autenticación OAuth 2.0 + OpenID Connect + MFA
mp.per.4: Gestión de vulnerabilidades SAST/DAST/Dependency Scanning en CI/CD

8.4. Pipeline DevSecOps Completo en el SAS

Pipeline DevSecOps – Diraya (GitLab CI/CD): ┌─────────────────────────────────────────────────────────────────┐ │ 1. COMMIT CODE (Git) │ └─────────────────────────────────────────────────────────────────┘ ↓ ┌─────────────────────────────────────────────────────────────────┐ │ 2. PRE-COMMIT HOOKS │ │ – Secreto escaneado (TruffleHog) │ │ – Linting código (ESLint, Checkstyle) │ └─────────────────────────────────────────────────────────────────┘ ↓ ┌─────────────────────────────────────────────────────────────────┐ │ 3. BUILD & UNIT TESTS │ │ – Maven build │ │ – JUnit tests (>80% coverage requerido) │ └─────────────────────────────────────────────────────────────────┘ ↓ ┌─────────────────────────────────────────────────────────────────┐ │ 4. SAST (SonarQube) │ │ – Análisis estático de seguridad │ │ – Quality Gate: 0 vulnerabilidades CRÍTICAS │ └─────────────────────────────────────────────────────────────────┘ ↓ ┌─────────────────────────────────────────────────────────────────┐ │ 5. DEPENDENCY CHECK (OWASP Dependency-Check) │ │ – Escaneo de librerías vulnerables (CVEs) │ └─────────────────────────────────────────────────────────────────┘ ↓ ┌─────────────────────────────────────────────────────────────────┐ │ 6. CONTAINER IMAGE BUILD │ │ – Docker build │ │ – Trivy scan de la imagen │ │ – Push a registro solo si pasa scan │ └─────────────────────────────────────────────────────────────────┘ ↓ ┌─────────────────────────────────────────────────────────────────┐ │ 7. DEPLOY TO STAGING │ │ – Deploy automático a entorno staging │ │ – IaC aplicado (Terraform) │ └─────────────────────────────────────────────────────────────────┘ ↓ ┌─────────────────────────────────────────────────────────────────┐ │ 8. INTEGRATION & E2E TESTS │ │ – Tests de integración (Selenium, Cypress) │ │ – Tests E2E de flujos críticos │ └─────────────────────────────────────────────────────────────────┘ ↓ ┌─────────────────────────────────────────────────────────────────┐ │ 9. DAST (OWASP ZAP) │ │ – Pentesting automatizado │ │ – Simulación de ataques (SQLi, XSS, CSRF…) │ └─────────────────────────────────────────────────────────────────┘ ↓ ┌─────────────────────────────────────────────────────────────────┐ │ 10. MANUAL APPROVAL (Responsible Sign-Off) │ │ – Revisión de resultados por Responsable TIC │ │ – Aprobación para producción │ └─────────────────────────────────────────────────────────────────┘ ↓ ┌─────────────────────────────────────────────────────────────────┐ │ 11. DEPLOY TO PRODUCTION │ │ – Blue-Green deployment (zero downtime) │ │ – Rollback automático si health checks fallan │ └─────────────────────────────────────────────────────────────────┘ ↓ ┌─────────────────────────────────────────────────────────────────┐ │ 12. MONITORING & ALERTING │ │ – Prometheus + Grafana (métricas) │ │ – ELK Stack (logs) │ │ – WAF (ModSecurity) + IDS/IPS │ └─────────────────────────────────────────────────────────────────┘ TODO AUTOMATIZADO. Desde commit hasta producción: 45 minutos.
✅ Beneficios DevSecOps en el SAS:
  • Detección temprana de vulnerabilidades (costo de fix 10x menor que en producción)
  • Cumplimiento ENS automatizado y auditable
  • Reducción de superficie de ataque (dependency updates automáticos)
  • Respuesta rápida a vulnerabilidades 0-day (Log4Shell: fix en 48h vs semanas)
  • Cultura de seguridad compartida (no solo el equipo de seguridad, todo el equipo)

9. Casos Prácticos en el Servicio Andaluz de Salud 🏥

📋 Caso Práctico 3: Transformación Ágil del Desarrollo de Apps Móviles SAS

Situación Inicial (2019):

  • ClicSalud+ (app para pacientes) desarrollada con Waterfall
  • Releases anuales (1 gran release al año)
  • Equipo externo (outsourcing) con poca comunicación
  • Feedback de usuarios llegaba tarde y no se incorporaba
  • Bugs en producción tardaban meses en corregirse
  • Nuevas funcionalidades tardaban 6-12 meses desde idea hasta producción

Puntos de Dolor:

  • Durante COVID (marzo 2020), se necesitaba URGENTE añadir telemedicina y autocita. No era posible con releases anuales.
  • Los pacientes se quejaban de bugs que tardaban meses en arreglarse
  • Las stores (App Store, Google Play) exigen actualizaciones frecuentes o la app baja en rankings

Transformación (2020-2021):

1. Creación de Equipo Interno Scrum:

  • Product Owner: Responsable de Sistemas de Información Ciudadana del SAS
  • Scrum Master: Técnico Especialista formado como PSM I
  • Development Team: 2 dev iOS (Swift), 2 dev Android (Kotlin), 1 backend (Node.js), 1 QA, 1 UX/UI designer
  • Duración Sprint: 2 semanas

2. Implementación de Prácticas Ágiles:

  • Product Backlog: Historias de usuario priorizadas por valor + urgencia
  • Sprint Planning: Cada 2 semanas, selección de historias para el Sprint
  • Daily Standup: Cada mañana 9:00 AM, 15 minutos
  • Sprint Review: Demo al final del Sprint con usuarios reales (pacientes y profesionales sanitarios)
  • Sprint Retrospective: Mejora continua del proceso

3. Implementación de DevOps:

  • CI/CD: GitLab CI con pipelines automatizados
  • Testing: Tests unitarios (Jest), tests UI (Appium), tests E2E
  • Despliegue: Beta Testing con 500 usuarios voluntarios antes de release público
  • Monitorización: Firebase Analytics + Crashlytics para detectar problemas en tiempo real

4. Integración DevSecOps:

  • SAST en cada commit (SonarQube)
  • Dependency scanning (librerías vulnerables)
  • DAST pre-release (OWASP ZAP contra el backend)
  • Cumplimiento ENS automatizado

Resultados (2022):

Métrica Antes (2019) Después (2022) Mejora
Frecuencia Releases 1 al año 26 al año (cada 2 semanas) 2600%
Lead Time (idea → producción) 6-12 meses 2-4 semanas -92%
Tiempo Fix Bug Crítico 2-3 meses 2-3 días -98%
Satisfacción Usuario (stores) 3.2/5.0 4.5/5.0 +41%
Usuarios Activos Mensuales 450,000 1,200,000 +167%
Vulnerabilidades en Producción 12 (año 2019) 1 (año 2022) -92%

Lecciones Aprendidas:

  • La colaboración con usuarios reales en Sprint Reviews fue CRÍTICA para el éxito
  • DevSecOps evitó vulnerabilidades graves (un SAST detectó una SQL injection antes de producción)
  • La automatización de tests redujo regresiones (bugs que reaparecían)
  • El equipo interno (vs outsourcing) mejoró muchísimo la calidad y velocidad
📋 Caso Práctico 4: Kanban en ayudaDIGITAL – Service Desk del SAS

Contexto: ayudaDIGITAL es el Service Desk del SAS que da soporte a los 100,000+ profesionales sanitarios y administrativos en temas TIC.

Volumen de Trabajo:

  • ~200 incidencias diarias
  • ~50 peticiones de servicio diarias (solicitudes de accesos, altas de usuarios, etc.)
  • ~30 consultas diarias

Problema (2020):

  • Los técnicos tenían asignadas 15-20 incidencias simultáneamente
  • Mucho «context switching» (cambiar de tarea constantemente)
  • Incidencias atascadas en «En Progreso» durante semanas
  • No había visibilidad de cuellos de botella
  • SLAs incumplidos frecuentemente

Solución: Implementación de KANBAN (2021):

1. Diseño del Tablero Kanban (Jira):

Columnas del Tablero: BACKLOG → TRIAJE → PENDIENTE → EN CURSO → VERIFICACIÓN → CERRADA (WIP:10) (WIP:20) (WIP:15) (WIP:5) Swimlanes (carriles) por prioridad: 🚨 CRÍTICA (SLA: 4h) ⚠️ ALTA (SLA: 8h) 🟠 MEDIA (SLA: 24h) 🟢 BAJA (SLA: 72h)

2. Límites WIP:

  • Triaje: Máximo 10 incidencias en triaje simultáneamente (si se llena, se para el intake hasta despejar)
  • Pendiente Asignación: Máximo 20 incidencias listas para trabajar
  • En Curso: Máximo 15 globales (5 técnicos × 3 incidencias/técnico)
  • Verificación: Máximo 5 pendientes de validación usuario

3. Políticas Explícitas:

Definition of Ready (DoR) – Pasar de PENDIENTE a EN CURSO: ✅ Categorizada (Incidencia/Petición/Consulta) ✅ Priorizada según SLA ✅ Asignada a técnico con capacidad (WIP no alcanzado) ✅ Información completa del usuario (descripción, screenshots, logs) Definition of Done (DoD) – Pasar de EN CURSO a VERIFICACIÓN: ✅ Solución implementada y testada ✅ Documentación actualizada en Base de Conocimiento ✅ Usuario notificado de la solución ✅ CMDB actualizada si procede (cambios de configuración) Definition of Done – Pasar de VERIFICACIÓN a CERRADA: ✅ Usuario confirma que el problema está resuelto ✅ Encuesta de satisfacción completada ✅ Métricas registradas (Lead Time, Cycle Time)

4. Métricas:

  • Lead Time: Desde que se reporta hasta que se cierra (objetivo: <24h para MEDIA)
  • Cycle Time: Desde que se empieza a trabajar hasta que se cierra
  • Throughput: Incidencias cerradas por día (objetivo: >200/día)
  • CFD: Diagrama de flujo acumulativo para detectar cuellos de botella
  • SLA Compliance: % de incidencias resueltas dentro del SLA

5. Cadencias (Reuniones):

  • Daily Standup: 15 min cada mañana frente al tablero Kanban
    • ¿Hay incidencias bloqueadas?
    • ¿Se están cumpliendo los límites WIP?
    • ¿Hay cuellos de botella visibles?
  • Revisión de Métricas: Semanal (viernes tarde)
    • Revisar CFD: ¿hay cuellos de botella?
    • Lead Time promedio por prioridad
    • SLA compliance
    • Identificar mejoras
  • Kaizen (Mejora Continua): Mensual
    • ¿Qué experimentos hacer este mes?
    • Ej: «Vamos a probar aumentar el límite WIP de TRIAJE de 10 a 12 y ver si mejora el throughput sin perjudicar la calidad»

Resultados Tras 12 Meses de KANBAN:

Métrica Antes Kanban Después Kanban Mejora
Lead Time Promedio 48 horas 18 horas -62%
Cycle Time Promedio 32 horas 12 horas -62%
Throughput 150 incidencias/día 220 incidencias/día +47%
SLA Compliance 72% 94% +22 pp
Satisfacción Usuario 6.2/10 8.5/10 +37%
Incidencias Reabiertas 15% 6% -60%

Factores Clave de Éxito:

  1. Límites WIP: Forzaron al equipo a terminar antes de empezar cosas nuevas
  2. Visualización: El tablero Kanban hizo visible dónde estaban atascadas las incidencias
  3. Políticas Explícitas: Eliminaron ambigüedades sobre cuándo una incidencia estaba «hecha»
  4. Métricas: Lead Time, Cycle Time y CFD guiaron mejoras continuas basadas en datos
  5. Clases de Servicio: Aseguraron que las incidencias críticas tuvieran prioridad real

10. Cuestionario de Autoevaluación 📝

30 preguntas tipo test basadas en exámenes reales del SAS y el contenido del tema. Nivel de dificultad: OPOSICIÓN.

Pregunta 1
¿Cuál de los siguientes NO es un valor del Manifiesto Ágil?
A) Individuos e interacciones sobre procesos y herramientas
B) Software funcionando sobre documentación exhaustiva
C) Colaboración con el cliente sobre negociación contractual
D) Planificación completa sobre respuesta ante el cambio
✅ Respuesta Correcta: D
Explicación: El cuarto valor del Manifiesto Ágil es «Respuesta ante el cambio sobre seguir un plan», NO «Planificación completa sobre respuesta ante el cambio». La opción D invierte el valor correcto. Las opciones A, B y C son los tres primeros valores del Manifiesto Ágil formulados correctamente.
Pregunta 2
¿Cuántos principios tiene el Manifiesto por el Desarrollo Ágil de Software?
A) 4 principios
B) 10 principios
C) 12 principios
D) 15 principios
✅ Respuesta Correcta: C
Explicación: El Manifiesto Ágil establece 4 valores y 12 principios. Esta es una pregunta de memorización directa que ha aparecido en exámenes del SAS. No confundir con los 4 valores.
Pregunta 3
En SCRUM, ¿cómo se llama al resultado de un Sprint?
A) Incremento
B) Producto
C) Sprint Backlog
D) Pila del Sprint
✅ Respuesta Correcta: A
Explicación: El resultado de un Sprint en SCRUM es un Incremento: la suma de todos los Product Backlog Items completados durante el Sprint y todos los Sprints anteriores. El Sprint Backlog (opción C) es el plan de trabajo, no el resultado. Esta pregunta es MUY frecuente en exámenes SAS.
Pregunta 4
En SCRUM, durante el Sprint…
A) No se realizan cambios que puedan afectar al objetivo del Sprint
B) Se pueden realizar todos los cambios que solicite el cliente
C) El Product Owner puede cambiar completamente las prioridades
D) El Sprint Backlog se resetea cada semana
✅ Respuesta Correcta: A
Explicación: Uno de los principios clave de SCRUM es que durante el Sprint NO se hacen cambios que pongan en peligro el Sprint Goal (objetivo del Sprint). El alcance puede clarificarse y renegociarse entre el PO y el Dev Team, pero no cambios que amenacen el objetivo. Esta es una regla fundamental de SCRUM que protege al equipo de interrupciones constantes.
Pregunta 5
¿Qué ocurre en la Sprint Review?
A) El equipo analiza su desempeño y propone mejoras en su proceso de trabajo
B) Se presenta el incremento del producto terminado y se obtiene retroalimentación de los interesados
C) Se planifica en detalle cada tarea a realizar en los próximos meses
D) Se asignan roles y responsabilidades fijas para todos los miembros del equipo
✅ Respuesta Correcta: B
Explicación: En la Sprint Review se presenta el Incremento (el trabajo completado) a los stakeholders y se obtiene feedback. La opción A describe la Sprint Retrospective (no la Review). Esta diferencia es CRÍTICA y aparece frecuentemente en exámenes. Review = sobre el PRODUCTO. Retrospective = sobre el PROCESO.
Pregunta 6
Los elementos del Product Backlog seleccionados para el Sprint, más el plan para terminarlos, recibe el nombre de…
A) Incremento
B) Product Backlog
C) Sprint Backlog
D) Definition of Done
✅ Respuesta Correcta: C
Explicación: El Sprint Backlog es el conjunto de elementos del Product Backlog seleccionados para el Sprint + el plan para entregarlos. Se crea en la Sprint Planning y es propiedad del Development Team. Esta es terminología oficial de SCRUM que debes dominar.
Pregunta 7
Indique cuál de las siguientes afirmaciones NO es correcta en relación a los métodos de desarrollo ágil:
A) En SCRUM durante el Sprint no se realizan cambios que puedan afectar al objetivo del Sprint
B) El tiempo que se tarda en terminar cada tarea se mide como lead time y cuenta desde que se hace una petición hasta que se hace la entrega
C) Los 12 principios del desarrollo ágil incluyen: «El software que funciona es la principal medida del progreso»
D) El diagrama de Gantt es uno de los elementos fundamentales de un tablero de Kanban
✅ Respuesta Correcta: D
Explicación: El diagrama de Gantt NO es un elemento de Kanban. Gantt es una herramienta de gestión tradicional (Waterfall). En Kanban se usa el Diagrama de Flujo Acumulativo (CFD – Cumulative Flow Diagram) para visualizar el flujo. Esta pregunta ha salido textualmente en exámenes del SAS 2025.
Pregunta 8
¿Qué tipo de diagrama se utiliza comúnmente en Kanban para visualizar el flujo de trabajo y el tiempo de ciclo?
A) Diagrama de Gantt
B) Diagrama de Flujo Acumulativo (CFD)
C) Diagrama de casos de uso
D) Diagrama de clases
✅ Respuesta Correcta: B
Explicación: El Diagrama de Flujo Acumulativo (Cumulative Flow Diagram – CFD) es el diagrama característico de Kanban. Muestra cómo fluyen las tareas a través de los diferentes estados a lo largo del tiempo, permitiendo identificar cuellos de botella. Pregunta directa de examen SAS 2025.
Pregunta 9
En relación a DevOps, indique cuál de las siguientes afirmaciones es correcta:
A) Los equipos lanzan versiones de software en ciclos cortos
B) Cada equipo trabaja internamente sus procesos sin necesidad de compartir ni dar visibilidad
C) Están perfectamente separados los procesos de desarrollo y de operaciones
D) En el proceso de entrega de software se evita el uso de automatización para garantizar la calidad del desarrollo
✅ Respuesta Correcta: A
Explicación: La opción A es correcta: DevOps promueve ciclos cortos de entrega (CI/CD). La B es falsa (DevOps requiere colaboración y transparencia). La C es falsa (DevOps UNE desarrollo y operaciones, no los separa). La D es falsa (DevOps depende crucialmente de la automatización). Pregunta textual de examen SAS 2025.
Pregunta 10
¿Cuál de los siguientes NO es un principio fundamental del Lean Software Development?
A) Eliminar el desperdicio
B) Amplificar el aprendizaje
C) Decidir lo más tarde posible
D) Maximizar la documentación exhaustiva
✅ Respuesta Correcta: D
Explicación: «Maximizar la documentación exhaustiva» NO es un principio Lean. Al contrario, Lean busca eliminar el desperdicio, y la documentación excesiva se considera desperdicio (muda). Los 7 principios Lean son: Eliminar desperdicio, Amplificar aprendizaje, Decidir tarde, Entregar rápido, Empoderar equipo, Construir integridad, Ver el todo. Pregunta directa examen SAS 2025.
Pregunta 11
¿Cuál de las siguientes afirmaciones sobre el Manifiesto Ágil es CORRECTA?
A) El método más eficiente y efectivo de comunicar información es el intercambio de documentos formales firmados
B) Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor
C) Los requisitos deben estar completamente definidos antes de iniciar el desarrollo
D) La documentación exhaustiva es más importante que el software funcionando
✅ Respuesta Correcta: B
Explicación: La opción B es textualmente el Principio #1 del Manifiesto Ágil. La opción A es falsa (el principio #6 dice que la conversación cara a cara es más efectiva). La C es falsa (en Agile los requisitos pueden cambiar). La D invierte el valor #2 del Manifiesto. Pregunta aparecida en examen SAS 2023.
Pregunta 12
¿Cuál es la duración máxima recomendada para la Daily Scrum?
A) 30 minutos
B) 15 minutos
C) 1 hora
D) No tiene duración fija
✅ Respuesta Correcta: B
Explicación: La Daily Scrum tiene un time-box estricto de 15 minutos. Es una de las reglas fundamentales de SCRUM. Si se alarga más, pierde efectividad y se convierte en una reunión de reporting en lugar de sincronización del equipo.
Pregunta 13
En SCRUM, ¿quién es el responsable de maximizar el valor del producto?
A) El Scrum Master
B) El Development Team
C) El Product Owner
D) Todo el Scrum Team por igual
✅ Respuesta Correcta: C
Explicación: El Product Owner es el responsable de maximizar el valor del producto. Es quien decide QUÉ se construye y en qué ORDEN, gestionando y priorizando el Product Backlog. El Scrum Master facilita el proceso, y el Dev Team construye el producto, pero la responsabilidad de maximizar valor es del PO.
Pregunta 14
¿Qué mide el «Lead Time» en Kanban?
A) El tiempo que un técnico dedica activamente a trabajar en una tarea
B) El tiempo total desde que se hace una petición hasta que se entrega
C) El número de tareas completadas por día
D) El tiempo de espera entre tareas
✅ Respuesta Correcta: B
Explicación: Lead Time es el tiempo total desde que se hace una petición hasta que se entrega (desde la perspectiva del cliente). La opción A describe el Cycle Time. La C describe el Throughput. Esta distinción es importante en Kanban y ha aparecido en exámenes SAS.
Pregunta 15
En el contexto de DevOps, ¿qué significa CI/CD?
A) Configuration Integration / Code Deployment
B) Continuous Integration / Continuous Delivery
C) Code Inspection / Central Database
D) Container Infrastructure / Cloud Development
✅ Respuesta Correcta: B
Explicación: CI/CD significa Continuous Integration (Integración Continua) / Continuous Delivery (Entrega Continua). Son prácticas fundamentales de DevOps que permiten integrar código frecuentemente y tenerlo siempre listo para desplegar a producción. Algunos usan CD como Continuous Deployment (despliegue automático sin intervención humana).
Pregunta 16
¿Cuál de las siguientes es una diferencia clave entre SCRUM y KANBAN?
A) SCRUM usa iteraciones de tiempo fijo (Sprints), KANBAN usa flujo continuo
B) SCRUM no permite cambios, KANBAN sí
C) SCRUM es para desarrollo, KANBAN solo para operaciones
D) SCRUM requiere automatización, KANBAN no
✅ Respuesta Correcta: A
Explicación: La diferencia clave es que SCRUM trabaja en iteraciones de tiempo fijo (Sprints de 1-4 semanas), mientras que KANBAN usa flujo continuo (no hay sprints). La B es falsa (ambos permiten cambios, pero de forma diferente). La C es falsa (ambos pueden usarse para desarrollo). La D es falsa (ninguno requiere automatización obligatoriamente).
Pregunta 17
¿Qué es WIP (Work In Progress) en el contexto de KANBAN?
A) El número total de tareas en el backlog
B) El límite máximo de tareas que pueden estar simultáneamente en una columna/estado
C) El tiempo promedio para completar una tarea
D) El número de tareas completadas por día
✅ Respuesta Correcta: B
Explicación: WIP (Work In Progress) es el límite máximo de tareas que pueden estar simultáneamente en un estado/columna del tablero Kanban. Limitar el WIP es uno de los principios clave de Kanban: previene sobrecarga, reduce multitasking y mejora el flujo. Por ejemplo: «En Curso: WIP=3» significa máximo 3 tareas en ese estado.
Pregunta 18
En DevSecOps, ¿qué significa «Shift-Left Security»?
A) Mover la seguridad al final del ciclo de desarrollo
B) Integrar la seguridad desde el inicio del ciclo de desarrollo
C) Separar el equipo de seguridad del equipo de desarrollo
D) Hacer auditorías de seguridad solo antes de producción
✅ Respuesta Correcta: B
Explicación: «Shift-Left» significa mover la seguridad hacia la izquierda del ciclo de desarrollo (hacia el inicio). En lugar de auditar seguridad solo al final, se integra desde el diseño: threat modeling, secure coding, SAST en cada commit, etc. Es el concepto fundamental de DevSecOps y muy relevante para el SAS por el ENS y RGPD.
Pregunta 19
¿Qué herramienta se usa típicamente para SAST (Static Application Security Testing)?
A) Jenkins
B) Docker
C) SonarQube
D) Kubernetes
✅ Respuesta Correcta: C
Explicación: SonarQube es una herramienta de SAST que analiza el código estáticamente (sin ejecutarlo) para detectar vulnerabilidades, code smells, bugs, etc. Jenkins es una herramienta de CI/CD, Docker es para contenedores, y Kubernetes para orquestación de contenedores. En el SAS, SonarQube se usa en los pipelines CI/CD de Diraya.
Pregunta 20
¿Cuál de los siguientes es uno de los «Tres Caminos» (Three Ways) de DevOps?
A) Planificación, Ejecución, Control
B) Flujo, Feedback, Aprendizaje Continuo
C) Desarrollo, Testing, Producción
D) Requisitos, Diseño, Implementación
✅ Respuesta Correcta: B
Explicación: Los Three Ways of DevOps son: 1) Flow (optimizar el flujo de trabajo), 2) Feedback (ciclos rápidos de feedback), 3) Continuous Learning & Experimentation (aprendizaje y experimentación continua). Este concepto viene del libro «The Phoenix Project» y es fundamental en la filosofía DevOps.
Pregunta 21
En SCRUM, ¿cuál es el tamaño recomendado del Development Team?
A) 1-3 personas
B) 3-9 personas
C) 10-15 personas
D) No hay tamaño recomendado
✅ Respuesta Correcta: B
Explicación: El tamaño recomendado del Development Team en SCRUM es 3-9 personas. Menos de 3 no hay masa crítica de habilidades. Más de 9 la coordinación se vuelve compleja (demasiadas interacciones). Este rango está definido en la Guía Oficial de SCRUM.
Pregunta 22
¿Qué es IaC (Infrastructure as Code) en el contexto de DevOps?
A) Escribir código de infraestructura en lenguajes de programación tradicionales
B) Definir y versionar la infraestructura mediante código, de forma automatizable
C) Documentar la infraestructura en archivos de texto
D) Crear interfaces de código para gestionar servidores manualmente
✅ Respuesta Correcta: B
Explicación: Infrastructure as Code (IaC) es la práctica de definir la infraestructura (servidores, redes, bases de datos…) mediante código que se versiona en Git y se aplica automáticamente. Herramientas: Terraform, Ansible, Puppet. Beneficios: reproducibilidad, versionado, auditoría. Muy relevante en el SAS para gestión de infraestructura de Diraya.
Pregunta 23
¿Cuál de los siguientes NO es un pilar de SCRUM?
A) Transparencia
B) Inspección
C) Adaptación
D) Planificación
✅ Respuesta Correcta: D
Explicación: Los tres pilares de SCRUM son: Transparencia, Inspección y Adaptación. «Planificación» no es un pilar de SCRUM, aunque sí es una actividad importante (Sprint Planning). Estos tres pilares son la base conceptual sobre la que se construye todo SCRUM.
Pregunta 24
En Lean Software Development, ¿qué significa «Muda»?
A) Mejora continua
B) Desperdicio
C) Valor para el cliente
D) Flujo de trabajo
✅ Respuesta Correcta: B
Explicación: «Muda» es el término japonés para desperdicio. En Lean se identifican 7 tipos de muda en desarrollo de software: trabajo parcialmente hecho, funcionalidades extra, re-aprendizaje, traspasos, retrasos, multi-tarea, y defectos. Eliminar muda es el primer principio Lean.
Pregunta 25
¿Qué práctica de DevOps permite ejecutar operaciones desde herramientas de chat como Slack?
A) GitOps
B) ChatOps
C) AIOps
D) SecOps
✅ Respuesta Correcta: B
Explicación: ChatOps es la práctica de ejecutar operaciones DevOps desde herramientas de chat (Slack, Microsoft Teams) mediante bots. Por ejemplo: «@bot deploy app v2.3 to staging». Mejora la transparencia (todos ven qué operaciones se hacen) y la velocidad de respuesta.
Pregunta 26
¿Cuál es la métrica de DevOps que mide el tiempo para recuperarse de un fallo en producción?
A) Lead Time for Changes
B) Deployment Frequency
C) Mean Time to Restore (MTTR)
D) Change Failure Rate
✅ Respuesta Correcta: C
Explicación: MTTR (Mean Time to Restore) mide el tiempo promedio para recuperarse de un fallo en producción. Es una de las 4 métricas clave de DevOps según «Accelerate». Las organizaciones de élite tienen MTTR <1 hora. En el SAS, el objetivo es <1 hora para sistemas críticos como Diraya.
Pregunta 27
En SCRUM, ¿cuándo se puede cancelar un Sprint?
A) Cuando el Development Team decide que no puede completar el trabajo
B) Cuando el Scrum Master detecta problemas en el proceso
C) Solo el Product Owner puede cancelar un Sprint, cuando el Sprint Goal queda obsoleto
D) Los Sprints nunca pueden cancelarse
✅ Respuesta Correcta: C
Explicación: Solo el Product Owner tiene autoridad para cancelar un Sprint, y solo lo hace cuando el Sprint Goal queda obsoleto (por ejemplo, por un cambio estratégico de la organización). La cancelación de Sprints es muy rara y costosa, pero es posible. Ni el SM ni el Dev Team pueden cancelar un Sprint.
Pregunta 28
¿Qué herramienta se usa típicamente para DAST (Dynamic Application Security Testing)?
A) SonarQube
B) OWASP ZAP
C) Git
D) Jira
✅ Respuesta Correcta: B
Explicación: OWASP ZAP (Zed Attack Proxy) es una herramienta de DAST que prueba aplicaciones en ejecución simulando ataques (SQL injection, XSS, CSRF…). A diferencia de SAST (SonarQube), DAST ejecuta la aplicación y la ataca como lo haría un hacker. En el SAS se usa para escanear Diraya en preproducción.
Pregunta 29
En el contexto de metodologías ágiles, ¿qué significa MVP?
A) Maximum Value Product
B) Minimum Viable Product
C) Most Valuable Player
D) Minimal Verification Process
✅ Respuesta Correcta: B
Explicación: MVP (Minimum Viable Product) es un producto con las características mínimas necesarias para ser desplegado y obtener feedback temprano de usuarios. Es una estrategia Lean: en lugar de construir el producto completo, construyes lo mínimo viable, aprendes, y luego iteras. Ejemplo SAS: MVP de app ClicSalud+ con solo cita previa, luego añadir más funciones.
Pregunta 30
¿Cuál de las siguientes NO es una característica del Development Team en SCRUM?
A) Es auto-organizado
B) Es multifuncional (cross-functional)
C) Está dirigido por el Scrum Master que asigna tareas
D) Es responsable de crear el Incremento
✅ Respuesta Correcta: C
Explicación: El Development Team es auto-organizado: ellos mismos deciden quién hace qué y cómo. El Scrum Master NO asigna tareas ni «dirige» al equipo. El SM facilita el proceso y elimina impedimentos, pero el equipo es autónomo. Esta es una característica fundamental de SCRUM que lo diferencia de gestión tradicional.

🎯 Evaluación del Cuestionario

Interpretación de Resultados:

  • 27-30 correctas: Excelente. Estás preparado/a para el examen.
  • 23-26 correctas: Muy bien. Repasa los temas que fallaste.
  • 20-22 correctas: Suficiente. Necesitas reforzar conceptos clave.
  • <20 correctas: Insuficiente. Vuelve a estudiar el tema completo.

Áreas críticas para repasar:

  1. Los 4 valores y 12 principios del Manifiesto Ágil (memorización literal)
  2. Diferencia entre Sprint Review y Sprint Retrospective
  3. Los 3 artefactos de SCRUM (Product Backlog, Sprint Backlog, Incremento)
  4. Métricas de Kanban: Lead Time vs Cycle Time, CFD
  5. Los 3 Caminos de DevOps y las 4 métricas clave
  6. Diferencia entre SAST y DAST en DevSecOps
  7. Los 7 principios de Lean

11. Mapa Conceptual del Tema 📐

                            ┌─────────────────────────────────┐
                            │  DESARROLLO ÁGIL DE SOFTWARE    │
                            │  (Manifiesto Ágil 2001)         │
                            └────────────┬────────────────────┘
                                         │
                   ┌─────────────────────┼─────────────────────┐
                   │                     │                     │
        ┌──────────▼──────────┐ ┌───────▼────────┐ ┌─────────▼─────────┐
        │   4 VALORES DEL     │ │  12 PRINCIPIOS  │ │   METODOLOGÍAS    │
        │  MANIFIESTO ÁGIL    │ │   OPERATIVOS    │ │      ÁGILES       │
        └──────────┬──────────┘ └────────────────┘ └─────────┬─────────┘
                   │                                          │
          ┌────────┴────────┐                    ┌────────────┼────────────┐
          │                 │                    │            │            │
   ┌──────▼──────┐  ┌──────▼──────┐      ┌──────▼────┐ ┌────▼─────┐ ┌───▼────┐
   │  PERSONAS   │  │  SOFTWARE   │      │   SCRUM   │ │  KANBAN  │ │  LEAN  │
   │    SOBRE    │  │FUNCIONANDO  │      │           │ │          │ │        │
   │  PROCESOS   │  │    SOBRE    │      └─────┬─────┘ └────┬─────┘ └───┬────┘
   └─────────────┘  │DOCUMENTACIÓN│            │            │           │
                    └─────────────┘            │            │           │
                                               │            │           │
   ┌────────────────────────────────────┬──────┴────────────┼───────────┤
   │                                    │                   │           │
┌──▼────────────┐              ┌────────▼──────────┐ ┌─────▼──────┐ ┌─▼──────┐
│  ROLES SCRUM  │              │  EVENTOS SCRUM    │ │  ARTEFACTOS│ │ MÉTRICAS│
├───────────────┤              ├───────────────────┤ ├────────────┤ ├─────────┤
│• Product      │              │• Sprint           │ │• Product   │ │• Lead   │
│  Owner        │              │• Sprint Planning  │ │  Backlog   │ │  Time   │
│• Scrum Master │              │• Daily Scrum      │ │• Sprint    │ │• Cycle  │
│• Development  │              │• Sprint Review    │ │  Backlog   │ │  Time   │
│  Team         │              │• Sprint           │ │• Incremento│ │• CFD    │
└───────────────┘              │  Retrospective    │ └────────────┘ │• WIP    │
                               └───────────────────┘                └─────────┘

                    ┌─────────────────────────────────────┐
                    │         EVOLUCIÓN ÁGIL              │
                    └──────────────┬──────────────────────┘
                                   │
              ┌────────────────────┼────────────────────┐
              │                    │                    │
       ┌──────▼──────┐      ┌──────▼──────┐     ┌──────▼──────┐
       │   DEVOPS    │      │ DEVSECOPS   │     │   SCRUMBAN  │
       │ (Dev + Ops) │      │(Dev+Sec+Ops)│     │ (Scrum +    │
       └──────┬──────┘      └──────┬──────┘     │  Kanban)    │
              │                    │             └─────────────┘
    ┌─────────┼─────────┐          │
    │         │         │          │
┌───▼────┐┌───▼────┐┌──▼───┐  ┌───▼───────┐
│CI/CD   ││ IaC    ││ChatOps│  │Shift-Left │
├────────┤├────────┤├───────┤  │Security   │
│Jenkins ││Terraform│Slack  │  ├───────────┤
│GitLab │││Ansible ││Teams  │  │• SAST     │
│GitHub │││        ││       │  │• DAST     │
│Actions│││        ││       │  │• Dep Check│
└────────┘└────────┘└───────┘  │• Container│
                                │  Security │
┌──────────────────────────┐    └───────────┘
│ PILARES DEVOPS           │
├──────────────────────────┤
│1. FLOW (Flujo)           │
│2. FEEDBACK               │
│3. CONTINUOUS LEARNING    │
└──────────────────────────┘

┌──────────────────────────────────────────────────────────┐
│           APLICACIÓN EN EL SAS                           │
├──────────────────────────────────────────────────────────┤
│                                                          │
│  SCRUM          → Desarrollo Diraya (nuevas features)   │
│  KANBAN         → ayudaDIGITAL (Service Desk)           │
│  DEVOPS         → CI/CD para apps móviles               │
│  DEVSECOPS      → Cumplimiento ENS + RGPD               │
│  LEAN           → Optimización procesos desarrollo       │
│                                                          │
│  OBJETIVO: Transformación Digital SSPA 2022-2027        │
└──────────────────────────────────────────────────────────┘

┌──────────────────────────────────────────────────────────┐
│          MÉTRICAS CLAVE DE ÉXITO                         │
├──────────────────────────────────────────────────────────┤
│  SCRUM     → Velocity (puntos/sprint)                    │
│             → Burndown Chart                             │
│  KANBAN    → Lead Time / Cycle Time                      │
│             → CFD (Cumulative Flow Diagram)              │
│             → Throughput                                 │
│  DEVOPS    → Deployment Frequency                        │
│             → Lead Time for Changes                      │
│             → MTTR (Mean Time to Restore)                │
│             → Change Failure Rate                        │
└──────────────────────────────────────────────────────────┘
💡 Cómo Usar Este Mapa:

Este mapa conceptual está diseñado para ayudarte a visualizar las relaciones entre conceptos. Recomendaciones:

  • Imprímelo y tenlo visible mientras estudias
  • Dibuja tu propia versión a mano (ayuda a memorizar)
  • Úsalo para hacer repasos rápidos antes del examen
  • Complementa con ejemplos del SAS para cada concepto

12. Conclusiones y Estrategia de Estudio 🎓

12.1. Ideas Clave del Tema (Memorizar)

🔑 Las 10 Ideas Clave que DEBES Dominar:

  1. Manifiesto Ágil: 4 valores + 12 principios (memorización literal de al menos 5 principios)
  2. SCRUM Roles: Product Owner (QUÉ), Scrum Master (facilitador), Dev Team (CÓMO)
  3. SCRUM Artefactos: Product Backlog, Sprint Backlog, Incremento
  4. SCRUM Eventos: Sprint, Planning, Daily (15min), Review (PRODUCTO), Retrospective (PROCESO)
  5. Kanban vs SCRUM: Flujo continuo vs Sprints, WIP explícito, Lead Time vs Velocity
  6. Kanban Métricas: Lead Time (cliente), Cycle Time (interno), CFD (diagrama clave)
  7. Lean 7 Principios: Eliminar desperdicio es #1, los otros 6 también importantes
  8. DevOps: CI/CD, IaC, Los 3 Caminos, 4 métricas clave
  9. DevSecOps: Shift-Left Security, SAST vs DAST, integración seguridad desde diseño
  10. Aplicación SAS: Diraya (SCRUM), ayudaDIGITAL (Kanban), Apps móviles (DevOps), ENS (DevSecOps)

12.2. Estrategia de Memorización

Para el Manifiesto Ágil (4 valores + 12 principios):

Técnica del Acrónimo:

Los 4 valores empiezan con: I-S-C-R

  • Individuos e interacciones
  • Software funcionando
  • Colaboración con el cliente
  • Respuesta ante el cambio

Para los 12 principios: Crea tarjetas Anki con el principio en una cara y un ejemplo del SAS en la otra.

Para SCRUM:

Visualización: Dibuja un ciclo Sprint completo incluyendo:

  • Sprint Planning (inicio)
  • Daily Scrum (durante, 15 min)
  • Sprint Review (final, PRODUCTO)
  • Sprint Retrospective (final, PROCESO)
  • Incremento (salida)

Repite el dibujo 10 veces a mano. Tu cerebro recordará el patrón visual.

Para Kanban:

Práctica: Crea un tablero Kanban para tu propio estudio:

  • Columnas: TEMAS POR ESTUDIAR | EN PROGRESO | REPASO | DOMINADO
  • Límite WIP: Máximo 2 temas «En Progreso»
  • Mide tu Lead Time por tema

Aplicar Kanban a tu propia preparación te ayudará a entenderlo profundamente.

12.3. Errores Comunes a Evitar

❌ Los 7 Errores Más Frecuentes:

  1. Confundir Sprint Review con Sprint Retrospective
    • Review = PRODUCTO (qué se construyó)
    • Retrospective = PROCESO (cómo se trabajó)
  2. Pensar que SCRUM no permite cambios
    • SCRUM sí permite cambios, pero no durante el Sprint si afectan al Sprint Goal
  3. Creer que Agile = sin documentación
    • Agile valora software funcionando SOBRE documentación, pero la documentación sigue siendo necesaria
  4. Confundir Lead Time con Cycle Time
    • Lead Time = desde petición hasta entrega (incluye esperas)
    • Cycle Time = desde inicio trabajo hasta entrega (solo trabajo activo)
  5. Pensar que el Scrum Master es el jefe del equipo
    • El SM es un facilitador, no un manager. No asigna tareas ni controla al equipo
  6. Confundir CI/CD con DevOps
    • CI/CD es una práctica de DevOps, no es lo mismo que DevOps (que es una cultura)
  7. Creer que Gantt es parte de Kanban
    • Gantt es Waterfall. Kanban usa CFD (Cumulative Flow Diagram)

12.4. Plan de Estudio Sugerido (1 Semana)

📅 Plan Intensivo 7 Días:

Día 1 (3 horas): Filosofía y Manifiesto Ágil

  • Lee la introducción y apartados 2-3
  • Memoriza los 4 valores del Manifiesto
  • Lee el Manifiesto Ágil original: agilemanifesto.org
  • Haz las preguntas 1, 2, 11 del cuestionario

Día 2 (4 horas): SCRUM (Parte 1)

  • Lee apartado 4 completo sobre SCRUM
  • Descarga y lee la Scrum Guide oficial (PDF gratis)
  • Dibuja un ciclo Sprint completo en papel
  • Haz las preguntas 3-7, 12-13, 21, 23, 27, 30 del cuestionario

Día 3 (3 horas): SCRUM (Parte 2) + Caso Práctico SAS

  • Repasa los roles, artefactos y eventos de SCRUM
  • Lee el Caso Práctico 1 (Diraya con SCRUM)
  • Identifica en tu trabajo actual qué elementos de SCRUM se aplican
  • Repite preguntas SCRUM que hayas fallado

Día 4 (3 horas): KANBAN + LEAN

  • Lee apartados 5 (Kanban) y 6 (Lean)
  • Diferencia clara entre Lead Time y Cycle Time
  • Memoriza los 7 principios de Lean
  • Lee el Caso Práctico 2 (ayudaDIGITAL con Kanban)
  • Haz las preguntas 8, 10, 14, 16-17, 24 del cuestionario

Día 5 (4 horas): DevOps

  • Lee apartado 7 (DevOps) completo
  • Memoriza los 3 Caminos de DevOps
  • Memoriza las 4 métricas clave
  • Entiende bien CI/CD, IaC, ChatOps
  • Haz las preguntas 9, 15, 20, 22, 25-26 del cuestionario

Día 6 (3 horas): DevSecOps

  • Lee apartado 8 (DevSecOps) completo
  • Diferencia SAST (SonarQube) vs DAST (OWASP ZAP)
  • Entiende «Shift-Left Security»
  • Conecta con ENS y RGPD (Temas 36 y 38)
  • Haz las preguntas 18-19, 28 del cuestionario

Día 7 (4 horas): Repaso Global + Simulacro

  • Repasa el mapa conceptual completo
  • Revisa todas las ideas clave
  • Haz el cuestionario completo (30 preguntas) en 45 minutos
  • Repasa las preguntas que falles
  • Lee las conclusiones y estrategia de estudio

Total: 24 horas de estudio efectivo en 7 días = ~3-4 horas/día

🎯 El Día Antes del Examen:

  • Repasa solo el mapa conceptual y las ideas clave
  • Haz un simulacro rápido de 10 preguntas aleatorias
  • NO estudies contenido nuevo
  • Descansa bien (dormir 8 horas es MÁS importante que estudiar una hora más)

13. Referencias Normativas y Bibliográficas 📚

Documentos Oficiales y Guías

The Scrum Guide (2020) – Ken Schwaber & Jeff Sutherland
Disponible en: https://scrumguides.org/
Documento oficial de SCRUM (19 páginas). IMPRESCINDIBLE.
Manifesto for Agile Software Development (2001)
Disponible en: https://agilemanifesto.org/
El documento fundacional del movimiento ágil.
Principles behind the Agile Manifesto
Disponible en: https://agilemanifesto.org/principles.html
Los 12 principios explicados.

Normativa y Estándares

ISO/IEC 12207:2017 – Systems and software engineering – Software life cycle processes
Estándar internacional para procesos del ciclo de vida del software.
ISO/IEC 20000-1:2018 – Information technology – Service management
Estándar de gestión de servicios TI (alineado con ITIL).
Real Decreto 311/2022, de 3 de mayo, por el que se regula el Esquema Nacional de Seguridad
Normativa española de ciberseguridad (aplicable al SAS).
Reglamento (UE) 2016/679 – RGPD
Normativa europea de protección de datos (crítica para el SAS).

Bibliografía Técnica

The Phoenix Project – Gene Kim, Kevin Behr, George Spafford (2013)
Novela técnica sobre DevOps. Muy didáctica.
The DevOps Handbook – Gene Kim, Jez Humble, Patrick Debois (2016)
Manual completo de DevOps.
Accelerate – Nicole Forsgren, Jez Humble, Gene Kim (2018)
Investigación sobre las 4 métricas clave de DevOps.
Kanban – David J. Anderson (2010)
El libro de referencia sobre Kanban en desarrollo de software.
Implementing Lean Software Development – Mary & Tom Poppendieck (2006)
Adaptación de Lean manufacturing al desarrollo de software.

🎯 ¡Mucho Éxito en tu Oposición!

Recuerda: El conocimiento técnico es importante, pero la constancia y la estrategia son las que realmente marcan la diferencia.

Esteban Castro – Preparador de Oposiciones SAS

Documento generado: Noviembre 2025 | Tema 15: Desarrollo Ágil de Software – Continuación

Publicaciones relacionadas

TEI – Tema 13. Herramientas de gestión de TIC: gestión de proyectos, de la operación, del conocimiento y gestión interna para la función de tecnologías de la información y comunicaciones en el Servicio Andaluz de Salud.

Esteban Castro

OPE 2025 TFA INF. Tema 18. Derechos de los ciudadanos. La libre elección de médico y hospital en Andalucía. Las garantías del plazo de respuesta en procesos quirúrgicos y en procesos asistenciales en el Sistema Sanitario de Andalucía: regulación. El ejercicio del derecho a la segunda opinión médica. Asistencia sanitaria a personas sin recursos en la Comunidad Autónoma de Andalucía. La prestación de ayuda para morir: regulación nacional y autonómica.

Esteban Castro

Protegido: OPE 2025 TFA INF. Tema 72. Los sistemas de gestión de bases de datos (SGBD). Modelos y arquitecturas: bases de datos centralizadas y distribuidas, bases de datos federadas, bases de datos no relacionales: clave- valor, documentales, de objetos, grafos, columnares. Motores de indexación. El modelo de referencia ANSI. Monitor de transacciones. Control de concurrencia. Bloqueos. Recuperación de errores. Integridad.

Esteban Castro