Il contratto di sviluppo agile: focus on

Che cos’è il contratto di sviluppo agile? In questo post, parleremo di un trend in atto nell’industria IT, basato sull’impiego delle metodologie agili e delle implicazioni nella redazione di adeguati contratti di sviluppo software.

Che cosa sono le metodologie agili?

Per metodologie agili, ci riferiamo ad un complesso di differenti metodi di sviluppo del software tra cui lo scrum e l’extreme programming, che hanno, quale trait d’union, il fatto di essere dei metodi iterativi. In altre parole, si fondano sulla presenza di cicli di sviluppo brevi e frequenti. Al termine di ogni ciclo di sviluppo, dovrebbe essere rilasciato (cd. deployment) software perfettamente funzionante.

Dov’è la differenza con il metodo di sviluppo tradizionale?

Il metodo di sviluppo software tradizionale (cd. “metodo a cascata“) si caratterizza nella suddivisione di un progetto in una sequenza di fasi successive (pianificazione, design, scrittura del codice, fase di test, rilascio). Nel metodo a cascata (cd. Waterfall development method), viene attribuita una rilevanza decisiva alla fase iniziale di pianificazione, nella quale le specifiche del progetto devono essere determinate in modo analitico.

I problemi di questo metodo di sviluppo sono stati individuati:

• nella difficoltà per il committente di stabilire, a priori, le specifiche tecniche del software da sviluppare;
• nel fatto che le specifiche, una volta determinate, sono tendenzialmente congelate.

Nei contratti di sviluppo software tradizionali, non a caso, solitamente si assegna la massima priorità alle Specifiche Tecniche (in genere contenute in un documento con un elevato grado di analiticità da allegare al contratto), inserendo clausole specifiche che limitino la possibilità di richiedere funzioni e/o elementi non previsti nelle medesime Specifiche. 

Perché una metodologia “agile”?

Come già accennato, nel sistema tradizionale, si presuppone che il Committente sia in grado di fornire allo Sviluppatore un set di richieste specifiche e ben definite. Nella prassi, tuttavia, ci si è resi conto che ciò avviene molto di rado. Ed infatti, si verifica spesso una delle seguenti situazioni:

• il Committente non ha gli strumenti tecnici e/o le competenze per determinare in modo specifico le Specifiche del prodotto da realizzare;
• il Committente non è in grado di stabilire se le Specifiche proposte dallo Sviluppatore possano soddisfare le proprie esigenze;
• il Committente (specialmente nel caso di startup), avendo un modello di business in evoluzione, potrebbe avere la necessità di richiedere, durante la fase di sviluppo, modifiche, anche strutturalmente rilevanti, dell’intero progetto.

Tutto ciò accresce il rischio di incorrere in contenziosi lunghi, difficili e costosi.

La metodologia agile, invece, mira a risolvere queste problematiche, attribuendo maggiore rilevanza all’iterazione e alla collaborazione con il cliente. Nel 2001, per fare un esempio pratico, è stato pubblicato, da un gruppo di sviluppatori software, il Manifesto per lo sviluppo agile che si fonda su dodici principi che possono così essere riassunti:

Stiamo scoprendo modi migliori di creare software,
sviluppandolo e aiutando gli altri a fare lo stesso.
Grazie a questa attività siamo arrivati a considerare importanti:

• Gli individui e le interazioni più che i processi e gli strumenti
• Il software funzionante più che la documentazione esaustiva
• La collaborazione col cliente più che la negoziazione dei contratti
• Rispondere al cambiamento più che seguire un piano
  

Ovvero, fermo restando il valore delle voci a destra,
consideriamo più importanti le voci a sinistra.

In altre parole, si passa da un rigido schema “a cascata” a un sistema fondato sulla flessibilità.

Esaminando, a titolo di esempio, la metodologia SCRUM, evidenziamo che:

• in luogo delle Specifiche, viene predisposto un documento più snello, denominato Product Backlog che contiene una elencazione non analitica delle caratteristiche del software da sviluppare;
• lo sviluppo del software viene suddiviso in vari cicli di breve durata (1-4 settimane), conosciuti come iterazioni o, più precisamente, come Sprint, in cui vi è uno scambio continuo di informazioni tra Committente e Team di Sviluppo.
• All’inizio di ogni Sprint, viene concordemente redatto un documento denominato Sprint Backlog che conterrà una elencazione di elementi (items) da realizzare in ordine di priorità, tra quelli indicati nel Product Backlog. 
• Al termine di ogni Sprint, il Team di Sviluppo consegna una versione completa e funzionante del prodotto, che conterrà le sole funzionalità stabilite all’interno dello Sprint Backlog.
• Se, per assurdo, non fossero realizzati alcuni degli Items contenuti nello Sprint Backlog, (es. per problemi tecnici o carenze di tempo), questi diventerebbero oggetto di un successivo Sprint.
• Il Committente ha facoltà di modificare in qualsiasi momento il Product Backlog, tranne che durante lo svolgimento di uno Sprint. 

