Ne aflăm la Agile Mammoths Games și avem ocazia de a-i adresa câteva întrebări lui Sander Hoogendoorn. Prezentarea sa a arătat cum putem să schimbăm modului în care mergem cu un produs live, planificăm următorul release sau ne organizăm echipele astfel încât să fim mai eficienți și mai naturali.
Aţi vorbit despre componentele mici și despre paradigma CNQ care este destul de complexă. Cum vedeţi posibilitatea de a lucra în echipe mici și cu componente mici comparativ cu metoda clasică de a lucra șase luni pentru a livra un proiect?
Sander Hoogendoorn> Am început să lucrăm la această abordare acum 6-7 ani și am devenit din ce în ce mai buni. Ciclurile au devenit mai scurte. Dacă vă uitaţi la abordarea Waterfall, aveţi un ciclu mare, cu o echipă mare împărţită pe mai multe discipline. Am învăţat din această experienţă și ne-am îndreptat spre Agile unde avem o echipă multi-disciplinară, ai cărei membri lucrează în cicluri scurte. Ciclurile devin din ce în ce mai scurte. Momentan, lumea se schimbă atât de repede datorită tehnologiei. Priviţi la ceea ce facem: trimitem mașini pe Marte, avem roboţi, deci ne schimbăm foarte repede. Pentru software development, acest lucru presupune și că trebuie să ţinem pasul, deorece, dacă suntem o companie lentă, alţii vor profita, ne vor lua locul făcând lucrurile mai repede și mai bine. Mai mult, companiile pot opta pentru a se dezvolta în industrii specifice. Tehnologia Cloud, de exemplu, are capacitate și posibilităţi de stocare mari pentru a face mai multe lucruri cu bani mai puţini, deoarece nu trebuie să menţineţi toată infrastructura singuri. Trebuie să fim mai rapizi, trebuie să construim lucrurile mai mici. A avea componente mai mici înseamnă a modulariza obiectivul. Acest lucru presupune că ne vom orienta spre microservicii, deoarece astfel putem livra mai rapid fără a submina complexitatea. Ciclurile vor deveni mai scurte. Când facem livrarea continuă, putem micșora ciclurile și iteraţiile. Tot ce trebuie să faceţi este să luaţi câte un element din listă. O echipă mică ( doi programatori, doi testeri, un desginer UX și un Product Owner) lucrează la o funcţionalitate, termină dezvoltarea, apoi trece la următoarea funcţionalitate. După ce aţi trecut prin acest proces iterativ o bucată de timp, veţi ajunge treptat la livrare continuă, ceea ce înseamnă că veţi merge dincolo de Agile și veţi fi mai rapizi. Trebuie făcut acest lucru, deoarece, dacă nu o veţi face voi, o vor face alţii.
Sander Hoogendoorn
Sunt de acord. Aţi menţionat ceva foarte interesant în legătură cu livrarea continuă : faceţi proiectul, lucraţi la MVP, apoi adăugaţi noi funcţionalităţi. Ne puteţi da mai multe detalii?
Sander Hoogendoorn> Abordarea tradiţională, clasică de a face proiecte în industrie este una cu timp fix de realizare. Stabilim timpul de lucru, banii și oamenii de care ai nevoie și funcţionalitatea pe care trebuie să o dezvoltăm. Această metaforă nu se potrivește industriei noastre. Problema ţine de faptul că, dacă încerci să planifici, dacă faci un design detaliat, acesta se va schimba în timp. Cu cât e mai lungă perioada și cu cât e mai lung și mai mare proiectul, cu atât mai mari sunt șansele ca proiectul să se schimbe. Prin urmare, marea diferenţă dintre software development și alte industrii este că, dacă construiţi o casă, și să zicem că aţi construit primul etaj, apoi spuneţi 'Hey, vreau un subsol', trebuie să săpaţi totul pentru a-l construi. În software development, puteţi spune 'Voi construi sub acest nivel; voi schimba arhitectura' și puteţi face asta pentru că este software. Software-ul se comportă foarte diferit comparativ cu alte discipline din inginerie. Este un domeniu foarte creativ, iar pentru că este foarte creativ și se schimbă mereu, trebuie să nu mai faceţi proiecte și să începeţi să construiţi soluţii. Dacă vă uitaţi la telefonul vostru, probabil aveţi aplicaţii a căror versiune apare la fiecare 2 zile. Vedeţi, ne îndreptăm spre această metaforă, deoarece cealaltă pur și simplu nu se potrivește.
În general, oamenii vorbesc despre Agile într-un mod învechit. Vorbind de echipe, Spotify a avut un succes enorm. Oamenii au început să îl urmeze. Puteţi să ne explicaţi de ce este bine să urmăm acest model?
Sander Hoogendoorn> Funcţionează pentru orice model, fie că e Scrum, Spotify sau Safe … toate aceste abordări au elemente bune. Fiecare proiect este diferit, fiecare echipă este diferită. Acest lucru presupune că a copia modelul altcuiva, s-ar putea ca acesta să nu funcţioneze pentru voi. Trebui să gândiţi pentru voi. Trebuie să îmbunătăţiţi ceea ce faceţi. Prin urmare, cel mai bine este să luaţi elemente din toate aceste modele și să le combinaţi astfel încât să funcţioneze pentru compania voastră.
Referindu-vă la echipe, aţi vorbit și despre echipele 'fără reguli'. Aţi dat exemplul unei străzi din Amsterdam fără reguli de trafic. Cum se organizează echipele voastre?
Sander Hoogendoorn> Echipele se organizează diferit și depinde de fiecare echipă. Pentru ca oamenii să fie eficienţi într-o echipă, voi trebuie să facilitaţi acest lucru. Trebuie să creaţi un mediu sigur, un mediu unde oamenii pot vorbi, unde oamenii își pot exprima opinia, unde se pot critica unii pe alţii fără a se simţi atacaţi. Trebuie să le daţi oamenilor încrederea de care au nevoie în permanenţă. Mai mult, deoarece ciclurile sunt atât de scurte în software development, importanţa unei decizii este mai mică. Dacă iau o decizie azi, voi putea observa dacă aceasta este greșită chiar în ziua respectivă sau ziua următoare. Voi putea repara rapid greșeala. În proiectele clasice, deciziile se iau pentru a afecta următorii doi ani; în proiectele curente, deciziile se iau pentru ziua următoare. Dimineaţa aceasta am avut o discuţe cu echipa mea despre modul de conectare a utilizatorilor la conturile lor: fie prin nume de utilizator, fie prin adrese e-mail. Jumătate a votat pentru prima opţiune, iar jumătate a votat pentru a doua opţiune. Vom alege o opţiune. Dacă va merge, va fi bine; dacă nu, vom schimba abordarea.
Poate le putem face pe ambele să funcţioneze.
Sander Hoogendoorn> Aceasta este o altă opţiune. Totul trebuie să rămână creativ. Astfel, oamenii se vor simți bine în echipele lor. Ei vor dori să lucreze pentru tine, nu pentru competiţie.
Mi-aţi răspuns la toate întrebările. Cum vă simţiţi la Cluj? V-a plăcut conferinţa?
Sander Hoogendoorn> Da, mi-a plăcut, deși multe sesiuni au fost în română. Aceasta mi-a permis să scriu cod, deoarece este activitatea mea favorită. Mi-au plăcut prezentările. Cred că prezentarea mea a fost bine primită și sper să vizitez orașul în această seară sau mâine.
Sunteţi pentru prima oară în România?
Sander Hoogendoorn> Nu, sunt pentru a doua oară aici. Am fost la un curs în Iași acum doi ani și sper să revin.
de Ovidiu Mățan
de Ovidiu Mățan
de Ovidiu Mățan
de Ovidiu Mățan
