El desenvolupament de programari àgil s'associa incòmodament amb contractes en què el resultat final, l'abast de l'encàrrec i la data de lliurament es fixen per endavant. En un projecte àgil, les parts treballen en sprints curts, períodes de treball definits, i el contingut del producte s'ajusta a mesura que avança el projecte.
Això ofereix flexibilitat, però també planteja qüestions legals. Qui estableix les prioritats? Quan s'accepta el resultat d'un sprint? I quan una data de lliurament incomplerta comporta un incompliment? Aquest article estableix com les parts poden respondre contractualment a aquestes preguntes.
Per contracte àgil ens referim, en el que segueix, al conjunt d'acords pels quals les parts registren una col·laboració àgil. A la pràctica, aquesta col·laboració pren la forma d'un acord marc amb acords d'implementació separats per a cada tasca.
Treball i contractació àgils
En un projecte informàtic tradicional, les parts acorden un disseny funcional i tècnic per endavant. El proveïdor es compromet a lliurar aquest resultat en un moment donat. En el desenvolupament àgil, aquesta destinació fixa està deliberadament absent: el resultat és un objectiu mòbil.
Cada sprint ofereix una part funcional i utilitzable del programari. A partir de demostracions i experiència d'usuari, el client ajusta el rumb. Mentre que un contracte tradicional registra on finalitza el projecte, en un treball àgil roman obert.
Per tant, les parts han de resoldre contractualment allò que un projecte tradicional normalment ja mostra a partir de l'especificació. Destaquen quatre temes:
- qui determina les especificacions, és a dir, qui compleix el rol de propietari del producte (la persona que estableix prioritats en nom del client);
- com es processen els canvis a la llista de projectes pendents (la llista prioritzada de funcionalitats que encara s'han de construir), la planificació i el preu;
- quan un component es considera complet, basant-se en una definició de fet (els criteris acordats per a un resultat final) i criteris d'acceptació (els requisits contra els quals es prova un lliurament);
- si les dates de lliurament acordades són estrictes o indicatives.
Una conseqüència pràctica: el treball àgil és difícil de combinar amb una licitació en què l'abast de l'encàrrec es fixa completament per endavant. Una part subjecta a les normes de contractació que, tanmateix, vulgui un desenvolupament àgil, fa bé que prevegi espai en els documents de la licitació per a un acord marc amb encàrrecs d'implementació definits de manera flexible.
Obligació de millor esforç o de resultats?
Segons una obligació de màxim esforç, el proveïdor no garanteix un resultat concret. Es compromet a aplicar la cura que s'espera d'un professional raonablement competent i que actua raonablement. Segons una obligació de resultats, sí que es compromet a un resultat descrit específicament.
L'etiqueta del contracte no és decisiva. Fins i tot quan un contracte fa referència a una obligació de resultats, el tribunal pot concloure, basant-se en la substància dels acords i el seu context, que de fet es tracta d'una obligació de màxim esforç, i viceversa. Per tant, la manera com les parts treballen realment juntes pesa almenys tant com la redacció escollida.
La distinció és important a la pràctica perquè, en una obligació de resultats, el resultat acordat és central, mentre que en una obligació de màxim esforç s'ha d'avaluar si el proveïdor ha aplicat l'esforç requerit. Aquesta diferència determina què argumenten les parts en una disputa i què han de demostrar.
Aquí tornen a aparèixer dues disposicions legals. L'article 6:74(1) del Codi Civil neerlandès estableix la base per a la indemnització per incompliment atribuïble. Tanmateix, no especifica quan hi ha un incompliment; això depèn de la qualificació de l'obligació i del contingut dels acords. L'article 6:248 estableix que un contracte també té les conseqüències derivades de la raonabilitat i la justícia. Això deixa marge per tenir en compte la naturalesa d'una col·laboració àgil a l'hora d'interpretar les obligacions de les parts.
La base contractual: acords marc i d'aplicació
A la pràctica, la col·laboració àgil es registra en capes. Un acord marc regeix el marc general: termes aplicables, responsabilitat, confidencialitat i la manera de cooperació.
Per a cada encàrrec, les parts conclouen un acord d'implementació que estableix l'abast, la planificació, la composició de l'equip, el preu i els criteris d'acceptació per a aquesta part. La relació legal es manté estable mentre que la substància pot avançar amb cada sprint o llançament.
Sense uns criteris d'acceptació clars, no hi ha cap registre de contra què s'ha de provar el resultat. Les disputes sobre si l'esprint ha tingut èxit sorgeixen més fàcilment. Per tant, els criteris d'acceptació concrets i mesurables per esprint són més importants que l'etiqueta que les parts assignen a l'obligació.
Un tema que mereix més atenció en els contractes àgils que en els contractes informàtics tradicionals és la terminació anticipada. Com que un projecte àgil és una sèrie de sprints consecutius sense un punt final fix, el contracte ha de regular quan una part pot aturar-se, què passa amb els components i el codi font ja lliurats i com es produeix la transferència a un altre proveïdor.
Els termes i condicions generals també importen aquí. Els Termes NLdigital 2025 succeeixen l'edició del 2020, afegint capítols sobre compliment normatiu, ciberseguretat, intercanvi de dades, intel·ligència artificial i plataformes en línia, entre d'altres. Els termes del 2020 continuen vigents on les parts els van acordar, així que comproveu quina versió s'aplica al vostre contracte. Només tracten els aspectes àgils específics només de manera limitada; aquests han de ser resolts per les parts en l'acord d'implementació.
Jurisprudència sobre terminis i cooperació
La jurisprudència no mostra cap regla general que una data de lliurament àgil no pugui ser mai estricta. La qualificació depèn del contingut del contracte, del mètode de treball escollit i de la cooperació real de les parts. Tres casos ho il·lustren.
Tribunal de Districte de Midden-Nederland, 26 de juliol de 2023 (ECLI:NL:RBMNE:2023:5936). El proveïdor IPS va desenvolupar un programari de bàscula utilitzant scrum per al client Synergy. El contracte feia referència a un termini de lliurament d'unes 24 setmanes. Aquest termini no es va complir; es va ajornar un nou termini i es va tornar a incomplir. Quan, a mitjans de desembre de 2020, es van lliurar nou dels deu blocs setmanals acordats, Synergy va rescindir el contracte. El tribunal va considerar que el termini de lliurament promès sí que comptava com un termini estricte, de manera que s'havia produït un incompliment. Tanmateix, la rescissió no es va mantenir: atesa la naturalesa de la col·laboració, en la qual es fan nous acords quan es perden els terminis, i atès que el projecte estava gairebé acabat, aquest incompliment no justificava la rescissió. Importància pràctica: fins i tot dins d'una col·laboració àgil, un termini de lliurament promès pot ser estricte, però l'incompliment no fa que una rescissió es mantingui automàticament.
Tribunal de Districte de Amsterdam, 22 d'abril de 2026 (ECLI:NL:RBAMS:2026:3930). Un client va al·legar que el desenvolupador DTT havia lliurat una nova aplicació mòbil amb retard, havia superat els costos pressupostats i havia realitzat el manteniment de les aplicacions existents de manera inadequada. El tribunal va desestimar totes les demandes. No hi havia terminis estrictes: la data de lliurament nomenada al pressupost i a la correspondència s'havia de considerar una obligació de màxim esforç dins d'un mètode de treball àgil o scrum, en què la flexibilitat i la comprensió en evolució són fonamentals. Importància pràctica: una part que vulgui que una data sigui estricta ho ha de constar expressament; una data en un pressupost no és suficient.
Amsterdam Tribunal d'Apel·lació, en el cas entre On Air i Triple IT. Les parts havien acordat treballar de manera àgil o scrum sense definir els resultats finals. En aquest context, l'obligació es redueix a poc més que posar a disposició desenvolupadors competents que s'apliquen d'acord amb el disseny i amb el deure de cura d'un contractista diligent. Si el que es lliura no és conforme, els esforços per fer-ho conforme són, en principi, treball addicional. Això pot ser diferent quan el proveïdor no ha complert els acords o el seu deure de cura, però la càrrega de la prova recau en el client. El mer fet que el rendiment del producte final no compleixi els desitjos del client és, per tant, insuficient per establir un error. En aquests procediments, el tribunal també va nomenar un expert en informàtica per explicar termes com ara scrum master, sprint i done. Importància pràctica: quan no hi ha resultats finals definits, el treball correctiu recau fàcilment en el client.
En avaluar una sol·licitud de rescissió, el tribunal pot, per tant, ponderar el paper que va tenir cada part en el retard i en la realització del projecte. Una part que no vulgui dependre d'aquesta ponderació en un cas individual ha de registrar ella mateixa quan un termini és estricte i quan és possible la rescissió anticipada.
Vuit punts a tractar en el contracte
Treballa els punts següents a l'hora de redactar un contracte àgil. Per a cada tema, formula la resposta a la pregunta adjunta.
- Abast: quina funcionalitat cau dins de l'sprint i quina n'està expressament fora?
- Priorització: qui pot canviar l'endarreriment i aquesta persona té el mandat de fer-ho en nom del client?
- Acceptació: en quin termini ha de fer la prova i respondre el client, i què s'aplica si no ho fa?
- Terminis: la data indicada és indicativa o estricta, i el contracte ho especifica amb el mateix nombre de paraules?
- Preu: el pagament és per sprint, per punt de funció, per hores desplegades o per resultat?
- Propietat i ús: en quin moment obté el client accés al codi font i a la documentació?
- Rescissió: què es transfereix en cas de rescissió anticipada i contra quin pagament?
- Continuïtat: pot un altre proveïdor continuar la feina i quina documentació i transferibilitat de codi requereix això?
També cal incloure una definició de "fet" que no només sigui funcional, sinó que també estableixi requisits de qualitat, documentació i transferibilitat del codi. En cas contrari, encara sorgirà una disputa sobre si el treball lliurat és utilitzable en el moment de la finalització.
Conclusió
El treball àgil ofereix flexibilitat, però requereix un contracte que difereix fonamentalment del model tradicional. La distinció entre les obligacions de màxim esforç i de resultats, uns criteris d'acceptació clars i un acord per a la terminació anticipada són decisius. Els casos discutits mostren que el resultat depèn en gran mesura dels acords específics i de la cooperació real. Un contracte que aborda aquests punts s'alinea millor amb la manera com treballen realment les parts i redueix el risc de conflictes.
Law & More Ajuda els proveïdors i clients de TI a redactar, revisar i negociar acords marc i implementar-los, i assessora sobre la qualificació de les obligacions, els criteris d'acceptació i els acords de sortida. Teniu una disputa sobre retards, resultats o finalització d'un projecte àgil? No dubteu a contactar amb nosaltres per obtenir assessorament personalitzat.
Preguntes freqüents
A continuació responem a les preguntes que ens fan més sovint sobre aquest tema.
Què és un contracte àgil?
El conjunt d'acords pels quals les parts registren una col·laboració àgil. A la pràctica, consisteix en un acord marc que estableix el marc general, amb un acord d'implementació per a cada tasca que cobreix l'abast, la planificació, el preu i els criteris d'acceptació d'aquesta part.
La data de lliurament en un projecte àgil és una data límit estricta?
No automàticament. No hi ha cap regla general; depèn del contracte, del mètode de treball i de la cooperació real. Si voleu que una data sigui estricta, anoteu-la amb el màxim nombre de paraules possibles. Una data en una cita s'ha considerat insuficient.
Quina diferència hi ha entre una obligació de màxim esforç i una obligació de resultats?
En una obligació de resultats, el resultat acordat és fonamental. En una obligació de màxims esforços, s'ha d'avaluar si el proveïdor ha aplicat l'esforç requerit. Aquesta diferència determina allò sobre el qual discuteixen les parts en una disputa.
L'etiqueta del contracte és decisiva?
No. Fins i tot quan el contracte fa referència a una obligació de resultats, el tribunal pot concloure, basant-se en el contingut i el context, que de fet es tracta d'una obligació de màxim esforç, i viceversa. La manera com treballen realment les parts té un pes com a mínim igual.
Qui pot canviar l'endarreriment?
La persona que compleix el rol de propietari del producte. Registreu qui és i si té un mandat per fer-ho en nom del client. Sense aquest acord, sorgeixen disputes sobre qui és responsable dels canvis de prioritats.
Per què importen tant els criteris d'acceptació?
Sense uns criteris d'acceptació clars, no hi ha cap registre de contra què s'ha de provar el resultat. Les disputes sobre si l'esprint ha tingut èxit sorgeixen més fàcilment. A la pràctica, importen més que l'etiqueta adjunta a l'obligació.
Qui paga les reparacions si el lliurament no és conforme?
Quan no s'han definit resultats finals, els esforços per satisfer els desitjos del client recauen en principi a càrrec del client com a treball addicional. Això és diferent quan el proveïdor no ha complert els acords o el seu deure de diligència, però la càrrega de provar-ho recau en el client.
Com s'organitza el pagament en el treball àgil?
Vincular el pagament a un únic moment de lliurament fix no encaixa bé amb un mètode sense un resultat final fix. Les alternatives habituals són el pagament per sprint, per punt de funció o per hores desplegades. Registreu expressament la base escollida.
Puc combinar el treball àgil amb una licitació pública?
Això requereix un enfocament adaptat, perquè una licitació amb un abast totalment fix pressuposa un resultat conegut per endavant. Preveu espai en els documents de la licitació per a un acord marc amb tasques d'implementació definides de manera flexible.
Què he de gestionar en cas de rescissió anticipada?
En quines condicions una part pot aturar el treball, què passa amb els components i el codi font ja lliurats, contra quina transferència de pagament es realitza i què necessita un altre proveïdor per continuar la feina.
Els Termes NLdigital 2025 proporcionen prou orientació?
Només de manera limitada. Succeeixen a l'edició del 2020 i afegeixen capítols sobre compliment normatiu, ciberseguretat, compartició de dades, intel·ligència artificial i plataformes en línia, entre d'altres, però no aborden els aspectes àgils específics. Els termes del 2020 continuen vigents on es van acordar. Aquests els heu de resoldre vosaltres mateixos a l'acord d'implementació.
Teniu una disputa amb un proveïdor de TI o voleu que es revisi un contracte de TI? Els nostres advocats especialitzats en TI estaran encantats d'ajudar-vos.
Com Law & More us pot ajudar amb això s'explica al nostre advocat informàtic
