Waterfall vs Àgil
El model en cascada (Waterfall)
El model en cascada, formalitzat per Winston Royce el 1970, organitza el projecte en fases seqüencials i estrictament ordenades: cada fase ha de completar-se completament abans que comenci la següent.
flowchart TD
R["Requisits\n(Que ha de fer el sistema?)"]
D["Disseny\n(Com ho construirem?)"]
I["Implementacio\n(Codificacio i configuracio)"]
T["Proves\n(Verificacio del resultat)"]
E["Entrega\n(Desplegament al client)"]
M["Manteniment\n(Correccio de defectes)"]
R --> D --> I --> T --> E --> M
style R fill:#1565c0,stroke:#0d47a1,color:#fff
style D fill:#0288d1,stroke:#01579b,color:#fff
style I fill:#00695c,stroke:#004d40,color:#fff
style T fill:#558b2f,stroke:#33691e,color:#fff
style E fill:#e65100,stroke:#bf360c,color:#fff
style M fill:#6a1b9a,stroke:#4a148c,color:#fffPer que va tenir sentit en el seu moment
El waterfall va ser dissenyat per a projectes d'enginyeria civil i manufactura, on canviar els plànols a mig construir un pont és extremadament car. En aquell context, definir tot al principi i executar sense desviacions era la millor estratègia.
En els primers anys de la informàtica, els projectes eren relativament estables: sistemes de nòmines, controls d'inventari, càlculs científics. Els requisits canviaven poc i els equips eren petits. El waterfall funcionava prou bé.
El problema: el món canvia
A mesura que el programari va créixer en complexitat i els negocis van accelerar el seu ritme de canvi, el waterfall va mostrar les seves limitacions:
1. Els requisits mai estan clars al principi
El client sovint no sap exactament el que vol fins que veu el producte funcionant. Quan li preguntes "que ha de fer el sistema?", descriu el problema actual, no la solució òptima. Descobreix els requisits reals en usar el sistema.
2. L'error es descobreix massa tard
Si un requisit es malentén a la fase inicial, l'error no es detecta fins a la fase de proves — mesos o anys després. En aquell moment, refer el disseny i la implementació és molt car.
flowchart LR
subgraph WF["Waterfall: cost de corregir un error"]
C1["Detectat\na Requisits\ncost: 1x"]
C2["Detectat\na Disseny\ncost: 5x"]
C3["Detectat\na Implementacio\ncost: 10x"]
C4["Detectat\na Proves\ncost: 25x"]
C5["Detectat\nen Produccio\ncost: 100x"]
end
C1 -.-> C2 -.-> C3 -.-> C4 -.-> C5
style C1 fill:#e8f5e9,stroke:#388e3c,color:#1b5e20
style C2 fill:#fff9c4,stroke:#f9a825,color:#5d4037
style C3 fill:#ffe0b2,stroke:#e65100,color:#5d4037
style C4 fill:#ffcdd2,stroke:#c62828,color:#7f0000
style C5 fill:#b71c1c,stroke:#7f0000,color:#fff3. El client no veu res fins al final
En un projecte waterfall de 18 mesos, el client no veu cap resultat fins al mes 18. Si aleshores descobreix que el sistema no s'adapta a com treballen realment, tot el treball queda obsolet.
4. Els equips treballen en silos
Analistes, dissenyadors, programadors i testers treballen en fases separades i rarament interactuen. Quan arriba la fase de proves, l'equip de disseny ja ha passat a un altre projecte i no hi ha ningú disponible per aclarir decisions anteriors.
El context ASIX: on falla el waterfall a sistemes?
En administració de sistemes, el waterfall apareix sovint disfressat:
- "Primer fem el document d'arquitectura, el valida el responsable, i després instal·lem."
- "No podem fer el deploy fins que totes les proves estiguin documentades i signades."
- "Necessitem els requisits complets del projecte de migració abans de demanar les llicències."
El resultat: el document d'arquitectura queda obsolet el primer dia, el deploy es retarda setmanes per burocràcia, i les llicències arriben quan els requisits han canviat.
La resposta àgil
Les metodologies àgils responen a aquests problemes amb un canvi radical de perspectiva:
| Principi waterfall | Principi àgil |
|---|---|
| Definir-ho tot al principi | Acceptar el canvi com a part del procés |
| Lliurar al final | Lliurar valor de forma incremental i freqüent |
| Seguir el pla | Adaptar el pla a la realitat |
| Documentació exhaustiva | Programari/sistema funcionant com a mesura de progrés |
| Contracte tancat | Col·laboració contínua amb el client |
El cicle incremental
En comptes d'una única entrega al final, les metodologies àgils divideixen el treball en increments curts (sprints d'1-4 setmanes). Cada increment lliura una part funcional del sistema.
flowchart LR
subgraph S1["Sprint 1 (2 setmanes)"]
direction TB
P1["Planificacio"] --> D1["Disseny i impl."] --> R1["Revisio + Retrosp."]
end
subgraph S2["Sprint 2 (2 setmanes)"]
direction TB
P2["Planificacio"] --> D2["Disseny i impl."] --> R2["Revisio + Retrosp."]
end
subgraph S3["Sprint 3 (2 setmanes)"]
direction TB
P3["Planificacio"] --> D3["Disseny i impl."] --> R3["Revisio + Retrosp."]
end
I1["Increment 1\nfuncional"] --> I2["Increment 2\nfuncional"] --> I3["Increment 3\nfuncional"]
S1 --> I1 --> S2 --> I2 --> S3 --> I3Cada sprint produeix un increment potencialment lliurable: algo que el client pot veure, provar i sobre el que pot donar feedback. Aixo permet detectar errors i canvis de requisits molt abans — quan el cost de corregir-los és mínim.
La metàfora del cotxe
El waterfall construeix el cotxe complet abans de mostrar-lo: primer el xassís, després el motor, després la carrosseria. Si el client volia una furgoneta i no un turisme, ho descobreix al final.
L'àgil construeix el vehicle de forma incremental però sempre funcional: primer un patinet (s'hi pot anar a peu), després una bicicleta, després una moto, finalment el cotxe. En cada pas el client pot usar el producte i confirmar si va en la direcció correcta.
Activitat AC-RA1-01
Penseu en un projecte de sistemes que hagueu vist o viscut (una migració, una instal·lació, una actualització):
- Identifiqueu quines fases del waterfall hi havia implícitament.
- En quin moment es van descobrir els problemes o canvis de requisits?
- Quin hauria estat el cost de detectar-los abans?
- Com podria un cicle incremental d'1-2 setmanes haver millorat el resultat?