ABONAMENTE VIDEO REDACȚIA
RO
EN
NOU
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 69
Abonament PDF

Abordări noi în lumea Software - Interviu cu Sander Hoogendoorn

Ovidiu Mățan
Fondator @ Today Software Magazine



INTERVIU


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.

VIDEO: NUMĂRULUI 126

Sponsori

  • BT Code Crafters
  • Accesa
  • Bosch
  • Betfair
  • MHP
  • Connatix
  • BoatyardX
  • AboutYou
  • Telenav
  • .msg systems
  • Colors in projects