El Ciclo de Vida del Software como Sistema
Ya sabés que un sistema recibe algo, lo transforma y entrega un resultado — y que un sistema que se autorregula además mide su propia salida y la usa para ajustarse. El ciclo de vida del software es exactamente eso: un sistema abierto, con sus propios bucles de control, y con personas en el medio, no solo código.
👁 — vistas · Ing. Roy Carrasco, Facultad de Ingeniería de Sistemas · UAB
Scrollea para empezar — el diagrama de un sprint de Scrum se arma solo, capa por capa, mientras leés.
Un sistema que nunca deja de producir
El ciclo de vida del software (SDLC) es, ante todo, un proceso: recibe algo, lo transforma, entrega algo. Pero un proceso que solo entrega una vez —como una cascada clásica, que corre de punta a punta y recién al final se prueba— se comporta muy distinto a uno que entrega en ciclos cortos y ajusta sobre la marcha. Scrum es el ejemplo más usado de esto último: cada sprint es, en sí mismo, un sistema completo.
Armemos ese sistema en vivo, capa por capa →
Lo que entra al sprint
La entrada de un sprint es el Product Backlog priorizado: la lista de historias de usuario que el Product Owner decidió que son las más valiosas para construir ahora. Nada entra al sprint que no haya pasado antes por esa priorización.
Lo que el equipo hace con eso
El proceso es el sprint mismo: el equipo construye, prueba e integra ese trabajo durante un tiempo fijo (típicamente 1 a 4 semanas). El daily stand-up no agrega nada nuevo al sistema — regula el proceso desde adentro, para que el equipo siga coordinado día a día.
Lo que el sprint entrega
La salida es el incremento: una porción de software potencialmente entregable, funcionando de verdad, no un diseño ni una promesa. Con esto ya tenés un E-P-S completo — pero un sprint aislado, sin ningún ajuste, sería tan ciego como una fábrica que nunca revisa lo que produjo.
La Retrospectiva ajusta el CÓMO
Al cerrar el sprint, el equipo se pregunta qué funcionó y qué no en su propia forma de trabajar — no en el producto. Es un bucle que no sale del sistema hacia el entorno: vuelve a entrar al mismo proceso, para cambiar cómo el equipo trabaja el próximo sprint.
El Sprint Review ajusta el QUÉ
El Sprint Review, en cambio, muestra el incremento a los interesados reales — y su reacción (qué sirve, qué falta, qué cambió en el negocio) vuelve a alimentar el Backlog. Es un segundo bucle, distinto del anterior: no corrige cómo trabaja el equipo, corrige qué construye a continuación.
El sprint nunca está aislado
Un sistema cerrado no intercambia nada con su entorno. Un sprint, en cambio, está constantemente expuesto a lo que pasa afuera: cambios de mercado, nuevas prioridades del negocio, usuarios reales usando el incremento anterior. Eso es lo que hace del ciclo de vida ágil un sistema abierto — justo lo que un modelo en cascada, con sus fases cerradas en secuencia, intenta minimizar.
No es solo código
El sistema completo no termina en el software: incluye al Product Owner decidiendo prioridades, al equipo negociando cómo trabajar, al Scrum Master facilitando. Un sistema de información real es sociotécnico — combina tecnología y personas, y sus fallas casi nunca son solo técnicas.
Ciclos de control: Cascada vs. Ágil
La diferencia entre un modelo en cascada y uno ágil no es solo de "orden de las tareas": es de qué tan seguido el sistema se compara contra la realidad y se corrige.
| Cascada (Waterfall) | Ágil (Scrum) | |
|---|---|---|
| Frecuencia del bucle de control | Uno solo, al final del proyecto | Uno por sprint (1 a 4 semanas) |
| Cuándo se detecta un desvío | Tarde: recién en la entrega final | Temprano: cada Review/Retro |
| Tipo de sistema | Más cerrado durante cada fase | Más abierto al entorno |
La cascada también se corrige — pero su único comparador está al final, cuando ya se construyó todo. Ágil no inventó la retroalimentación: la acortó y la repitió muchas más veces dentro del mismo proyecto.
Un equipo trabaja seis meses en cascada y recién en la última semana el cliente ve el sistema completo por primera vez, pidiendo cambios grandes. ¿Qué le faltó al sistema, en términos de teoría de sistemas?
¿Por qué un sprint corto (1 a 4 semanas) se comporta como un sistema "más abierto" que una fase de cascada de seis meses?
Practiquemos con otro sistema: un pipeline de integración continua (CI/CD). Clasifica cada elemento como Entrada, Proceso o Salida.
Pipeline de integración continua (CI/CD).
Sistemas sociotécnicos
Un sistema de información nunca es solo el software. Es la combinación de tecnología (código, servidores, pipelines) y personas (quienes deciden, quienes construyen, quienes usan) — y ambas partes tienen que funcionar juntas.
Dos equipos pueden usar exactamente el mismo Jira, el mismo pipeline de CI/CD y el mismo framework — y a uno le va bien y al otro no. La diferencia casi nunca es técnica: es cómo las personas del equipo se coordinan, priorizan y se comunican alrededor de esa tecnología.
Relaciona cada elemento del sprint con su rol dentro del sistema.
Un equipo migra a un framework técnicamente superior, pero el proyecto fracasa porque nadie consultó a los usuarios que dependían del sistema anterior y se negaron a adoptarlo. ¿Qué explica mejor este fracaso?
Actividades de repaso
Un repaso integrador de todo el módulo. Cada actividad se corrige al instante; tu progreso se guarda automáticamente en este navegador.
¿Cuál de estas es la diferencia real entre la Retrospectiva y el Sprint Review?
El daily stand-up es un bucle de retroalimentación que compara el resultado del sprint contra el entorno real.
Una empresa de software solo se reúne con sus clientes una vez, al firmar el contrato, y no vuelve a mostrarles nada hasta la entrega final. ¿Cómo describirías ese sistema?
¿Qué parte del sprint corresponde a la "salida" del sistema?
Repasemos el sprint como sistema.
1. El Product Backlog priorizado es la .
2. El equipo construyendo durante el sprint es el .
3. Ajustar cómo trabaja el equipo, sin mirar afuera, es un bucle de .
4. Un ciclo de vida que intercambia poco con su entorno mientras dura el proceso es un sistema más .
📤 Evidencia de la sesión: diagrama del proceso ágil como sistema
Con tu equipo, mapea un sprint de Scrum (u otro proceso ágil que ya conozcan) como sistema completo, mostrando su ciclo de entrada, proceso, salida y ambos bucles de retroalimentación.
Arma el diagrama en Draw.io (gratuito, funciona desde el navegador, no necesita instalación).
Como mínimo, tu diagrama debe incluir:
- Los tres bloques del ciclo (Backlog → Sprint → Incremento) conectados en orden.
- El bucle de Retrospectiva (interno, ajusta el CÓMO) y el bucle de Sprint Review (externo, ajusta el QUÉ), señalados por separado.
- Una anotación de qué hace del sprint un sistema abierto (qué entra y sale desde/hacia el entorno) y de su componente sociotécnico (qué personas participan).
Exporta el diagrama como imagen (PNG o JPG) desde Draw.io y súbelo a la tarea correspondiente en Classroom antes del inicio de la próxima sesión. No se acepta el link editable de Draw.io en lugar de la imagen: sube el archivo directamente.
Cheat Sheet
| Término | Idea clave |
|---|---|
| Backlog | Entrada: lista priorizada de trabajo pendiente. |
| Sprint | Proceso: el equipo construye durante un tiempo fijo. |
| Incremento | Salida: software funcionando, entregable. |
| Daily stand-up | Regulación interna del proceso, día a día. |
| Retrospectiva | Retroalimentación interna: ajusta el CÓMO trabaja el equipo. |
| Sprint Review | Retroalimentación externa: ajusta el QUÉ se construye. |
| Sistema abierto | Intercambia seguido con su entorno. |
| Sistema cerrado | Casi no intercambia con su entorno. |
| Sistema sociotécnico | Combina tecnología y personas; ninguna alcanza sola. |
¿Sabías que...?
🏉 "Scrum" viene del rugby
Hirotaka Takeuchi e Ikujiro Nonaka usaron esa palabra en 1986, en un artículo sobre desarrollo de productos, para describir equipos que avanzan juntos "como en una melé" en vez de pasarse el trabajo por etapas separadas.
📄 El propio Royce ya dudaba de la cascada
Winston Royce, autor del artículo de 1970 que popularizó el modelo en cascada, en realidad advertía en ese mismo texto que aplicarlo sin iterar era "riesgoso e invita al fracaso" — la crítica es casi tan vieja como el modelo.
⛏️ Los sistemas sociotécnicos nacieron en una mina
El concepto se formuló en los años 50 en el Instituto Tavistock, estudiando minas de carbón británicas: la misma tecnología de extracción rendía muy distinto según cómo se organizaban los equipos de mineros alrededor de ella.