Vas comprar llicències d'IA per al teu equip i la velocitat continua sent pràcticament la mateixa. És la queixa número u que sentim de CTOs i VP d'Enginyeria el 2026, i gairebé sempre té la mateixa arrel: el problema no és l'eina, és el mètode. La IA que vas donar al teu equip accelera un tram del procés —teclejar codi— però deixa intactes els dos trams on de veritat es perd el temps: decidir què val la pena construir i verificar que allò construït és correcte. Aquest article explica com muntar un Scrum dual-track accelerat amb IA que ataca els tres trams alhora, amb el mètode operatiu que onext fa servir en producció.
Per què el Scrum "normal" amb IA accelera el tram equivocat
El Scrum clàssic fica descobriment i entrega al mateix carril: un backlog, un sprint, i l'esperança que les històries arribin "prou definides" en començar. Funcionava —amb fricció— quan escriure el codi era la feina cara. La IA trenca aquest equilibri: quan teclejar una funció passa d'hores a minuts, la feina cara es desplaça aigües amunt (què construeixo i amb quines regles?) i aigües avall (això és correcte, segur i mantenible?).
El resultat, en equips que "van adoptar IA" sense canviar el mètode, és previsible:
- Es genera codi més ràpid del que es pot decidir i revisar. El generador va a 10x; el que decideix l'abast i el que revisa el PR continuen a 1x. El coll es mou, no desapareix.
- La "velocitat percebuda" puja i l'entrega no. És la paradoxa que va documentar METR: els equips senten que van més ràpid mentre el lead time real fins a producció no millora, perquè el retreball es menja el guany.
- El deute es difereix, no s'elimina. Codi sense especificació prèvia ni verificació sistemàtica produeix bugs i reprocessos que apareixen un o dos trimestres després, quan ja ningú no els atribueix a "la setmana que vam anar ràpids".
La conclusió operativa: perquè la IA acceleri l'entrega (no només l'escriptura), cal separar el carril que decideix del carril que construeix, i ficar verificació en tots dos. Això és el dual-track.
Què és un dual-track i per què la IA el fa per fi viable
El dual-track agile no és nou: separa discovery (què construir i per què) de delivery (com es construeix), corrent en paral·lel i no en cascada. La idea sempre va ser bona; el problema és que fer bé el discovery —especificar sense ambigüitat, mapar regles de negoci, casos límit— era tan car que gairebé ningú no el mantenia, i el track es degradava a "un backlog una mica millor".
La IA canvia l'economia: especificar, dissenyar i verificar deixen de ser la feina cara i lenta. I aquí hi ha la inversió clau que la majoria no veu —fer servir la IA sobretot per pensar millor abans de codificar, no només per codificar més ràpid. Quan el cost d'una bona especificació cau, el dual-track deixa de ser un luxe de procés i es converteix en el multiplicador: cada hora invertida al track de discovery n'estalvia diverses al de delivery, perquè el codi es genera contra una diana clara en comptes de contra una intuïció.
A onext l'operem amb una espina dorsal de mètode —Spec-Driven Development (SDD)— sobre tres nivells d'estabilitat:
| Nivell | Què fixa | Cadència de canvi |
|---|---|---|
| Mòdul (estable) | què fa cada peça del sistema i com està construïda de veritat | lent — es refresca en tancar cada història |
| Discovery / Feature (mitjà termini) | quin problema resolem i per a qui | per feature |
| Delivery / Història (curt termini) | què construïm ara i com | per història, una vegada |
El track de discovery: decidir bé, amb IA, abans de tocar codi
El track de discovery respon a què construir i per què, i la seva sortida és una feature "shaped": definida sense assumpcions i prioritzada. El flux:
- Idea. Entra crua en un inbox, sense filtre. Pot venir de negoci, de suport, d'una anàlisi de mercat o d'un spike tècnic que valida viabilitat.
- Qualificació. La idea s'accepta (es promou a feature) o es descarta amb motiu. Aquí ja es decideix què NO es fa, que és la meitat del valor.
- Shaping sense assumpcions. La feature s'especifica elicitant actors, casos d'ús, regles de negoci, invariants i casos límit — preguntant tot el que faci falta en comptes d'assumir. Aquest és el pas que la IA fa per fi barat: un assistent disciplinat interroga la idea fins que no queden buits.
- Priorització. La feature entra en un backlog prioritzat que alimenta el roadmap (el quan).
El gate humà és explícit: una feature no passa a delivery sense aprovació d'una persona. La IA accelera el shaping; no signa l'abast. Aquest és el primer punt on el human-on-the-loop manté el control.
El track de delivery: construir amb verificació a cada pas (SDD)
Quan una feature prioritzada "passa a desenvolupament", es descompon en Històries d'Usuari atòmiques —cadascuna una entrega coherent que es pot demostrar funcionant— i cada història recorre el cicle SDD complet. Aquí és on la IA accelera de veritat, perquè cada etapa té un artefacte de sortida i un gate abans d'avançar:
- Història — "Com… vull… per a…" + criteris d'acceptació.
- PRD (especificació) — requisits curats, amb requisits no funcionals quantificats i ≥3 casos límit per requisit crític. Estat "llest" = zero preguntes obertes.
- Disseny tècnic — model d'amenaces, rendiment objectiu per endpoint, decisions impactades, rutes d'error per cas límit. Si la història fa servir LLM, incorpora una revisió específica d'enginyeria d'IA.
- Tasques — descomposició en vertical slices de ≤4 h, amb almenys una tasca adversarial per requisit crític (una tasca la feina de la qual és intentar trencar allò construït).
- Implementació + tests — amb límits de qualitat forçats per hooks automàtics (mida d'arxiu i funció, cobertura mínima, tests obligatoris).
- Review — no una persona mirant el PR, sinó diversos auditors especialitzats en paral·lel (seguretat, aïllament de dades, coherència doc-codi…), cadascun amb la seva checklist. Veredicte quantificat abans de tancar.
- Sincronització del mòdul — la documentació "com està construït de veritat" s'actualitza automàticament, perquè el següent que arribi no hereti una mentida.
I un gate a escala de sprint: quan totes les històries estan fetes, una auditoria del diff consolidat del sprint caça les regressions i interaccions que la revisió història a història no veu, abans de donar el sprint per tancat.
On accelera la IA (i on decideix l'humà)
El malentès car és pensar que "IA accelerada" significa "IA autònoma". En el dual-track d'onext la IA fa la feina pesada de cada etapa —redactar l'especificació, proposar el disseny, generar les tasques, escriure el codi i els tests, executar les auditories— i l'humà conserva la decisió als gates: quina feature entra, quina especificació està llesta, quin disseny s'aprova, quin veredicte de review tanca la història.
Això és human-on-the-loop, no human-in-the-loop: l'humà no tecleja cada línia, però signa a cada frontera de risc. És exactament el que permet anar ×7 sense que la qualitat es pagui en producció — i el que fa defensable davant d'un comitè la frase "anem més ràpid": no és sensació, hi ha un artefacte i un gate darrere de cada pas.
A més, diversos d'aquests passos corren en paral·lel real: els auditors de review es llancen alhora, no en fila. L'acceleració no ve només que cada tasca sigui més ràpida, sinó que el procés deixa de ser una seqüència d'esperes.
Com implementar-lo al teu equip: un camí de 8 setmanes
No s'instal·la un dual-track per decret ni comprant una altra llicència. És un canvi de mètode que, en la pràctica d'onext, es construeix amb l'equip en unes 8 setmanes, sense parar l'entrega:
- Setmanes 1-2 · Línia base i espina dorsal. Mesurar el lead time real fins a producció (no la sensació) i muntar el nivell "mòdul": escriure, per a les peces que tocareu, què fan i com estan de veritat. Sense aquesta base, tota la resta flota.
- Setmanes 3-4 · Track de discovery. Instaurar el flux idea → shaping sense assumpcions → priorització, amb la IA fent la feina d'especificació i una persona signant el gate. Objectiu: que cap història entri a delivery sense abast tancat.
- Setmanes 5-6 · Track de delivery (SDD). Portar 2-3 històries reals pel cicle complet (PRD → disseny → tasques → review) amb gates i auditoria. S'aprèn fent, sobre feina que igualment calia entregar.
- Setmanes 7-8 · Gates de sprint i transferència. Activar l'auditoria de sprint i, sobretot, transferir el mètode a l'equip: l'objectiu no és que depenguis de nosaltres, sinó que el mètode es quedi a dins. En acabar, la capacitat és teva.
El principi que ordena tot el calendari: 0 sprints perduts durant la transformació. No es para per transformar; es transforma entregant.
Com sabràs que funciona: què mesurar
Canviar de mètode sense mesurar és canviar de fe. El dual-track accelerat es defensa amb números que un comitè entén:
- Lead time fins a producció (d'idea acceptada a feature en producció governada). És la mètrica; baixa ~50% sobre una base de mercat de ~16 setmanes.
- Velocitat d'entrega (throughput d'històries amb valor verificat, no línies de codi). El headline signat el 2026 és ×7.
- Sprints perduts durant la transició. Objectiu: 0.
- Retreball / bugs en producció per història. Ha de baixar, no pujar — és la prova que la velocitat no es paga en deute.
- Cost per tasca útil verificada, no per llicència instal·lada. La unitat que de veritat mesura el retorn.
Preguntes freqüents
Què és un Scrum dual-track accelerat amb IA?
És un mètode àgil que separa dos carrils que corren en paral·lel: discovery (decidir què construir i amb quines regles, sense assumpcions) i delivery (construir-ho amb verificació a cada pas, via Spec-Driven Development). La IA accelera la feina pesada de tots dos carrils —especificar, dissenyar, generar, testejar, auditar— mentre una persona conserva la decisió als gates. Ataca els tres colls del desenvolupament (decidir, construir, verificar), no només el d'escriure codi.
Per què el meu equip té llicències d'IA i no va més ràpid?
Perquè la IA accelera escriure codi, que rarament és el coll d'ampolla real. Sense un mètode que ordeni què es construeix i com es verifica, generes més codi més ràpid i traslades l'embús a la decisió d'abast i a la revisió — a més d'acumular deute que apareix mesos després. El problema no és l'eina, és el mètode.
Quant es triga a implementar un dual-track amb IA?
En la pràctica d'onext, unes 8 setmanes, construint-lo amb l'equip i sense parar l'entrega (objectiu: 0 sprints perduts). Primer es fixa la línia base i la documentació de mòduls; després s'instauren els dos tracks sobre històries reals; al final es transfereix el mètode perquè la capacitat es quedi al teu equip.
Això no alenteix l'equip amb "més procés"?
Al revés, si el procés té els gates correctes. El dual-track no afegeix burocràcia: substitueix el retreball (la part cara i invisible) per especificació i verificació barates —perquè la IA les fa en minuts—. El resultat mesurable en els equips transformats és ×7 en velocitat d'entrega amb el deute baixant, no pujant.
Conclusió
La IA no accelera el teu equip pel fet d'estar instal·lada. Accelera quan el mètode aprofita que especificar i verificar ja no són cars: un carril que decideix bé què construir i un altre que ho construeix amb verificació a cada pas, amb la persona signant en els gates que importen. Aquest és el Scrum dual-track accelerat amb IA — i és la diferència entre generar més codi i entregar més valor amb menys deute. En els equips que onext ha transformat, aquest canvi de mètode val ×7 en velocitat, 0 sprints perduts i −50% de time-to-production, amb la capacitat quedant-se dins de l'equip.
Jordi García és Tech Lead a onext. Treballa a portar la IA a producció governada en equips de desenvolupament i de producte —amb Spec-Driven Development, enginyeria de context i verificació humana a cada pas— i signa els insights tècnics d'onext sobre mètode, qualitat i cost de la IA aplicada.
LinkedIn →