Tema 41
Desarrollo Ágil de Software
Filosofía, Principios, Manifiesto Ágil, SCRUM, Kanban, Lean, DevOps, DevSecOps
Oposición Técnico/a de Función Administrativa – Opción Sistemas y Tecnología de la Información (TFA-STI) del SAS
🎯 Por qué Desarrollo Ágil es CRÍTICO para tu futuro TFA-STI
Conexión temas anteriores:
- Tema 37 (Gestión Proyectos): «Metodologías Ágil vs Waterfall» – profundizamos SCRUM aquí
- Tema 38 (Herramientas): «JIRA Scrum boards, Kanban» – entiendes POR QUÉ funcionan así
- Tema 39 (Ciclo Vida): «Modelos Ágiles SDLC» – detalles técnicos implementación
- Tema 40 (Análisis): «Historias Usuario vs Casos Uso» – enfoque ágil requisitos
Realidad trabajo SAS: Desarrollos Diraya evolucionan con Sprints. Versiones anuales (6.0 → 6.1 → 6.2) siguen patrones ágiles. Teams/Circuit = colaboración ágil diaria. DevOps para CI/CD automation.
En examen: 15-20% preguntas desarrollo ágil. Manifiesto Ágil (4 valores memorizar), SCRUM roles, Kanban WIP limits, DevOps vs DevSecOps diferencias.
1. Introducción al Desarrollo Ágil de Software
1.1. ¿Qué es Desarrollo Ágil?
El desarrollo ágil de software es un conjunto de metodologías y prácticas que buscan optimizar la producción de software, mejorando la capacidad de adaptación a los cambios y fomentando la entrega continua de valor.
Este enfoque se basa en la colaboración entre equipos multidisciplinarios y en ciclos de desarrollo iterativos e incrementales (típicamente 1-4 semanas llamados «Sprints»).
📚 Contexto Histórico
Los métodos ágiles surgieron en respuesta a las limitaciones de los enfoques tradicionales como el modelo en cascada (Waterfall), que resultaban rígidos y difíciles de adaptar a los cambios de requisitos.
A través de prácticas colaborativas y entrega frecuente de software funcional, la agilidad permite reducir riesgos, mejorar la satisfacción del cliente y aumentar la eficiencia en el desarrollo.
1.2. Diferencias Fundamentales: Ágil vs Waterfall
| Aspecto | Waterfall (Tradicional) | Ágil (Moderno) |
|---|---|---|
| Cambios requisitos | Costosos, se evitan | Bienvenidos, esperados |
| Planificación | Extensa al inicio | Iterativa, adaptable |
| Entrega valor | Al final (meses/años) | Cada Sprint (1-4 semanas) |
| Documentación | Exhaustiva | Suficiente, prioriza software funcionando |
| Cliente | Validación final | Colaboración continua |
| Equipo | Roles especializados | Multifuncional, auto-organizado |
2. Filosofía y Principios del Desarrollo Ágil
2.1. Filosofía del Desarrollo Ágil
El enfoque ágil se fundamenta en cuatro pilares filosóficos:
Capacidad de adaptarse a cambios en los requisitos del software durante el desarrollo. Los cambios NO son problema, son oportunidad de mejorar.
Desarrollo en ciclos cortos (Sprints) con entregas parciales de funcionalidad. Cada Sprint produce software funcionando.
Trabajo en equipo, comunicación constante y compromiso con el usuario final. Daily standups, demos, retrospectivas.
Testing automatizado, integración continua (CI/CD) y feedback constante para mejorar proceso y producto.
2.2. Los 12 Principios del Desarrollo Ágil
Basados en el Manifiesto Ágil (2001), estos principios guían las prácticas ágiles:
Satisfacción del cliente a través de entregas tempranas y continuas de software valioso.
Aceptación del cambio en los requisitos incluso en etapas avanzadas del desarrollo.
Entregas frecuentes de software funcional en periodos cortos (semanas, no meses).
Colaboración entre equipos de negocio y desarrollo a lo largo del proyecto.
Motivación y autonomía de los equipos, proporcionando el entorno adecuado.
Comunicación directa y efectiva cara a cara siempre que sea posible.
Software funcional como medida principal de progreso.
Ritmo sostenible para garantizar calidad sin sobrecarga de trabajo.
Atención a la excelencia técnica y buen diseño mejora la agilidad.
Simplicidad como principio clave para optimizar el desarrollo.
Equipos auto-organizados que generan las mejores arquitecturas y diseños.
Reflexión y ajuste constante de procesos para mejorar continuamente.
✅ Aplicación SAS: Principios Ágiles en Diraya
- Principio 1 (Satisfacción cliente): Versiones Diraya anuales entregan funcionalidades que médicos solicitan
- Principio 3 (Entregas frecuentes): Hotfixes Diraya cada mes, versiones mayores cada año
- Principio 4 (Colaboración): Médicos piloto participan UAT antes lanzamiento
- Principio 6 (Comunicación directa): Teams/Circuit facilita comunicación equipos STIC
- Principio 12 (Mejora continua): Retrospectivas post-implantación para mejorar MCMI
3. El Manifiesto Ágil (2001)
📜 Historia del Manifiesto Ágil
El Manifiesto Ágil, publicado en febrero de 2001 por un grupo de 17 expertos en desarrollo de software (incluyendo Kent Beck, Martin Fowler, Jeff Sutherland, Ken Schwaber), estableció los cuatro valores fundamentales que transformaron la industria del software.
Estos valores reflejan la importancia de la adaptabilidad, comunicación efectiva y entrega continua de valor por encima de la rigidez y documentación excesiva del Waterfall.
3.1. Los 4 Valores del Manifiesto Ágil
Memoriza estos 4 valores para el examen – aparecen frecuentemente:
1️⃣ Individuos e Interacciones
SOBRE
Procesos y Herramientas
Significado: La comunicación entre personas es más importante que seguir procesos rígidos. Un equipo motivado y colaborativo produce mejor software que seguir procedimientos estrictos.
Ejemplo SAS: Daily Standup 15min cara a cara > email formal reporte semanal
2️⃣ Software Funcionando
SOBRE
Documentación Extensiva
Significado: El software que funciona es la medida del progreso, NO documentos de 500 páginas. Documentación suficiente, NO exhaustiva.
Ejemplo SAS: Demo Diraya v6.1 funcional médicos > documento especificación técnica 200 páginas
3️⃣ Colaboración con el Cliente
SOBRE
Negociación Contractual
Significado: Trabajar JUNTO al cliente (usuario final) durante todo el proyecto es más valioso que negociar contratos cerrados al inicio.
Ejemplo SAS: Médicos participan Sprint Reviews cada 2 semanas > contrato LCSP fijo sin cambios permitidos
4️⃣ Respuesta al Cambio
SOBRE
Seguir un Plan Rígido
Significado: Adaptarse a cambios de requisitos es ventaja competitiva, NO problema. El cambio NO es enemigo, es realidad.
Ejemplo SAS: Cambio normativo RGPD mid-proyecto → adaptar requisitos Sprint siguiente > rechazar cambio porque «plan inicial decía otra cosa»
⚠️ Importante: «Sobre» NO significa «en lugar de»
El Manifiesto Ágil NO dice que procesos, documentación, contratos y planes sean innecesarios. Dice que los valores de la izquierda son MÁS importantes que los de la derecha.
Ejemplo: Sí hay documentación en Ágil (Confluence documenta arquitectura Diraya), pero se prioriza software funcionando demostrando valor real.
3.2. Aplicación de los 4 Valores en el SAS
| Valor Manifiesto | Aplicación Práctica SAS | Herramienta/Proceso |
|---|---|---|
| 1. Individuos e Interacciones | Equipos STIC usan Teams/Circuit para comunicación continua diaria, evitando emails formales y burocráticos | Teams Daily Calls, Circuit mensajes |
| 2. Software Funcionando | Versiones Diraya productivas cada año (6.0, 6.1, 6.2…) médicos usan real vs documentos teóricos | Diraya Producción, UAT hospitales piloto |
| 3. Colaboración Cliente | Médicos participan UAT antes lanzamiento, feedback directo incorpora próximas versiones | UAT médicos, Sprint Reviews, MCMI validaciones |
| 4. Respuesta Cambio | Hotfixes mensuales Diraya responden cambios normativos (SINAUTO receta, RGPD updates) sin bloquear desarrollo | Hotfixes, Sprints adaptativos, JIRA backlog flexible |
✅ Tips Examen: Preguntas Frecuentes Manifiesto Ágil
- «¿Cuál NO es valor Manifiesto Ágil?» → Respuesta: Cualquier que invierta orden (ej: «Documentación sobre software funcionando» = FALSO)
- «¿Qué significa ‘sobre’ en Manifiesto?» → Respuesta: Valorar MÁS lo izquierdo, NO eliminar lo derecho
- «¿Cuántos valores tiene Manifiesto?» → Respuesta: 4 valores (NO confundir con 12 principios)
- «¿Cuál valor prioriza colaboración con usuario?» → Respuesta: Valor 3 (Colaboración con cliente sobre negociación contractual)
3.3. Contraste: Waterfall vs Manifiesto Ágil
4. Métodos de Desarrollo Ágil
Existen varios métodos ágiles que aplican los principios del Manifiesto Ágil. Los más relevantes para el examen TFA-STI son SCRUM, Kanban, Lean, DevOps y DevSecOps.
4.1. SCRUM – El Marco Ágil Más Popular
SCRUM es el marco ágil más utilizado mundialmente y se basa en ciclos de desarrollo llamados Sprints, que duran típicamente entre 1 y 4 semanas (normalmente 2 semanas en SAS).
🎯 Los 3 Roles SCRUM (CRÍTICO MEMORIZAR)
| Rol SCRUM | Responsabilidades | Aplicación SAS |
|---|---|---|
| Product Owner (PO) |
✓ Define y prioriza Product Backlog
✓ Responsable valor negocio ✓ Comunica requisitos equipo ✓ Valida entregas end-user |
Ejemplo: Director STIC Diraya define que v6.2 añade telemedicina |
| SCRUM Master (SM) |
✓ Facilita proceso SCRUM
✓ Elimina impedimentos («blockers») ✓ Asegura adherencia SCRUM ✓ Coaching equipo + organización |
Ejemplo: SM identifica que BBDD lenta ralentiza Sprints → escalada infraestructura |
| Equipo Desarrollo |
✓ Multifuncional (dev, testers, diseñadores)
✓ Auto-organización tareas ✓ Entrega software funcional ✓ Responsabilidad colectiva |
Ejemplo: 7 devs Java + 2 testers + 1 designer Diraya trabajan Sprint 2 semanas |
📅 Los 4 Eventos SCRUM (Ceremonias)
Cuándo: Inicio Sprint (típicamente Lunes)
Duración: 2-4 horas (Sprint 2 semanas)
Qué: Equipo selecciona historias Usuario del Backlog que caben Sprint (basado velocidad)
Output: Sprint Backlog definido, tareas asignadas
SAS Ejemplo: Planning Diraya v6.2 Sprint decide: «Esta semana implementar video-consulta, next week recetas»
Cuándo: Cada día laborable (típicamente 09:30 AM)
Duración: 15 minutos MÁXIMO (time-boxed)
Qué: Cada dev responde 3 preguntas:
- ¿Qué hice ayer?
- ¿Qué haré hoy?
- ¿Qué impedimentos tengo?
SAS Ejemplo: Daily Diraya Teams call 09:30, todos responden preguntas rápido, SM nota impedimento BBDD, escalada
Cuándo: Fin Sprint (típicamente Viernes)
Duración: 1-2 horas
Qué: Equipo DEMUESTRA software funcionando a Product Owner + stakeholders (médicos, usuarios finales)
Output: Feedback usuario recolectado, Product Backlog refinado
SAS Ejemplo: Demo Diraya v6.2 telemedicina funciona → médicos pilotos aprueban, feedback «añadir gravación»
Cuándo: Fin Sprint (después Sprint Review)
Duración: 1-1.5 horas
Qué: Equipo reflexiona INTERNA (sin PO) sobre proceso, NO producto
Preguntas: ¿Qué funcionó? ¿Qué mejorar? ¿Acciones próximo Sprint?
SAS Ejemplo: Retro Diraya: «JIRA lento, testing manual toma tiempo, necesitamos tests automáticos» → Acción próximo Sprint
📊 Conceptos SCRUM Clave
Product Backlog
Lista priorizada de requisitos/historias Usuario que Product Owner mantiene. Nunca termina (siempre hay mejoras). Ej: Diraya Backlog tiene 500+ items.
Sprint Backlog
Subconjunto Product Backlog que equipo selecciona Sprint. Items NO completados próximo Sprint vuelven Backlog. Típicamente 10-20 historias por Sprint 2 semanas SAS.
Velocidad (Velocity)
Histórico de cuántos Story Points equipo completa por Sprint. Usa planning futuro. Ej: Equipo Diraya velocidad 40 puntos/Sprint → próximo planning «cabemos 40 puntos».
Definición de Hecho (Definition of Done)
Criterios acordados considerar tarea completada. Típicamente: código + tests + code review + documentación + demo funcionando.
💡 Diferencia Importante: Sprint Planning vs Backlog Refinement
Backlog Refinement (PREVIO Sprint Planning): PO + devs preparan historias (estimación, claridad) ANTES planning
Sprint Planning (inicio Sprint): Equipo selecciona historias refinadas, las asigna tareas concretas
En SAS: Refinement cada jueves (prepara viernes planning sprint siguiente)
4.2. KANBAN – Visualización Flujo Continuo
Kanban es un método visual para gestionar el flujo de trabajo basado en un tablero con columnas que representan estados del proceso.
📊 Tablero KANBAN Típico
📋 Límite WIP (Work In Progress): Máximo items por columna
Ejemplo arriba: BACKLOG ilimitado (preparación) | TODO max 20 items | IN PROGRESS max 5 (enfoque) | DONE ilimitado (completados)
Ventaja: Evita sobrecarga equipos, mantiene flujo constante, identifica cuellos botella (ej: si IN PROGRESS siempre en max, problema en tests)
Principios KANBAN
- Visualización del trabajo: Tablero visible todos ven qué se hace + estado
- Limitación WIP (Work In Progress): Máximo items «In Progress» → evita sobrecarga
- Entrega continua: NO Sprints fijos, items fluyen tablero continuamente
- Mejora continua: Monitorizan Lead Time (cuánto tarda item Backlog → Done)
✅ SCRUM vs KANBAN: ¿Cuál Elegir?
| Aspecto | SCRUM | KANBAN |
|---|---|---|
| Ciclos | Sprints fijos (2 semanas) | Flujo continuo, NO Sprints |
| Cambios | Mid-Sprint = minimizar | Cambios bienvenidos cualquier momento |
| Mejor para | Proyectos nuevos, requisitos claros | Operación continua, cambios frecuentes |
| SAS Aplicación | Diraya v6.0 → v6.1 desarrollo | Hotfixes Diraya, mantenimiento operación |
4.3. LEAN – Eliminación Desperdicios
Lean Development se basa en los principios de manufactura Lean de Toyota (1950s) aplicados software. Foco: eliminar desperdicios.
7 Tipos Desperdicio Lean en Desarrollo Software
- Código parcialmente construido: Features comenzadas NO terminadas
- Procesos/burocracias: Reuniones innecesarias, aprobaciones lentas
- Requisitos incompletos: Inicio desarrollo sin claridad suficiente
- Esperas: Dev esperando feedback, testing esperando BBDD…
- Defectos/Testing: Bugs descubiertos late (testing mal integrado)
- Features innecesarias: Desarrollar funciones usuario NO pide
- Complejidad extra: Código sobre-engineered, arquitectura innecesaria
Principios LEAN
- Optimización del flujo de trabajo: Reducir ciclo idea → entrega
- Reducción de desperdicios: Documentación excesiva, trabajo innecesario
- Mejora continua aprendizaje: Validar supuestos hipótesis rápido
- Respeto personas: Motivar equipos, autonomía decisiones
4.4. DevOps – Integración Dev + Ops
DevOps es una metodología que integra desarrollo (Dev) y operaciones (Ops) para mejorar la entrega continua de software, automatizando procesos SDLC.
Pilares DevOps
| Pilar | Explicación | SAS Diraya Ejemplo |
|---|---|---|
| Automatización (CI/CD) | Build, test, deploy automáticos cada commit. NO manual | Commit GitHub → Jenkins build automático → tests → deploy staging → producción |
| Colaboración Dev-Ops | Dev + Ops trabajar juntos (NO silos). Shared responsibility | Teams Dev+Ops diarios, shared JIRA backlog, «you build it, you run it» |
| Monitorización | Logs, métricas, alertas sistemas producción real-time | Nagios monitoriza Diraya producción, alerta si CPU >80%, downtime >5min |
| Infraestructura Como Código | Infraestructura definida código (versionada, reproducible) | Terraform scripts definen servidores Diraya, version control Git |
💡 DevOps vs SCRUM
SCRUM: Cómo DESARROLLAR software (metodología)
DevOps: Cómo ENTREGAR software automatizado continuamente (práctica operacional)
Combinados: Equipo SCRUM Sprint 2 semanas + DevOps CI/CD automático = entrega rápida calidad
4.5. DevSecOps – DevOps + Seguridad
DevSecOps extiende DevOps integrando SEGURIDAD desde el inicio del ciclo de vida del software, NO como afterthought final.
Principios DevSecOps
- Seguridad Shift-Left: Pruebas seguridad TEMPRANO desarrollo (vs final)
- Automatización pruebas seguridad: SAST (análisis código), DAST (testing dinámico)
- Cumplimiento normativo: RGPD, ENS, HIPAA checks automáticos CI/CD
- Vulnerabilidad scanning: Dependencias, librerías vulnerables identificadas automático
- Secrets management: Passwords, API keys NO en código, gestión centralizada segura
⚠️ DevSecOps Crítico SAS Diraya
HC pacientes = datos CRÍTICOS sensibles. DevSecOps NO opcional:
- ✓ RGPD: Cifrado AES-256, derecho olvido automático
- ✓ ENS: Logs auditoría 10 años, cumplimiento medidas organizativas/técnicas
- ✓ Seguridad: Cada commit Diraya scanning vulnerabilidades automático (OWASP)
- ✓ Compliance: Tests automáticos verifican requisitos regulatorios sin human error
4.6. Comparativa Métodos Ágiles
| Método | Enfoque | Ciclos | Mejor Para | SAS Uso |
|---|---|---|---|---|
| SCRUM | Sprints iterativos estructurados | 2-4 semanas | Proyectos nuevos | Diraya development versiones |
| Kanban | Flujo continuo visualizado | Continuo (NO fijo) | Operación, cambios frecuentes | Diraya hotfixes, mantenimiento |
| Lean | Eliminación desperdicios | Variable, optimiza ciclos | Eficiencia máxima | Optimización procesos SAS |
| DevOps | Integración Dev-Ops CI/CD | Deploy múltiple veces día | Entrega automatizada continua | Diraya CI/CD pipeline Jenkins |
| DevSecOps | DevOps + Seguridad integrada | Deploy seguro continuo | Crítico datos sensibles | Diraya RGPD/ENS compliance |
⚡ Tips Examen: Métodos Ágiles
- «¿Qué rol SCRUM prioriza backlog?» → Product Owner
- «¿Duración típica Sprint?» → 1-4 semanas (normalmente 2)
- «¿Cuántas ceremonias SCRUM?» → 4 (Planning, Daily, Review, Retro)
- «¿Diferencia SCRUM vs Kanban?» → Sprints fijos vs flujo continuo
- «¿Qué es WIP Kanban?» → Límite Work In Progress (evita sobrecarga)
- «¿DevOps + qué = DevSecOps?» → Seguridad integrada ciclo vida
5. Cuestionario de Autoevaluación – 20 Preguntas Tipo Test
📝 Instrucciones del Cuestionario
20 preguntas sobre desarrollo ágil: Manifiesto Ágil valores, SCRUM roles/eventos, Kanban, Lean, DevOps, DevSecOps.
Tiempo recomendado: 40 minutos.
Objetivo: >16 correctas (80%) para considerar tema dominado.
Pregunta 1
¿Cuál es el principal objetivo del desarrollo ágil?
A) Reducir documentación completamente
B) Garantizar entregas rápidas de software funcional adaptable a cambios
C) Seguir plan rígido sin modificaciones
D) Maximizar herramientas sobre colaboración humana
✓ Respuesta: B – Ágil prioriza entrega frecuente software funcionando con capacidad adaptación cambios.
Pregunta 2
¿Cuál de los siguientes NO es valor del Manifiesto Ágil?
A) Respuesta al cambio sobre plan rígido
B) Software funcionando sobre documentación exhaustiva
C) Documentación detallada sobre colaboración cliente
D) Individuos e interacciones sobre procesos
✓ Respuesta: C – Ágil prioriza colaboración cliente, NO documentación excesiva.
Pregunta 3
¿Cuál rol SCRUM define prioridades Product Backlog?
A) SCRUM Master
B) Equipo Desarrollo
C) Product Owner
D) Stakeholder externo
✓ Respuesta: C – Product Owner responsable gestionar y priorizar Product Backlog.
Pregunta 4
¿Cuál es duración típica Sprint SCRUM?
A) 1 día
B) 1-4 semanas (normalmente 2)
C) 1 mes
D) 1 trimestre
✓ Respuesta: B – SCRUM típicamente 2 semanas (rango 1-4 semanas válido).
Pregunta 5
¿Cuántas ceremonias/eventos tiene SCRUM?
A) 2 (Planning, Review)
B) 3 (Planning, Daily, Review)
C) 4 (Planning, Daily, Review, Retrospective)
D) 5+ (incluye Backlog Refinement)
✓ Respuesta: C – 4 ceremonias SCRUM principales (Refinement técnicamente separado).
Pregunta 6
¿Cuál es duración máxima Daily Scrum?
A) 5 minutos
B) 15 minutos
C) 30 minutos
D) 1 hora
✓ Respuesta: B – Daily Scrum time-boxed 15 minutos máximo (no discusiones largas).
Pregunta 7
¿Cuál es propósito Sprint Retrospective?
A) Validar software con usuarios finales
B) Equipo reflexiona cómo mejorar proceso INTERNO (sin PO)
C) Planificar próximo Sprint tareas
D) Reportar progreso executives
✓ Respuesta: B – Retrospective reunión INTERNA equipo reflexiona proceso, NO producto/usuario.
Pregunta 8
¿Qué significa WIP en Kanban?
A) Work In Progress (límite items en «In Progress»)
B) Work Important Points
C) Weekly Information Planning
D) Work Intensive Process
✓ Respuesta: A – WIP = máximo tareas simultáneas, limita sobrecarga equipos.
Pregunta 9
¿Diferencia SCRUM vs Kanban?
A) SCRUM mejor Kanban peor
B) SCRUM Sprints fijos, Kanban flujo continuo
C) Son exactamente iguales
D) Kanban solo para mantenimiento
✓ Respuesta: B – SCRUM ciclos fijos, Kanban continuidad, cada uno uso diferente.
Pregunta 10
¿Cuál es objetivo Lean Development?
A) Sprints rápidos ilimitados
B) Automatización total desarrollo
C) Eliminar desperdicios, optimizar flujo
D) Máxima documentación
✓ Respuesta: C – Lean elimina actividades innecesarias, mejora eficiencia procesos.
Pregunta 11
¿Qué es DevOps?
A) Framework SCRUM mejorado
B) Integración Dev + Ops, automatización CI/CD
C) Sistema operativo «Development Operations»
D) Documento operacional proyecto
✓ Respuesta: B – DevOps metodología integra desarrollo + operaciones, automatiza pipeline.
Pregunta 12
¿Cuál es diferencia DevOps vs DevSecOps?
A) Son lo mismo
B) DevSecOps = DevOps + seguridad integrada desde inicio
C) DevSecOps solo para gobierno
D) No existe DevSecOps, solo marketing
✓ Respuesta: B – DevSecOps extiende DevOps integrando seguridad temprano ciclo vida.
Pregunta 13
¿Qué es CI/CD DevOps?
A) Continuous Integration / Continuous Delivery (automatización build-test-deploy)
B) Customer Interface / Customer Development
C) Certificación Industry / Compliance Division
D) Component Integration / Component Design
✓ Respuesta: A – CI/CD automatiza pipeline software (build, test, deploy) múltiple veces día.
Pregunta 14
¿Cuál es principal beneficio desarrollo ágil SAS?
A) Evitar completamente cambios requisitos
B) Entrega frecuente valor usuarios, adaptación cambios rápida
C) Reducir equipos trabajo
D) Eliminar testing software
✓ Respuesta: B – Ágil permite entregas frecuentes adaptables cambios (RGPD, normativa sanitaria).
Pregunta 15
¿Cuántos valores principales tiene Manifiesto Ágil?
A) 2
B) 4
C) 12
D) 20
✓ Respuesta: B – 4 valores (NO confundir con 12 principios).
Pregunta 16
¿Qué es Sprint Backlog?
A) Lista todos requisitos proyecto globales
B) Items Product Backlog seleccionados Sprint actual
C) Errores encontrados testing
D) Documentos completados Sprint
✓ Respuesta: B – Sprint Backlog subconjunto items PO prioriza equipo Sprint.
Pregunta 17
¿Quién facilita SCRUM proceso elimina impedimentos?
A) Product Owner
B) SCRUM Master
C) CEO empresa
D) Cliente externo
✓ Respuesta: B – SCRUM Master facilita proceso, elimina blockers, coaching equipo.
Pregunta 18
¿Cuál NO es desperdicio Lean?
A) Código parcialmente construido
B) Testing automatizado (detecta bugs temprano)
C) Procesos burocráticos lentos
D) Esperas entre equipos
✓ Respuesta: B – Testing automatizado REDUCE desperdicios, NO es desperdicio.
Pregunta 19
¿Cuál pilar DevOps automatiza pipeline?
A) Colaboración
B) Monitorización
C) Automatización CI/CD
D) Infraestructura
✓ Respuesta: C – Automatización build-test-deploy automático cada commit.
Pregunta 20
¿Cuál medida principal progreso Ágil?
A) Documentación completada
B) Horas trabajadas equipo
C) Software funcionando entregado Sprint
D) Reuniones completadas
✓ Respuesta: C – Manifiesto Ágil: «software funcionando» medida progreso.
✅ Evaluación de Resultados
- 18-20 correctas: Excelente, dominas desarrollo ágil completo
- 15-17 correctas: Muy bien, repasa métodos específicos (DevOps, Lean)
- 12-14 correctas: Bien, estudia más SCRUM roles/eventos + Manifiesto Ágil
- 10-11 correctas: Aprobado, repasa conceptos SCRUM básicos
- <10 correctas: Repasa tema completo, céntrate en: 4 valores Manifiesto, 3 roles SCRUM, 4 eventos SCRUM, diferencias métodos
6. Mapa Conceptual Tema 41
7. Referencias Normativas y Bibliográficas (Tema 41)
Estándares y Documentos
- Manifiesto Ágil (2001): agilemanifesto.org – 4 valores, 12 principios
- SCRUM Guide (2020): scrumguides.org – Schwaber & Sutherland (creadores SCRUM)
- Kanban Guide (2019): kanban.guide – visualización, WIP limits
- ISO/IEC/IEEE 12207:2017: Software life cycle processes (incluye métodos ágiles)
Libros Referencia
- Ken Schwaber, Jeff Sutherland: «SCRUM: The Art of Doing Twice the Work in Half the Time»
- David Anderson: «Kanban: Successful Evolutionary Change for Your Technology Business»
- Mary Poppendieck: «Lean Software Development: An Agile Toolkit»
- Gene Kim, Kevin Behr, George Spafford: «The Phoenix Project» (DevOps origen)
- Nicole Forsgren, Jez Humble, Gene Kim: «Accelerate: The Science of Lean Software and DevOps»
Contexto SAS
- MCMI SAS: Modelo Corporativo Marco Implantaciones (incorpora Sprints, metodología ágil)
- Diraya: Ciclo vida versiones sigue Sprint Planning + Review (ágil SDLC)
- JIRA Diraya: Gestión productos ágil SAS
- Teams/Circuit: Comunicación continua Daily Standup SAS