Colibri cu gâtul roșu deține recordul pentru pasărea cu cea mai mare frecvență a bătăilor din aripi: 200 de bătăi pe secundă. Zborul ei fluid este un spectacol al agilității: planează, schimbă direcția, zboară cu spatele, anticipează și este precisă. Nu este doar adaptată la mediul în care trăiește, este mediul însuși.
Trăim în secolul vitezei. Contextul este atât de dinamic, lucrurile se schimbă atât de repede încât stilul de viață din copilăria noastră, când mamele puneau zacuscă pentru iarnă sau retușau pantalonii prea lungi, se cheamă acum "slow living" și renaște ca un contracurent la noua normalitate. A tinde spre agilitate este firesc pentru a rămâne relevant într-o piață dinamică. Fie că se discută despre o persoană, o echipă sau o companie, plasticitatea în fața schimbării, adaptabilitatea și colaborarea devin un fel de a fi.
Agilitatea este dezideratul multor companii, modul de lucru consacrat și eficient creat pentru echipele de software development și, paradoxal, adoptat cu mai puțin succes, de echipele de data science.
De ce paradoxal? Pentru că Agile Manifesto promovează valori necesare tranziției proiectelor de data science din zona cercetării, în valoarea adăugată produselor, deciziilor și proceselor. Cu toate acestea, multe dintre ele rămân la nivelul de simple studii, ratând menirea datelor de a deveni "actionable insights".
Ceea ce caracterizează proiectele de data science este incertitudinea. De cele mai multe ori, cerințele sunt ambigue, ipotezele testate necesită re-ajustare, pe măsura explorării datelor, noi idei ies la iveală, estimările de timp și buget deviază adesea de la plan. Îmbrățișarea acestor particularități și nu încercarea de a le înghesui într-o cutiuță, pre-întâmpinarea lor prin capacitatea organizației și a echipei de a răspunde la schimbări sunt vitale pentru reușita proiectelor de data science.
Un alt aspect important în echipele de software, însă mai puțin practicat în echipele de data science este comunicarea frecventă cu clientul sau stakeholderul. Caracterul explorator specific domeniului și, uneori, senzația lipsei de progres sau rezultate uimitoare fac tentantă amânarea interacțiunii cu clientul. Dincolo de a avea siguranța că echipa lucrează în direcția bună, transparența și feed-backul față de și de la client construiesc și consolidează încrederea acestuia în echipă, precum și sentimentul colectiv de contribuție.
La peste 25 de ani de la conceperea sa, în 1996 "de către trei veterani ai pieței tinere și imature de data mining: Daimler-Benz, SPSS și NCR", metodologia CRISP-DM este încă referința pentru abordarea proiectelor de data science. Fluxul adoptat de majoritatea echipelor de data science presupune parcurgerea a șase pași, de la: cunoașterea și înțelegerea domeniului, înțelegerea datelor, pregătirea datelor, modelarea, evaluarea și punerea modelului în producție.
Formulat într-un ghid exhaustiv de 70 de pagini, CRISP-DM este rigid cu veleități agile. Poate sursa părerilor contradictorii privind încadrarea lui în waterfall sau agile ține de gradul de flexibilitate sau modul de implementare.
De-a lungul timpului au apărut workflowuri diferite, răspunzând diversității produselor de data science, precum OSEMN sau Harvard, însă acestea sunt variațiuni ale CRISP-DM.
Atunci când se lucrează cu date, pentru a putea determina dacă lucrurile se mișcă în direcția bună, este esențială stabilirea a-priori a metricilor monitorizate. În felul acesta, se poate evalua valoarea adăugată a produsului în urma fiecărei noi iterații, se poate decide dacă un nou feature va fi inclus sau nu în varianta anterioară a produsului.
Pentru a putea îmbrățișa agilitatea, în echipa de data science este nevoie de toate cunoștințele realizării unui produs funcțional, de la asigurarea și mentenanța infrastructurii, a mediului de test și de producție, la achiziția datelor, curățarea, modelarea, punere modelului în producție, uneori dezvoltarea unei aplicații/ dashboard în care va rula modelul, monitorizarea continuă a performanței.
Din experiența proprie, membrii echipelor agile care lucrează cu date au cunoștințe generale despre majoritatea etapelor din ciclul de viață al produsului și cunoștințe aprofundate în domeniul lor de expertiză, fiind ceea ce se cheamă "T-shaped people". Colaborarea și deschiderea fiecăruia de a învăța și împărtăși are avantaje majore pe termen lung, oferind autonomie fiecărui membru și înlăturând blocajele.
Pornind de la pașii consacrați în abordarea unui proiect de data science, există două direcții potențiale care determină dacă modul de lucru tinde sau nu înspre agilitate: secvențierea fluxului de lucru pe orizontală sau pe verticală.
O secvențiere pe orizontală condiționează trecerea la pasul următor de finalizarea pasului curent: prima dată se colectează datele necesare, apoi se inspectează și se curăță datele înainte de a trece la modelarea cea mai simplă, adică o abordare tip waterfall.
Secvențierea pe verticală, inspirată din modul de lucru lean al start-upurilor presupune parcurgerea întregului flux de lucru asemenea creării unui minimum viable product, respectiv reluarea pașilor pentru fiecare nouă versiune îmbunătățită a produsului.
O modalitate mai realistă de a estima durata taskurilor în data science, decât în număr de ore necesare, ar fi ușor-mediu-dificil sau inspirat din mărimile tricourilor, S-M-L-XL. Devine utilă și atașarea estimării impactului soluționării acelui task, care ajută în prioritizare.
Când este finalizat un task? Este o întrebare care, în lipsa unui limbaj comun, suportă la fel de multe răspunsuri valide ca acei cărora li se adresează. De aceea, este practic ca membrii echipei și product ownerul (care confirmă finalizarea unui task) să vorbească un limbaj comun.
Cel mai popular framework agil este scrum, fiind adoptat de 87% din organizațiile de software.
Încurajează colaborarea oferind în același timp simplitate și structură. Presupune divizarea produsului (software) în bucățele mai mici și dezvoltarea incrementală a acestuia, în urma unor iterații de durată fixă, numite sprinturi.
Adoptarea pură a scrum în contextul data science are neajunsuri din mai multe motive. Pe de o parte, este natura ambiguă a data science și dificultatea în a estima precis durata unei activități, iar, pe de altă parte, este lucrul în sprinturi de durată fixă de timp din scrum.
DDS este un framework creat în 2019, special pentru ca echipele de data science să devină utilizatori fluenți ai agilității. Împrumută ce e mai bun din libertatea oferită de principiile lean și structura scrum.
Primul pas este crearea unei liste prioritizate de itemi, care sunt de fapt idei/experimente ordonate în funcție de impactul potențial și valoarea adăugată produsului, respectiv efortul echipei pentru realizarea experimentului. Aceasta se numește item backlog.
Unitatea de bază în DDS este iterația, parcurgerea unui ciclu de la idee la increment. În DDS, iterațiile nu au o durată de timp fixă, pre-determinată, ci permit variabilitate în funcție de complexitatea cerinței abordate. Durata maximă recomandată a unei iterații este de o lună, însă ea poate fi chiar și o zi.
De aceea, are sens deconectarea iterațiilor de ceremoniile echipei, o altă adaptare a scrum pentru data science.
În cadrul unei iterații se abordează unul sau mai mulți itemi din backlog, în funcție de complexitatea experimentului și a capacității echipei. Obiectivul fiecărei iterații este concentrarea eforturilor echipei pentru obținerea unei versiuni funcționale, îmbunătățite a produsului.
DDS propune ca taskurile aferente fiecărei iterații/experiment să fie etichetate obligatoriu cu un scop dintre: Create-Observe-Analyze, corespunzător tipului său, dar și să existe minim un task purtător al fiecărei etichete. Iterația trebuie finalizată prin finalizarea taskurilor de analiză.
Astfel, fiecare item este fragmentat în taskuri cu specific de creare, observare și analiză, plasate în coloana "to do" a unui visual board, de unde urmează drumul clasic: in progress, open for verification, done. Pentru a înlătura blocajele se implementează limitarea work-in-progress, la fel ca în kanban.
Figură 2: Exemplificarea grafică a fluxului DDS
Selecția itemului din backlog are loc după finalizarea fiecărei iterații și se referă la selecția următorului item de prioritate maximă de pe listă. Backlogul trebuie văzut ca un organism în continuă schimbare, noi itemi ajung pe listă în urma închiderii experimentului curent, lista este revizuită și itemii reprioritizați.
Întâlnirile zilnice urmează structura stand-up din scrum, 15 minute care ajută echipa să reflecte la munca din ziua anterioară și să își planifice ziua curentă, evidențierea blocajelor.
Review-ul iterației poate avea loc săptămânal și este momentul întâlnirii cu product ownerul, stakeholderii pentru a discuta rezultatele iterației, plusul de performanță observat a fi adus produsului prin analiza bazată pe metrici. Pot să apară noi idei de experimente, care sunt puse în item backlog și prioritizate.
Retrospectiva are loc o dată pe lună și urmează structura retrospectivei din scrum. Echipa discută dificultățile apărute, se urmărește îmbunătățirea procesului, astfel încât echipa să câștige fluență în muncă și colaborare.
Agilitatea vine ca o mănușă proiectelor de data science, atunci când modul de lucru este structurat, dar flexibil. Data Driven Scrum este o variantă despre care pot afirma cu încredere că, implementat corect, funcționează în practică, nu doar pe hârtie, facilitând calea de la idee la produs. Vă încurajez să încercați DDS în echipele voastre dacă sunteți parte dintr-un proiect de data science și dacă simțiți că proiectul la care lucrați bate pasul pe loc, că haosul vă acaparează ziua de muncă, că solicitările continue vă ucid creativitatea și productivitatea. Data science should be fun!
de Nóra Dobre
