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

Trend-uri Agile - Interviu cu Henrik Kniberg

Ovidiu Mățan
Fondator @ Today Software Magazine
INTERVIU


Ovidiu Măţan: Vorbim cu Henrik Kniberg din Suedia. Salut, Henrik. Am urmărit prezentarea ta despre Agile. A fost foarte interesantă. Graficul despre valoare vs. Efort mi s-a părut foarte elocvent. În proiectele tradiţionale, ne axăm pe cât de mult muncesc oamenii sau pe cât produc, dar nu pe valoarea a ceea ce produc. Le puteţi spune cititorilor mai multe despre acest lucru?

Henrik Kniberg: Vorbind de această tendinţă, am constat că multe proiecte și organizaţii se axează pe rapoarte ce ţin de gestionarea timpului sau de utilizarea resurselor. Există o preocupare ca oamenii să fie ocupaţi să facă ceva. Nu este un mod productiv de a ne raporta la un anumit produs dacă lucrezi într-un domeniu complex, deoarece, dacă găsiţi o persoană care rezolvă problema în jumătate din timp, este mai bine. Este mai bine ca o persoană să lucreze mai puţin. Când aplicaţi o metodă precum Scrum care este populară, veţi ieși din acest mod de gândire. Scrum se centrează pe viteză/velocity. Măsuraţi cât produceţi într-un sprint, nu câte ore petrec oamenii făcând lucruri. Deci, metodele Scrum și Agile te fac să nu te mai orientezi pe efort, ci pe rezultat. Kanban se axează pe timpul petrecut de la un capăt la altul. În Scrum, Agile și Kanban, te uiţi la activitatea în sine, nu la numărul de ore petrecute, ceea ce este un pas în direcţia cea bună, dar multe companii se opresc aici. Doresc să evidenţiez că cele mai de succes companii pe care le-am văzut, duc totul un pas mai departe și spun: "De ce să îmi pese de viteză? Aici am o echipă cu velocitate mai mică decât cealaltă echipă, dar prima echipă aduce mai multă valoare. A reușit să rezolve problema clientului cu mai puţine feature-uri." Acesta este genul de evoluţie pe care îl constat și pe care vreau să îl promovez.

Ovidiu Măţan: Cum se măsoară valoarea? Cum pot oamenii deveni conștienţi de valoarea unui task? Cum își aleg oamenii taskuri?

Henrik Kniberg: Aceasta este una din provocări. Faptul că este un lucru mai greu de capturat ne face să ne bazăm pe măsurarea orelor sau a vitezei, deoarece este mai ușor. Valoarea este mai dificil de măsurat, dar nu este știinţă atomică. Putem să ne uităm cum o fac celelalte companii. Spotify, o companie cu care petrec mult timp, se axează pe utilizatorii activi per lună (monthly active users sau MAU) și observă în ce măsură, dacă facem un feature așa sau altfel, există vreun efect asupra modului în care se folosește produsul. Trebuie investit în infrastructură pentru acest lucru. Dacă este vorba de un proiect software, nu este atât de greu, deoarece puteţi măsura acest lucru. Dacă este vorba de un produs web, este ușor. Sunt multe tooluri pentru asta, dar acesta este doar un prim aspect. Reversul medaliei este mai personal. Asiguraţi-vă că cei care construiesc produsul iau contactul cu utilizatorii reali. Ar putea să lucreze la suport pentru a vedea care sunt plângerile utilizatorilor. Ar putea vedea niște videouri cu utilizatori noi care încearcă să utilizeze produsul. Astfel, programatorii pot înţelege cine sunt utilizatorii și unde au ei probleme. Acei programatori vor avea în vedere mai mult problemele utilizatorilor.

Ovidiu Măţan: Aţi devenit mai cunoscut odată cu modelul Spotify. Ne spuneţi mai multe despre acesta?

Henrik Kniberg: Nu am creat modelul Spotify, dar am ajutat la definirea acestuia. Fac parte din organizaţie de ceva vreme și sunt fascinat de cultura acesteia. Este prima companie cu o cultură Agile autentică. Nu totul este perfect Agile, dar cultura companiei are la bază Agile. Această abordare s-a răspândit deoarece îi inspiră pe oameni. La Spotify totul este orientat spre autonomie și încredere, dând echipelor abilitatea de a lua decizii. Acest lucru este atractiv pentru oameni. Companiile care activează în domenii complexe, într-o lume în schimbare, își dau seama că metoda comandă-control este un mod decizional de sus în jos care nu este potrivit deoarece este prea lent.

Ovidiu Măţan: În ce proiecte nu se aplică Agile?

Henrik Kniberg: M-aș uita la complexitate. Proiectele simple sau repetitive (creaţi campanii web, vreo 20 pe săptămână) nu au nevoie de Agile deoarece orice ai face, acel lucru probabil funcţionează deja. Dacă lucrezi într-un domeniu complex unde nevoile clientului sunt neclare sau unde tehnologia este neclară sau tinde să se schimbe, chiar ai nevoie de Agile. M-aș uita la complexitate.

