AGILE development: ce trebuie să știm atunci când contractăm dezvoltare de software în regim agile?

Radu face parte din departamentul de Tehnologie, Media şi Telecomunicații al societatii de avocati bpv GRIGORESCU STEFANICA, oferind consultanță pe probleme de drept clienților din industria IT, media şi telecomunicații, precum şi cu privire la măsurile necesare ȋn vederea conformării cu noul Regulament General privind Protecția Datelor. El oferă de asemenea consultanță şi cu privire la alte aspecte de drept comercial şi de proprietate intelectuală.

Acesta deține acreditarea internațională CIPP/E (Certified Information Privacy Professional/Europe) conferită de IAPP (International Association of Privacy Professionals), una dintre cele mai proeminente certificări din lume ȋn domeniul protecției datelor.

Simplificând conceptul, procesele agile implică o dezvoltare flexibilă şi iterativă a software-ului dorit, fiecare iterație reprezentând un așa zis „produs potențial a fi livrat” – i.e. un modul software funcțional de sine stătător. Această abordare iterativă cu privire la dezvoltarea de software a fost creată pentru a se putea adapta mai bine la cerințele clienților care se modifică ȋn mod constant, precum şi pentru a livra produse de înaltă calitate printr-o inspecția şi analiză continuă a software-ului de urmează a fi dezvoltat, colaborare continuă între echipele multi-disciplinare şi un răspuns prompt la schimbare. 

Pe scurt: agile înseamnă să livrezi clientului ce își dorește, chiar dacă el nu știe încă asta.

Acest model nu este, însă, fără obstacole pentru avocați. Una din valorile principale ale dezvoltării de software agile, şi probabil cea care îi sperie cel mai mult pe profesioniștii din domeniu juridic, este: „colaborarea cu clientul prevalează negocierii de contracte”, de aici si paradoxul. Întrebarea cu care ne confruntăm cel mai des ȋn aceste situații este: cum pot părțile să aibă flexibilitatea modelului agile, păstrând totodată același nivel de protecție ca şi ȋn contractele standard de tip cascadă (ȋn engleza „waterfall model”)?

Acest articol intenționează să prezinte o imagine de ansamblu asupra celor mai importante aspecte legate de redactarea unor contracte de dezvoltare de software agile. Pentru exemplificare, ne vom concentra pe metodologia SCRUM, dar majoritatea conceptelor prezentate aici se aplică la întreg conceptul agile şi nu sunt limitate doar la SCRUM.

Răspunsul pe scurt: DA!

Cheltuielile efectuate cu redactarea contractelor nu sunt pe lista de dorințe a niciunui dezvoltator sau client care dorește să migreze către modelul de dezvoltare de software agile, ȋn special dacă au deja un contract standard de dezvoltare software de tip cascadă. De ce nu poate fi adaptat acest contract la noul model, dacă obiectul acestuia este identic: dezvoltarea de software?

Adevărul este că diferențele dintre modelul de tip cascadă şi modelul agile sunt considerabile, iar adaptarea unui contract care a fost conceput special pentru modelul de tip cascadă va putea lăsa părțile expuse la diverse riscuri dintr-o perspectivă legală.

Această secțiune se va concentra doar pe aspectele specifice contractelor de dezvoltare de software agile, precum principalele roluri din proiect, procedura de sprint, recepția, răspunderea etc.

Scrum Master (antrenor agile)

• poate fi un angajat al clientului, al dezvoltatorului sau al unei terțe părți;
• rolul Scrum Master-ului constă, ȋn principal, ȋn obligația de a sprijini Product Owner-ul şi echipa de dezvoltare (asemenea unui antrenor);
• Scrum Master-ul nu are nicio autoritate asupra echipei de dezvoltare sau a Product Owner-ului, dar trebuie să se asigure că fiecare dintre aceștia cooperează ȋn cel mai eficient mod posibil şi că aceștia nu întâmpină obstacole care ar putea afecta procesul de dezvoltare de software.

Product Owner

• este reprezentantul cheie al clientului;
• este responsabil pentru comunicarea ȋn mod clar a obiectivelor proiectului (i.e. cerințele clientului) echipei de dezvoltare;
• este responsabil pentru redactarea şi revizuirea continuă a product backlog;
• este responsabil pentru redactarea şi revizuirea continuă a planului de lansare ȋn producție;

Echipa de dezvoltare

• de obicei este formată din angajați ai dezvoltatorului (dar pot include şi angajați ai clientului)
• este responsabilă pentru dezvoltarea efectivă şi testarea software-ului;
• este responsabilă pentru estimarea efortului necesar pentru dezvoltarea fiecărui articol din product backlog;

Orice contract de dezvoltare de software agile ar trebui să identifice rolurile cheie din fiecare proiect, precum şi obligațiile corespunzătoare fiecărui membru din echipa de proiect. In principiu, orice astfel de contract ar trebui să includă următoarele roluri şi obligații:

Pe durata unui contract agile, software-ul este dezvoltat in iterații, numite şi „sprinturi”. Durata fiecărui sprint este la discreția părților, dar este ȋn general între 2 şi 4 săptămâni. Un sprint începe de obicei cu o întâlnire de planificare a respectivei iterații (denumită şi „sprint planning meeting”) şi încetează cu recepția şi revizuirea livrabilelor (denumită şi „sprint review meeting”).

