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ă!
de Jari Laakso