Logicamente, la metodologia SCRUM prevede molte altre caratteristiche che meriterebbero un’analisi più approfondita, ma abbiamo preferito indicarne i tratti essenziali, allo scopo di introdurre il contratto di sviluppo agile.

Il contratto di sviluppo agile: come fare?

Avendo, brevemente, illustrato alcuni capisaldi della metodologia agile, dobbiamo, a questo punto, introdurre la tematica del contratto di sviluppo agile.

Come ha affermato Jacopo Romei (che, a mio modesto avviso, è uno dei massimi esperti italiani in materia), nel suo libro Extreme Contracting: 

Ora, non so quale sia la vostra esperienza solita con i contratti, ma la mia e che siano pensati e scritti per entrare in gioco quando le cose sono messe gia male, molto male. Finche la relazione tra le parti è rosea nessuno avverte l’esigenza di un contratto.

Quando qualcuno vede i suoi interessi non coccolati a sufficienza e nessuna riconciliazione sembra affacciarsi all’orizzonte, ecco che iniziano i riferimenti a clausole e avvocati.

In un sistema agile anche il contratto dovrebbe essere influenzato dal principio di base della cooperazione e della iterazione.

Sostanzialmente, dal mio punto di vista di avvocato, il contratto di sviluppo agile dovrebbe, quanto meno assolvere alle seguenti finalità.

• Individuare i ruoli delle parti e gli obblighi relativi. Ad esempio, con riferimento allo SCRUM, dove è prevista la figura del Product Owner – rappresentante del Committente, incaricato di mantenere costanti rapporti con il Team di Sviluppo – si potrebbero inserire clausole di inamovibilità, per evitarne la rimozione ingiustificata e, quindi, danneggiare il clima di collaborazione che si dovrebbe instaurare con il Team di Sviluppo.
• Determinare le caratteristiche essenziali del prodotto da realizzare. Solitamente, si allega al contratto un documento molto generico, denominato Product Vision, demandando la definizione di specifiche di dettaglio a successivi incontri congiunti tra il Committente (o suoi collaboratori) e il Team di Sviluppo.
• Disciplina dei cicli di iterazione. Ad esempio, potrebbe essere inserita una clausola specifica per la valutazione del risultato del ciclo iterativo, prevedendo, in caso di contrasti, il deferimento del giudizio tecnico a un esperto di comune fiducia delle Parti (cd. “perizia contrattuale”).
• Disciplina dei corrispettivi. Il contratto di sviluppo agile, al riguardo, potrebbe prevedere: (i) un compenso “forfettario” per ogni ciclo iterativo; (ii) un compenso orario sulla base di una tempistica stimata; (iii) un meccanismo misto (fisso + incentivi per eventuali item aggiuntivi realizzati); (iv) un primo ciclo di iterazione gratuito (a scopo promozionale), con successivi cicli a compenso fisso e così via.
• La disciplina del recesso. Il contratto di sviluppo agile, per essere tale, dovrebbe prevedere ampie facoltà di way out alle Parti. L’obiettivo è quello di stimolare la continua collaborazione, ma si dovrebbe pur sempre permettere al Committente di recedere dal rapporto nel caso in cui il risultato dei cicli di iterazione non fosse coerente con le proprie aspettative. Si potrebbe prevedere, ad esempio, un diritto di recesso libero (al termine di ogni ciclo iterativo), con caparra penitenziale. Si tratterebbe di una somma di denaro (contenuta) che assolverebbe alla funzione di “corrispettivo del recesso” e consentirebbe un equo contemperamento degli interessi delle Parti.

In conclusione, come si può vedere, il contratto di sviluppo agile richiede al consulente legale di abbandonare le strutture mentali tipiche dell’avvocato, per approcciare un metodo di redazione delle clausole più orientato ad attribuire valore al documento negoziale e nell’ottica di snellire la relazione, piuttosto che “aggravarla”.