L'agilitat va treure molts equips dels projectes eterns. Lliuraments curts, conversa amb negoci i programari que funciona abans que el pla es quedi vell. Ningú amb seny vol tornar enrere.
Però en molts equips va passar una altra cosa pel camí. «Iterar» va anar ocupant el lloc de l'anàlisi funcional i del disseny tècnic. La feina no va desaparèixer: va canviar de lloc. Menys pensar abans, més corregir després de lliurar.
La tesi d'aquesta peça: amb agents que llegeixen l'especificació, l'anàlisi i el disseny tornen a compensar, i el lliurament pot continuar sent curt. El rigor d'abans amb la cadència d'ara. És una tesi, no un resultat mesurat, i al final expliquem on pot fallar.
El que diu el Manifest (i el que no)
Convé començar pel text original, del 2001. El Manifest Àgil valora les persones i les seves interaccions per sobre dels processos i les eines, el programari que funciona per sobre de la documentació exhaustiva, la col·laboració amb el client per sobre de la negociació del contracte i la resposta al canvi per sobre de seguir un pla.
I afegeix la frase que més s'oblida: tot i que hi ha valor en els elements de la dreta, valorem més els de l'esquerra. «Més» no vol dir «en lloc de». La documentació i el pla tenen valor; només pesen menys.
Els dotze principis ho deixen encara més clar. Un demana lliurar programari que funcioni sovint, entre un parell de setmanes i un parell de mesos, amb preferència pel termini més curt. Un altre, que negoci i desenvolupament treballin junts cada dia. I el novè diu que l'atenció contínua a l'excel·lència tècnica i al bon disseny millora l'agilitat.
On es va perdre l'anàlisi
Que pensar abans no sobra ho han dit, des de dins, dos dels signants del Manifest.
Martin Fowler va escriure «Is Design Dead?» per a una conferència del 2000 i el va revisar el 2004. La seva resposta era que no: la programació extrema implica molt de disseny, però fet d'una altra manera. També reconeixia el risc. En el seu ús habitual, deia, el disseny que creix mentre es construeix és un desastre, i els seus detractors el veien com una tornada al «programar i arreglar». I tancava amb un equilibri: el disseny planificat no desapareix del tot i hi ha lloc per dissenyar abans de programar.
Dave Thomas, un altre dels disset signants, va anar més lluny el 2014 amb «Agile is Dead (Long Live Agility)». Per a ell, la paraula «agile» s'havia buidat de significat en convertir-se en un terme de màrqueting. Proposava quedar-se amb l'agilitat com a manera de treballar: esbrinar on ets, fer un pas petit cap a l'objectiu, ajustar el que has entès amb el que has après i repetir.
Cap dels dos no demana més documents. Tots dos demanen pensar. El problema no era el Manifest; era que, en el dia a dia, pensar abans de construir es va tornar car de justificar. Amb un sprint de dues setmanes al davant, una anàlisi de tres dies sembla un luxe.
Per què l'especificació torna a compensar
Aquí hi ha el canvi de fons. Fins ara, qui llegia l'anàlisi era una persona que havia de programar. Si l'anàlisi era fluixa, aquella persona preguntava, suposava o ho descobria a mitja feina. El cost d'una mala anàlisi es repartia en converses i en tornar a fer feina.
Amb un agent que construeix, l'especificació és l'entrada de la feina. L'especificació de spec-kit, el kit de GitHub per a l'Spec-Driven Development (SDD, desenvolupament guiat per especificacions), ho descriu així: els documents de requisits eren la bastida que es construïa i es llençava tan bon punt començava la feina «de veritat», la de programar. A l'SDD, l'especificació passa a ser l'artefacte principal i el codi, la seva expressió en un llenguatge i un framework concrets.
Dit de manera pràctica: el que no està escrit, l'agent ho suposa. Una anàlisi funcional bona, amb casos i criteris, i un disseny tècnic que digui on va cada cosa ja no són un luxe. Són el que necessita qui construeix. Si vols la definició d'SDD amb calma, és a SDD: la metodologia que converteix la IA en codi controlat.
Per què no és tornar al waterfall
L'objecció és òbvia: si tornem a escriure abans de construir, no estem tornant al waterfall? La diferència és la mida i el ritme.
El waterfall escrivia l'anàlisi de tot el projecte abans de construir res i lliurava al final. Amb l'SDD s'especifica la peça de treball següent, l'agent la construeix i el lliurament arriba aviat. L'anàlisi torna; els mesos d'espera, no.
Birgitta Böckeler, de Thoughtworks, ho vigila des de l'altre costat. Després de provar tres eines d'SDD, escriu que l'experiència ha demostrat que la millor manera de mantenir el control del que construïm són els passos petits i iteratius. Dubta que molt de disseny d'especificació per endavant sigui bona idea. I adverteix que una bona eina d'SDD hauria de permetre treballar de manera iterativa, tot i que les peces de treball petites gairebé semblen anar contra la idea mateixa de l'SDD. En algun dels seus casos, el procés li va semblar excessiu per a la mida del problema.
| Pregunta | Waterfall | Iterar sense anàlisi (la deriva) | Especificació i agent (la tesi) |
|---|---|---|---|
| Quan es pensa què s'ha de construir? | Tot al principi | Durant i després de lliurar | Abans de cada peça, a la seva mida |
| Qui llegeix l'anàlisi? | Persones, de vegades mesos després | Gairebé ningú: una història d'una línia | L'agent que construeix i la persona que ho revisa |
| Cada quant es lliura? | Al final | Cada poques setmanes | Cada poques setmanes o abans |
| On apareix el desacord amb negoci? | Al lliurament final | A la revisió de l'sprint, com a feina refeta | En revisar l'especificació, abans del codi |
| Quin és el risc principal? | Un document enorme que es queda vell | Lliurar molt i alinear poc | Una especificació pesada o sense criteris comprovables |
Elaboració pròpia d'onext. L'última columna és una tesi, no un resultat mesurat.
La fila que més importa és la quarta. A la deriva, el desacord amb negoci es descobreix quan ja hi ha programari: s'ensenya, no era això, es refà. Amb l'especificació al davant, el desacord pot aparèixer en llegir-la, quan corregir costa una conversa. Per això té sentit que una persona signi l'especificació abans que l'agent generi res, com expliquem a l'especificació és on se signa.
El que ha de portar l'especificació per no ser un document llarg
Tornar a l'anàlisi no és tornar als documents de cent pàgines. Una especificació que l'agent llegeix i que ningú no pot comprovar és només prosa. El que la converteix en anàlisi útil són els criteris d'acceptació: frases concretes que diuen què ha de passar i que una màquina pot verificar. Com passar de criteri a porta del merge ho expliquem a la teva spec ja és un eval, i com hi encaixen les proves, a SDD, TDD i BDD: què aporta cadascun.
El disseny tècnic funciona igual. No cal un disseny de tot el sistema abans de començar. Cal que l'especificació de cada peça digui on va, què toca i què no ha de trencar. És l'equilibri de Fowler portat a cada tasca: una mica de disseny planificat, molt de disseny que evoluciona.
Risc Una especificació sense criteris comprovables no recupera l'anàlisi: la imita. Si l'especificació creix i ningú no pot dir si el codi la compleix, has tornat al document que es queda vell, ara amb un agent que l'interpreta a la seva manera.
L'alineació amb negoci, amb els seus límits
La promesa de fons és l'alineació entre TI i negoci a una velocitat raonable: l'anàlisi d'abans per entendre què es demana i la cadència d'ara per comprovar-ho aviat. És la part més atractiva de la tesi i també la que més fàcilment s'exagera.
L'informe de DORA del 2025 sobre desenvolupament de programari assistit per IA ho resumeix en una frase: el paper principal de la IA és el d'amplificador, que magnifica les fortaleses i les debilitats que l'organització ja té. Si negoci i desenvolupament no es parlen, un agent ràpid no ho arregla; lliura més de pressa el que ningú no havia acordat. Ho vam veure des d'un altre angle a el gap del 70 %: l'adopció d'IA en desenvolupament és un problema organitzatiu.
El que encara no sabem
Tres límits que convé dir en veu alta.
- És una tesi. No tenim cap estudi que mesuri l'alineació amb negoci abans i després de treballar amb especificacions i agents. El que hi ha són arguments i fonts que apunten en aquesta direcció.
- El punt d'equilibri no està escrit. Quant cal especificar abans de cada peça depèn del risc, de l'equip i del canvi. Böckeler ho va veure a les seves proves: el mateix procés sobrava per a un problema petit. I Böckeler planteja un dubte de fons: les peces petites gairebé semblen anar contra la idea de l'SDD.
- La disciplina no ve amb l'eina. Escriure bons criteris és un hàbit. Si l'equip no el té, l'especificació serà tan fluixa com la història d'una línia, només que més llarga.
I una pregunta per a la teva propera planificació: de l'última funcionalitat que es va refer, el desacord es podria haver vist llegint una especificació d'una pàgina? Si la resposta és sí, l'anàlisi que et falta no és un document. És una conversa amb data, abans del codi. Si t'interessa el costat incòmode d'aquesta conversa, el de la pressió per ensenyar alguna cosa com més aviat millor, el tractem a MVP davant d'especificació.
Preguntes freqüents
L'Spec-Driven Development és tornar al waterfall?
No, si es fa bé. El waterfall escrivia tota l'anàlisi i tot el disseny abans de construir i lliurava al final. Amb l'Spec-Driven Development (SDD, desenvolupament guiat per especificacions) s'escriu l'especificació de la peça de treball següent, la llegeix l'agent que construeix i el lliurament continua sent curt. El risc d'assemblar-se al waterfall existeix quan l'especificació creix sense mesura: Birgitta Böckeler, de Thoughtworks, recorda que els passos petits i iteratius continuen sent la millor manera de mantenir el control.
El Manifest Àgil està en contra de la documentació i del disseny?
No. El Manifest diu que, tot i que hi ha valor en els elements de la dreta (processos, documentació, contractes i plans), valora més els de l'esquerra. I un dels seus dotze principis diu que l'atenció contínua a l'excel·lència tècnica i al bon disseny millora l'agilitat. El que es va perdre en molts equips va ser una pràctica, no una regla del Manifest.
Per què la IA fa que torni a compensar l'anàlisi funcional?
Perquè l'agent construeix amb el que llegeix. Durant anys, els documents de requisits eren, en paraules de l'especificació de spec-kit (el kit de GitHub per a l'SDD), una bastida que es construïa i es llençava quan començava la feina de veritat. Amb un agent, l'especificació és l'entrada de la feina: el que no està escrit, l'agent ho suposa.
Quant s'ha d'especificar abans que l'agent comenci?
El just per a la peça de treball següent, amb criteris que es puguin comprovar. No hi ha una xifra universal. Böckeler va provar diverses eines d'SDD i en alguns casos el procés li va semblar excessiu per a la mida del problema. La mesura la posa una persona, peça a peça.
La IA arregla la manca d'alineació entre TI i negoci?
No per si sola. L'informe de DORA del 2025 sobre desenvolupament de programari assistit per IA conclou que la IA actua sobretot com a amplificador: magnifica les fortaleses i les debilitats que l'organització ja té. Escriure millor què es construeix és una condició per alinear; no és una garantia.
Què és el disseny evolutiu i què hi té a veure l'SDD?
És la idea que el disseny d'un sistema creix mentre es construeix. Martin Fowler, a «Is Design Dead?», explica que la programació extrema (XP) implica molt de disseny, però fet d'una altra manera, i que el disseny planificat no desapareix del tot: hi ha lloc per dissenyar abans de programar. L'SDD encaixa en aquest equilibri: es dissenya abans de cada peça, no abans de tot el projecte.
Fonts
- Kent Beck, Martin Fowler, Dave Thomas i altres, «Manifesto for Agile Software Development», 2001, i els seus dotze principis (consultats l'11 d'octubre de 2026).
- Martin Fowler, «Is Design Dead?», martinfowler.com, presentat a XP 2000 i revisat el maig del 2004.
- Dave Thomas, «Agile is Dead (Long Live Agility)», pragdave.me, 4 de març de 2014.
- Birgitta Böckeler (Thoughtworks), «Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl», martinfowler.com, 15 d'octubre de 2025.
- GitHub spec-kit, «Specification-Driven Development (SDD)» (sense data visible; consultada l'11 d'octubre de 2026).
- DORA (Google Cloud), «State of AI-assisted Software Development 2025».
Bernat López és fundador i CEO d'onext, boutique d'IA. Acompanya equips de desenvolupament i de producte a treballar amb IA amb mètode —especificació abans de programar, una persona que decideix on hi ha risc i Spec-Driven Development— i aplica a la seva pròpia empresa el que proposa: onext funciona amb el seu propi sistema agèntic.
LinkedIn →