Ovidiu Măţan: Ne-aţi dat un exemplu cu copii și voluntari pentru a ne arăta ce înseamnă a avea resurse. Ne-aţi arătat diferenţa dintre o autostradă blocată și una normală.

Henrik Kniberg: Acel demo ne arată ce se întâmplă când ne axăm pe a ţine oamenii ocupaţi. Același lucru se întâmplă pe o autostradă plină de mașini. Am vrut să demonstrez această greșeală mentală. Dacă îngheţaţi imaginea plină de mașini a unei autostrăzi, totul pare eficient. Aţi umplut autostrada cu mașini și funcţionează 100%. Este grozav, dar orice programator știe că a folosi procesorul la 100% este foarte rău. Totul este folosit eficient, dar totul este lent, deci nu ne dorim așa ceva. Principiul "pull" (tragere) rezolvă blocajul într-o anume măsură. De exemplu, în Scrum, la Sprint planning meeting, echipa trage niște stories din backlog. Dacă trag prea multe, nu vor termina munca. Vor învăţa din aceasta, iar data viitoare vor trage mai puţin. Totul devine un sistem care se ajustează pe parcurs, ca să ai suficiente elemente într-un sprint. Trebuie limitat numărul mașinilor de pe autostradă. Nu folosiţi "primul venit, primul servit". Stabiliți prioritățile în funcţie de valoare.

Ovidiu Măţan: Ne-aţi dat exemplul avionului realizat cu metodologia Agile. Acesta nu este un proiect IT, dar este complex. Cum s-a aplicat metodologia în acest caz?

Henrik Kniberg: Nu am lucrat la acel proiect, dar am vizitat echipa timp de o zi. Am citit și un articol despre proiect. Informaţia mea e limitată, dar ce am văzut m-a surprins, deoarece este cel mai de succes proiect de avioane de luptă realizat vreodată ca performanţă și preţ. Toţi membrii echipei au devenit colocatari și toţi au folosit Scrum, chiar și cei de la fuselaj sau achiziţii. Piloţii au conlocuit cu echipele, deci piloţii încercau software-ul scris de echipă în aceeași zi. Echipa a primit feedback foarte repede. Cel mai important factor care a contribuit la succes a fost colocaţia, Scrum cu feedback rapid și piloţi încercând software-ul zilnic. Un avion de luptă conţine mult software.

Ovidiu Măţan: La final, ne-aţi dat un exemplu cu modul în care aţi organizat un barbecue acasă. Aţi făcut o listă cu ce trebuie făcut, iar invitaţii au ales ce doresc să facă. Cum se compară această experienţă cu modul tradiţional de a le spune oamenilor ce este de făcut?

Henrik Kniberg: Am experienţă cu petrecerile barbecue la mine acasă. Am încercat multe modele, inclusiv comandă și control. Am organizat o petrecere barbecue și am avut mai mulţi invitaţi decât m-am așeptat. Mi-am dat seama că planul meu iniţial nu va ţine, deci am făcut un panou Scrum a ceea ce vrem pe masă (carne, fructe, băuturi) după priorităţi. Invitaţii au ajuns. I-am rugat să se grupeze, să pună un carton, să facă acel lucru și să apeleze la mine dacă au nevoie de ceva. Eram precum un Scrum master. Nu le spuneam oamenilor ce să facă. Oamenii s-au organizat. Funcţionează surprinzător de bine. Inivitaţilor li se pare distractiv. Iau taskuri distractive, toţi au același scop, iar eu nu trebuie să controlez oamenii. Eu doar îi ajut, deci este ca un model servant-leadership. De asemenea, mi-a dat mai mult timp de socializare.

Ovidiu Măţan: Voi încerca și eu. În ce a constat hackingul?

Henrik Kniberg: Erau mulţi copii mici la petrecere. Ei se uitau la panou, la adulţi și se întrebau ce se întâmplă. Copiilor li s-a aprins becul: tot ce apare pe panou chiar se întâmplă. Copiii au hăckuit sistemul. Au pus bileţele cu îngheţată. Adulţii au fost nevoiţi să aducă îngheţată. A fost un moment "Aha" pentru mine, deoarece principiile Agile sunt foarte puternice. Chiar și un copil de trei ani a înţeles aceasta fără explicaţii.

Ovidiu Măţan: Mulţumesc foarte mult, Henrik.

Henrik Kniberg: Mulţumesc.


VIDEO: NUMĂRULUI 125

Sponsori

  • BT Code Crafters
  • Accesa
  • Bosch
  • Betfair
  • MHP
  • Connatix
  • BoatyardX
  • AboutYou
  • Colors in projects

VIDEO: EXTRA