ABONAMENTE VIDEO REDACȚIA
RO
EN
NOU
Numărul 144
Numărul 143 Numărul 142 Numărul 141 Numărul 140 Numărul 139 Numărul 138 Numărul 137 Numărul 136 Numărul 135 Numărul 134 Numărul 133 Numărul 132 Numărul 131 Numărul 130 Numărul 129 Numărul 128 Numărul 127 Numărul 126 Numărul 125 Numărul 124 Numărul 123 Numărul 122 Numărul 121 Numărul 120 Numărul 119 Numărul 118 Numărul 117 Numărul 116 Numărul 115 Numărul 114 Numărul 113 Numărul 112 Numărul 111 Numărul 110 Numărul 109 Numărul 108 Numărul 107 Numărul 106 Numărul 105 Numărul 104 Numărul 103 Numărul 102 Numărul 101 Numărul 100 Numărul 99 Numărul 98 Numărul 97 Numărul 96 Numărul 95 Numărul 94 Numărul 93 Numărul 92 Numărul 91 Numărul 90 Numărul 89 Numărul 88 Numărul 87 Numărul 86 Numărul 85 Numărul 84 Numărul 83 Numărul 82 Numărul 81 Numărul 80 Numărul 79 Numărul 78 Numărul 77 Numărul 76 Numărul 75 Numărul 74 Numărul 73 Numărul 72 Numărul 71 Numărul 70 Numărul 69 Numărul 68 Numărul 67 Numărul 66 Numărul 65 Numărul 64 Numărul 63 Numărul 62 Numărul 61 Numărul 60 Numărul 59 Numărul 58 Numărul 57 Numărul 56 Numărul 55 Numărul 54 Numărul 53 Numărul 52 Numărul 51 Numărul 50 Numărul 49 Numărul 48 Numărul 47 Numărul 46 Numărul 45 Numărul 44 Numărul 43 Numărul 42 Numărul 41 Numărul 40 Numărul 39 Numărul 38 Numărul 37 Numărul 36 Numărul 35 Numărul 34 Numărul 33 Numărul 32 Numărul 31 Numărul 30 Numărul 29 Numărul 28 Numărul 27 Numărul 26 Numărul 25 Numărul 24 Numărul 23 Numărul 22 Numărul 21 Numărul 20 Numărul 19 Numărul 18 Numărul 17 Numărul 16 Numărul 15 Numărul 14 Numărul 13 Numărul 12 Numărul 11 Numărul 10 Numărul 9 Numărul 8 Numărul 7 Numărul 6 Numărul 5 Numărul 4 Numărul 3 Numărul 2 Numărul 1
×
▼ LISTĂ EDIȚII ▼
Numărul 136
Abonament PDF

Agile sau data science? De ce nu amândouă?

Ioana Barboș
Founder & Data Scientist @ Giraffa Analytics



MANAGEMENT

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.

Workflow-ul proiectelor de data science

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.

Cum pot fi adaptate proiectele de data science pentru a deveni mai agile?

Metrici

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.

Echipa diversă cu "T-shaped people"

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.

Vertical slicing vs. Horizontal slicing

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.

Estimări realiste

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.

Definirea noțiunii de "done"

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.

Scrum - "sinonim" al agilității

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.

Data Driven Scrum™ (DDS)

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

Ceremoniile în 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.

Data science should be structured fun!

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!

Referințe:

  1. Data Science Process Alliance, creatorul Data Driven Scrum

  2. https://digital.ai/resource-center/analyst-reports/state-of-agile-report/

  3. https://www.contentbloom.com/blog/how-to-apply-a-data-driven-mindset-in-an-agile-framework/

NUMĂRUL 143 - Software Craftsmanship

Sponsori

  • Accenture
  • BT Code Crafters
  • Accesa
  • Bosch
  • Betfair
  • MHP
  • BoatyardX
  • .msg systems
  • P3 group
  • Ing Hubs
  • Cognizant Softvision
  • Colors in projects

Ioana Barboș a mai scris