Deși ȋn practică există diverse discuții cu privire la dacă procedura de sprint ar trebui să fie obligatorie între părți (spunându-se că o abordarea prea rigidă a procedurii de sprint ar fi incompatibilă cu modelul agile), noi considerăm că până la un anumit punct este recomandabil ca aceasta procedură să fie obligatorie pentru părți, deoarece acest lucru va defini mai bine răspunderea fiecărei părți ȋn cazul ȋn care proiectul nu progresează după cum s-ar fi dorit.

De exemplu, întâlnirile de planificare şi cele de revizuire ar trebui definite ȋn mod clar ȋn orice contract de dezvoltare de software agile, pe când întâlnirile zilnice ar putea fi lăsate la latitudinea echipei de dezvoltare, pentru a permite flexibilitate şi management al timpului mai bune pentru fiecare sprint individual.

In procesele SCRUM, această „definiție” reprezintă modelul de referință după care va fi măsurat fiecare livrabil dezvoltat ȋn cadrului unui sprint, pentru a se putea determina dacă acesta satisface cerințele clientului. Aceasta definiție este de o importanță majoră, întrucât va putea deschide calea unei potențiale răspunderi viitoare a dezvoltatorului. Ea trebuie redactată şi negociată cu mare atenție încă de la începutul proiectului, pentru ca ambele părți să aibă o înțelegere unitară cu privire la ce înseamnă „gata” ȋn ceea ce privește software-ul livrat. De exemplu, această definiție poate menționa că software-ul a trecut toate testele funcționale/non-funcționale ale clientului, criteriile de acceptare pentru fiecare articol din product backlog au fost îndeplinite etc.

Ȋn principiu, întârzierea nu este un concept uzual in proiectele SCRUM. Acest lucru se datorează faptului că viteza (aceasta fiind reprezentată prin numărul de articole din product backlog pe care echipa de dezvoltare le poate dezvolta ȋntr-un sprint) este de obicei variabilă. Dacă anumite articole nu ar putea fi dezvoltate ȋn cadrul unui sprint, acestea se întorc ȋn product backlog şi sunt prioritizate pentru următoarele sprinturi. In acest sens, avocații deseori ajung ȋn situația ȋn care evită să stabilească o răspundere specifică pentru întârzieri, bazându-se pe celelalte dispoziții contractuale, precum obligațiile ce revin fiecărei persoane implicată ȋn proiect de a se organiza şi a se adapta corespunzător, pentru a livra cu maximă eficiență şi la timp.

Acest lucru nu înseamnă, însă, că consecințele întârzierii nu pot fi abordate ȋn contract ȋntr-o altă formă. De exemplu, ȋn multe situații viteza echipei de dezvoltare poate fi determinată cu mare precizie. In acest sens, deși reperele şi termenele fixe sunt deseori descurajate, anumite garanții cu privire la viteza minimă a echipei ar putea fi folosite pentru a acoperi aceste lacune. Cu toate acestea, avocații ar trebui să aibă mare grijă la cum redactează astfel de clauze, pentru a se asigura că până şi viteza garantată permite o anumită flexibilitate necesară modelelor agile. Redactarea unor dispoziții prea rigide ar conduce la blocaje ȋn cadrul proiectului.

Ȋn fine, modelele agile se bazează foarte mult pe colaborarea între părți. Existe multe aspecte pe parcursul relației contractuale care ar putea isca dispute, precum: dacă o iterație îndeplinește criteriile prevăzute de „definition of done”, dacă efortul estimat de echipa de dezvoltare este rezonabil şi respectă standardele industriei etc. Desigur, ȋn orice contract părțile vor încerca să rezolve aceste conflicte ȋn mod amiabil, dar ȋn cazul ȋn care acest lucru nu e posibil ele trebuie să se adreseze instanțelor.

Ȋn modelele agile, având ȋn vedere livrarea incrementală, o astfel de abordare ar conduce la blocaje semnificative ale proiectului. Ȋn acest sens, un mecanism de rezolvare a conflictelor având mai multe grade este esențial contractelor de dezvoltare de software agile. De exemplu, orice conflict ce nu poate fi rezolvat între Product Owner, Scrum Master şi echipa de dezvoltare ar trebui transmis spre rezolvare către middle management-ului, iar ȋn cele din urmă către top management-ului părților. Solicitarea opiniei unui expert este, de asemenea, o abordare recomandată ȋn cadrul contractelor de dezvoltare de software agile, întrucât majoritatea conflictelor au o natură tehnică.

Migrarea de la modelul de dezvoltare software tip cascadă spre modelul de dezvoltare agile, impune clienților şi dezvoltatorilor să se asigure că există mecanisme contractuale adecvate care reflectă ȋn mod precis noua metodologie de dezvoltare software. Având ȋn vedere diferențele majore dintre cele două modele, adaptarea contractelor clasice de dezvoltare software tip cascadă nu este recomandată, deoarece va există mereu riscul unor lacune cu privire la protecția conferită părților.

Dacă rolurile şi procedurile reprezintă nucleul oricărui contract de dezvoltare software agile, colaborarea părților reprezintă învelișul acestuia. Conflictele trebuie tratate ca o parte obișnuită a procesului şi trebuie rezolvate amiabil prin mecanisme adecvate, fără ca acest lucru să blocheze progresul.

Modelul agile este o poveste de succes care va continua și ȋn viitor. Rămâne ȋn sarcina profesioniștilor din domeniul juridic să se asigure că aceste contracte pot ține pasul cu schimbările rapide din sectorul tehnologic. La urma urmei, flexibilitatea nu înseamnă absolut nimic fără mecanisme de protecție adecvate.