Contratti Agile: scadenze, accettazione e responsabilità nei progetti IT

Un contratto agile formalizza una collaborazione in cui il risultato finale non è predeterminato, pertanto deve regolamentare chi stabilisce le priorità, quando il risultato di uno sprint viene accettato e se le date di consegna sono vincolanti. Secondo la legge olandese, una data di consegna in un progetto agile non è automaticamente una scadenza tassativa: il tribunale valuta il contratto, il metodo di lavoro e le modalità di effettiva collaborazione tra le parti, e persino il mancato rispetto di una scadenza tassativa non sempre giustifica la rescissione.

Nello sviluppo agile, le parti lavorano in brevi sprint e adattano il prodotto man mano che il progetto procede. Questo articolo spiega come qualificare gli obblighi del fornitore, come strutturare il contratto, cosa dice la giurisprudenza recente in materia di scadenze e cosa dovrebbero verificare clienti e fornitori.

Perché il lavoro agile richiede un contratto diverso?

Perché il risultato è un obiettivo in continuo movimento. In un progetto IT tradizionale, le parti definiscono un progetto funzionale e tecnico e il fornitore si impegna a consegnarlo entro una data prestabilita; nello sviluppo agile, ogni sprint fornisce una parte funzionante e il cliente adegua la rotta in base alle dimostrazioni.

Il contratto deve quindi definire quattro aspetti a cui una specifica tradizionale risponde già di per sé:

