ABONAMENTE VIDEO REDACȚIA
RO
EN
NOU
Numărul 147
Numărul 146 Numărul 145 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 100
Abonament PDF

Behavior-driven development - Interviu cu Dan North

Ovidiu Mățan
Fondator @ Today Software Magazine



INTERVIU

Ovidiu Mățan: Sunteți cunoscut drept părintele BDD. Cum a început totul?

Dan North: Am lucrat ca programator la ThoughtWorks, o firmă de consultanță software, în 2003. Propuneam folosirea unui model de livrare de tip XP, folosind practici precum iterațiile, user stories, programarea în echipă, integrarea continuă, programare bazată pe teste etc. Elementul ce ieșea în evidență era TDD - programatorii credeau că scrierea de teste era destinată testerilor de rang inferior. Testerii nu agreau nici ei ideea ca programatorii să scrie teste, poate pentru că nu credeau că programatorii știau cum să scrie teste, poate pentru că le era teamă că vor rămâne fără slujbă!

Dan North - părintele BDD

Din propria experiență, știam că TDD era o chestiune de design și mai puțin de testare. Am scris un articol în 2003 (primul meu articol tech publicat!) pentru Java Developers' Journal, articol numit Test- Driven Development is not about Testing, acum pierdut în negura timpului. Am încercat să le introduc programatorilor conceptul TDD fără a folosi cuvântul "test". Am vorbit despre exemple și comportamente, dar și despre modul corect de a scrie. Programatorii au fost mai receptivi la TDD când nu am mai pomenit termenul "testare". Așa a început BDD.

Ați petrecut primii ani în calitate de consultant software ThoughtWorks. Ce ați învățat acolo în ceea ce privește modul de lucru?

Aveam deja peste zece ani de carieră când m-am alăturat ThoughtWorks, deci nu eram la început! Făceau lucrurile foarte diferit de orice loc unde lucrasem, fiind aliniați valorilor mele. Am avut marele privilegiu de a lucra cu unii dintre cei mai buni oameni din dezvoltarea software de la vremea respectivă. Erau cu mult înaintea modului în care se făceau lucrurile: erau pionieri ai metodelor agile în organizații mari; susțineau și contribuiau la proiecte open source înainte să existe GitHub sau git; susțineau și promovau activ diversitatea; creșteau rapid în dimensiune păstrând ierarhiile la nivel minim.

Am învățat și am dezvoltat multe tehnici agile cât am lucrat la ThoughtWorks, dar cel mai mult am crescut în zona de coaching de echipe, de înțelegere a modului în care funcționează organizațiile, de gestionare a procesului de release engineering, de metode ce urmau să devină Continuous Delivery (livrarea continuă). ThoughtWorks a fost fantastic, deoarece și-a încurajat oamenii să scrie și să vorbească la conferințe. În calitate de Chief Scientist la ThoughtWorks, Martin Fowler manifesta un interes personal când venea vorba de activități de coaching față de oameni ca mine care nu aveau experiență în a vorbi la conferințe.

Transformarea TDD (Test Driven Development) în BDD (Behaviour Driven Development) a fost o mișcare inteligentă cu consecințe ce au făcut BDD mai bun decât TDD. Care au fost lucrurile nou adăugate?

Dan North: BDD este diferit de TDD, dar nu neapărat mai bun. A deschis calea către designul ghidat de exemple (example-guided design) care se adresa unei audiențe noi. Pentru mine a fost mai ușor să explic și să predau acest mod de muncă. Am scris un articol numit BDD is like TDD if... care descrie diferențele esențiale. Comentariile sunt interesante - mulți specialiști agile de renume au luat parte la discuție.

Cum funcționează BDD și Agile Scrum împreună? Unde se poziționează BDD?

Dan North: Scrum este, în esență, o metodă de gestiune a lucrului pentru livrarea de software. Nu ține cont de modul cum se face munca, atâta timp cât echipa livrează, la finalul sprintului. Ceremoniile Scrum sunt menite să monitorizeze munca, să îndepărteze obstacolele, să arate care este stadiul progresului, deci BDD este potrivit dacă vrem ca munca să fie finalizată. Echipa poate folosi etapa de backlog grooming ca oportunitate în cadrul căreia să definească criteriile de acceptabilitate și scenariile pentru fiecare funcționalitate. În cadrul unui sprint, echipa poate folosi aceste scenarii și exemple pentru a ghida designul aplicației și pentru a se asigura că aplicația corespunde criteriilor de acceptabilitate.

Pandemia curentă ne-a mutat pe toți **online**. Ce oportunități și ce limitări tehnice vedeți în acest context?

Dan North: O expresie cu care rezonez este "distribuit subit" ("suddenly distributed"). Mulți oameni nu au ales să lucreze de acasă, ci li s-a impus acest lucru. Nu s-au putut pregăti pentru acest lucru; mulți nu au echipamentul corespunzător, conexiune bună sau un mediu de lucru fără elemente perturbatoare. Mulți fac jonglerii între sarcinile de acasă și cele de la serviciu, de multe ori în același timp. Este foarte solicitant!

Când oamenii se vor putea întoarce la lucru în siguranță, vom vedea un mix de lucru de acasă și de la serviciu, nu neapărat doar una dintre variante. Unii oameni iubesc să se afle în preajma altor oameni, unii preferă să fie singuri, pentru unii depinde de ceea ce au de făcut. Industria noastră are multă diversitate, deci nu are sens să vorbim despre modul de lucru al "oamenilor obișnuiți". Trebuie să avem cu toții grijă de sănătatea noastră emoțională și mentală, dar și de a celorlalți. Trebuie să ne gândim cum putem colabora cât mai bine, respectând viața privată a celorlalți și orele care nu sunt destinate muncii de birou.

Sunt impresionat de cât de bine s-au descurcat companiile de produs cu echipe distribuite ce au trebuit să colaboreze. Aplicații de conferințe video precum Zoom sau MS Teams, whiteboarduri distribuite precum Miro și Mural au crescut enorm în popularitate. Zoom a fost un coșmar din punctul de vedere al securității la începutul anului, MS Teams nu a funcționat inițial pentru grupuri foarte mari etc. Desigur, lucrurile se pot îmbunătăți, dar se poate ușor constata cât s-a investit și ce impact au avut toate aceste lucruri. Lucrul la distanță nu va putea înlocui complet colaborarea în persoană, dar este o bună metodă de lucru complementară în multe cazuri, iar avantajul de a nu face naveta, de a fi la dispoziția familiei etc. sunt semnificative.

Ce urmează după BDD?

Dan North: BDD este o modalitate prin care o echipă poate oferi cu succes software. În ultimii ani, am analizat modul în care grupuri de echipe livrează un întreg program sau modul în care se poate structura o întreagă organizație pentru colaborare eficientă și pentru livrarea continuă de calitate clienților. BDD este în continuare o metodă bună de colaborare la nivel de echipă, prin urmare, următoarea întrebare este cum să menținem acel nivel de agilitate și colaborare pe măsură ce organizația crește cu sute sau mii de oameni.

O cercetare recentă de-a mea studiază cum pot companiile de produse digitale să obțină "autonomie de aliniere" ( "autonomy with alignment"), prin intermediul unei combinații de design de organizație, leadership, gestionare modernă de produs, metode lean de livrare sau practici agile de inginerie. Este o adevărată aventură!

Conferință TSM

NUMĂRUL 147 - Automotive

Sponsori

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