• Chi determina le specifiche e le priorità: il product owner lato cliente;
• come vengono elaborate le modifiche nel backlog (l'elenco prioritario delle funzionalità ancora da realizzare), la pianificazione e il prezzo;
• quando una parte viene considerata finita, in base a una definizione di fatto e a criteri di accettazione misurabili;
• se le date di consegna concordate siano tassative o indicative.

È difficile conciliare il lavoro agile con una gara d'appalto pubblica in cui l'ambito di lavoro è definito in anticipo. Un ente appaltante che desidera uno sviluppo agile dovrebbe prevedere, nei documenti di gara, la possibilità di stipulare un accordo quadro con assegnazioni di lavoro flessibili.

Si tratta di un obbligo basato sul massimo impegno o sul raggiungimento dei risultati?

Nei progetti agili, l'obbligo del fornitore è spesso qualificato come un obbligo di massimo impegno (inspanningsverbintenis), poiché non è stato concordato alcun risultato finale fisso. In base a un obbligo di risultato (resultaatsverbintenis), il fornitore si impegna a fornire un risultato specificamente descritto.

La denominazione contrattuale non è determinante: il tribunale esamina il contenuto degli accordi e le modalità operative effettive delle parti. Nel caso di un obbligo di risultato, la questione è se il risultato sia stato effettivamente conseguito; nel caso di un obbligo di massimo impegno, se il fornitore abbia dimostrato la diligenza di un professionista IT ragionevolmente competente e che abbia agito con ragionevolezza.

L'articolo 6:74(1) del Codice civile olandese (BW) costituisce la base per il risarcimento dei danni derivanti da un inadempimento imputabile, ma non specifica quando si verifica tale inadempimento; ciò dipende dalla qualificazione dell'obbligazione. Ai sensi dell'articolo 6:248(1) del BW, un contratto ha anche le conseguenze che derivano dalla ragionevolezza e dall'equità, il che lascia spazio a considerare la natura flessibile della collaborazione.

Come si struttura un contratto agile?

Solitamente strutturato su due livelli. Un accordo quadro definisce le regole generali: termini applicabili, responsabilità, riservatezza, proprietà intellettuale e modalità di collaborazione. Per ogni incarico o rilascio, un accordo di attuazione definisce l'ambito, la pianificazione, il team, il prezzo e i criteri di accettazione.

Criteri di accettazione concreti e misurabili per ogni sprint sono più importanti della semplice etichetta dell'obbligo. Senza di essi, non c'è nulla con cui confrontare il risultato e le controversie sul successo o meno di uno sprint sorgono rapidamente. È fondamentale includere una definizione di "fatto" che comprenda non solo la funzionalità, ma anche la qualità del codice, la documentazione e la trasferibilità.

La risoluzione anticipata del contratto merita maggiore attenzione rispetto a un contratto tradizionale, perché un progetto agile non ha una data di fine prestabilita. È fondamentale concordare quando ciascuna parte può interrompere il progetto, cosa accade ai componenti consegnati e al codice sorgente, e come il lavoro viene trasferito a un altro fornitore.

I termini standard IT, come ad esempio i Termini NLdigital, regolano gli aspetti agili solo in misura limitata. Verifica quale edizione si applica e formalizza le disposizioni relative alle metodologie agili nell'accordo di implementazione.

Cosa dice la giurisprudenza in merito alle scadenze?

Non esiste una regola generale secondo cui una data in un progetto agile non debba mai essere tassativa. Due recenti sentenze mostrano come il tribunale valuti il ​​contratto e la collaborazione.

Tribunale distrettuale di Midden-Nederland, 2023: termine perentorio, ma nessuna revoca

In una sentenza relativa al caso ECLI:NL:RBMNE:2023:5936, il software per un sistema di pesatura è stato sviluppato utilizzando la metodologia Scrum, con un tempo di consegna concordato di circa 24 settimane e successive date di scadenza fisse. Il tribunale ha stabilito che tali date costituivano termini perentori, pertanto il fornitore è risultato inadempiente senza aver ricevuto preavviso di inadempimento al momento della loro scadenza.

La richiesta di recesso da parte del cliente non è stata accolta. Data la natura agile del progetto, la responsabilità condivisa tra le parti e il fatto che rimanesse da completare un solo blocco di lavoro, il mancato completamento del progetto non giustificava il recesso ai sensi dell'articolo 6:265 del Codice Civile tedesco (CBD). Le richieste di rimborso e risarcimento danni sono state respinte.

Tribunale distrettuale di Amsterdam22 aprile 2026: date indicative

Nel caso ECLI:NL:RBAMS:2026:3930, un cliente ha affermato che lo sviluppatore aveva consegnato una nuova app in ritardo, superato il budget e gestito male le app esistenti. Il preventivo si basava su sprint Scrum di due settimane e una data di lancio indicativa.

Il tribunale ha riscontrato l'assenza di scadenze rigide: la data di lancio e la pianificazione dello sprint erano indicative e l'approccio Scrum richiedeva una stretta collaborazione. In assenza di una scadenza precisa, il cliente necessitava di una valida diffida, e le sue diffide non hanno reso lo sviluppatore inadempiente. Tutte le richieste sono state respinte.

La lezione: se si desidera che una data sia tassativa, è necessario specificarlo espressamente nel contratto. Una data indicata in un preventivo o in un'e-mail di solito non è sufficiente.

Che cosa dovresti verificare come cliente?

• Chi è il responsabile del prodotto e questa persona ha il mandato di modificare il backlog per vostro conto?
• I criteri di accettazione e la definizione di "fatto" sono registrati per ogni sprint o release?
• Il contratto specifica espressamente quali date sono da considerarsi termini perentori?
• Entro quanto tempo devi testare e rispondere a una consegna, e cosa succede se non lo fai?
• Quando riceverai l'accesso al codice sorgente e alla documentazione?
• Cosa viene corrisposto in caso di risoluzione anticipata e a quale prezzo?

Che cosa dovresti verificare come fornitore?

• È chiaro che le date nei preventivi e nella pianificazione sono indicative, salvo diverso accordo?
• Documentate per iscritto le decisioni del product owner e le modifiche al backlog?
• Registrate i casi in cui il cliente non fornisce input, non verifica la capacità di esecuzione o non prende decisioni nei tempi previsti? Ciò può configurarsi come inadempimento del creditore (articolo 6:58 BW).
• La modalità di pagamento è chiara: a sprint, a ore, a function point o a risultato?
• Avete limitato la vostra responsabilità ed escluso i danni consequenziali nell'accordo quadro?

Cosa possiamo fare per voi con i contratti agili?

I nostri avvocati specializzati in diritto informatico assistono fornitori e clienti IT in progetti agili. Possiamo:

• redigere o rivedere un accordo quadro e gli accordi di attuazione per un progetto agile;
• formulare criteri di accettazione, una definizione di "fatto" e clausole di scadenza chiare;
• redigere un accordo di uscita per la risoluzione anticipata e il trasferimento a un altro fornitore;
• valutare se un fornitore è inadempiente e se è possibile rescindere il contratto;
• redigere un avviso di inadempimento o una risposta ad esso, e avviare procedimenti relativi al ritardo o alla risoluzione del contratto.

Scopri di più su cosa fa un avvocato specializzato in diritto informatico.

Sintesi

• Un contratto agile di solito consiste in un accordo quadro e in accordi di attuazione per ogni singolo incarico.
• L'obbligo del fornitore è spesso un obbligo di massimo impegno; la dicitura nel contratto non è determinante.
• Criteri di accettazione misurabili e una definizione di "fatto" prevengono controversie sul successo o meno di uno sprint.
• Stabilire se una data di consegna sia un termine perentorio dipende dal contratto e dalla collaborazione, quindi è necessario specificarlo espressamente; anche il mancato rispetto di un termine perentorio non giustifica automaticamente la rescissione del contratto (ECLI:NL:RBMNE:2023:5936).
• Regolamentare in anticipo la risoluzione anticipata del contratto, il codice sorgente e il passaggio di consegne a un altro fornitore.

Domande frequenti