ABONAMENTE VIDEO REDACȚIA
RO
EN
NOU
Numărul 150
Numărul 149 Numărul 148 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 50
Abonament PDF

Echipe hiperproductive

Mădălin Ilie
Cluj Java Discipline Lead
@Endava



MANAGEMENT


O echipă hiperproductivă este visul oricărui lider de echipă. Ce simplu ar fi să aplicăm un algoritm în zece pași prin care să ajungem la o echipă de zece ori mai productivă. Sau să îmbunătățim puțin comunicarea și echipa să ajungă singură în stadiul de nirvana al productivității. Cum bine știm cu toții, lucrurile nu sunt atât de simple. Acest articol își propune să prezinte câteva modalități prin care putem crea o echipă echilibrată și motivată care își cunoaște atât punctele forte cât și pe cele slabe.

Înainte de a începe aș vrea să punctez câteva idei pentru a selecta corect așteptările asupra conținutului. Cum ziceam mai sus, nu o să găsiți în acest articol rețete gen 10 pași către o echipă super-productivă. Dacă aș fi avut un astfel de algoritm, aș fi fost mult mai celebru decât acum. Și cel mai important de precizat, acest articol este destinat liderilor și nu managerilor. (Pentru cine are dubii despre diferența dintre cele două concepte, observați explicațiile vizuale de mai jos.)

Nu știu dacă mai țineți minte serialul Lost care era în mare vogă acum 8-10 ani. Fiecare episod începea cu următoarea precizare: Viewer discretion is advised. Aceasta însemna că show-ul ce urma, avea conținut care putea fi considerat ofensator de anumite persoane și aceștia luau o decizie conștientă și informată de a continua să se uite la episodul respectiv sau nu.

Același lucru îl voi spune și eu despre conținutul acestui articol: Reader discretion is advised. Articolul de față va conține limbaj explicit precum performanță, productivitate, lipsa anumitor abilități, metrici, etc., care poate fi considerat din categoria "așa ceva nu se discută" de anumite persoane.

Când vorbim despre calitate în proiectele software, vorbim de obicei de calitate din mai multe perspective. Putem vorbi de calitatea procesului de livrare în sine, putem vorbi despre calitatea testării, despre calitatea codului, arhitecturii, etc. . De foarte puține ori însă discutăm deschis despre calitatea persoanelor din echipă. Și aceasta pentru că în cazul performanței individuale, lucrurile devin foarte personale. E mult mai simplu să atacăm subiectele abstracte și impersonale precum cele enumerate anterior legate de proces, testare, cod - deși sunt tipuri de persoane care consideră codul o prelungire a propriei ființe- , dar foarte greu să ajungem la discuții punctuale legate de abilitățile individuale.

Una dintre cele mai revelatoare cărți pe care am citit-o, din zona performanței în domeniile creative, cum este cel al dezvoltării software, este Drive a lui Daniel H. Pink. Pe scurt, cartea face o paralelă între Motivation 1.0 aka Carrots and Sticks - modalitatea cea mai simplă și cea mai folosită de-a lungul timpului pentru motivarea indivizilor: dacă faci ceva bine primești o recompensă, dacă faci ceva greșit ești penalizat, și Motivation 2.0 care este mult mai complexă ca mecanism și are la baza trei concepte: Mastery, Autonomy(DETAIL) and Purpose. În esență, pentru lucrul creativ, de la un anumit punct încolo, indiferent cât de mare devine recompensa, rezultatele nu mai sunt pe măsură, ba chiar mai mult, recompensa tinde să aibă efecte negative asupra rezultatelor. Așa că atenția ar trebui orientată spre crearea unui mediu de lucru care încurajează colaborarea, recunoașterea nivelului de expertiză, încrederea că fiecare poate rezolva autonom diverse tipuri de taskuri și oferirea unui înțeles muncii pe care o depune fiecare. Deși cartea descrie foarte bine diferențele dintre cele două tipuri de motivare cu exemple concrete, bine documentate, nu relatează foarte concret și modul de creare a unui mediu de lucru favorabil pentru Motivation 2.0.

Un alt concept legat de performanța echipelor de această dată este The Bus Factor: câți membri din echipă trebuie să fie loviți de un autobuz pentru ca proiectul să ajungă în impas. Cu cât factorul tinde mai mult către 1, cu atât riscul de a nu livra proiectul la timp este mai ridicat.

În continuare, vom discuta despre cum putem crea un mediu de lucru propice pentru Motivation 2.0 astfel încât să ajungem la un Bus Factor cât mai departat de 1. Dar în loc să discutăm despre percepții subiective și modalități euristice de aplicare, vom analiza modalități concrete și obiective prin care putem face acest lucru.

Anul trecut la Qcon am asistat la o prezentare foarte interesantă numită Treat your code as a crime scene. Autorul prezentării (există si o carte pe baza subiectului), Adam Tornhill, afirmă că ar trebui să tratăm sistemul de versionare a codului (git, svn, tfs) ca un loc al unei crime și să extragem informații valoroase legate de comportamentul codului de-a lungul unei perioade de timp definite, informații care ne vor folosi apoi pentru diverse decizii legate de: zonele din care să începem o refactorizare, în ce direcție se îndreaptă codebase-ul sau modalitatea în care echipa influențează designul codului. Toată prezentarea a fost strict legată de comportamentul codului. Însă eu cred că sistemul de versionare ascunde informații la fel de prețioase legate de comportamentul membrilor din echipă.

Mai mult decât atât, cred că avem în momentul de față o mulțime de sisteme pe care le folosim (jira, sonarqube, crucible, jenkins, etc.) care oferă metrici valoroase pe care, dacă le-am corela, am avea informații și mai clare despre aptitudinile și comportamentul membrilor din echipă.

Articolul de față se va focaliza exact pe modul în care putem corela metrici din aceste sisteme și cum putem determina disfuncționalități ale echipelor și membrilor echipelor astfel încât să influențăm dezvoltarea personală în direcția corectă. Am numit aceste disfuncționalități sindroame, pentru a le prezenta și într-o forma clinică ușor de urmărit.

Sindromul Fugitivului sau Modalitatea prin care putem identifica lipsuri de bază

Simptome:

(Limbajul de specialitate psihiatrică are conotații ironice!)

Diagnostic:

Vom oferi un exemplu care să demonstreze cât de important este contextul, precum testele unitare. Vom considera și o echipă fictivă: Transformers.

Identificarea numărului de teste unitare adăugate de un membru al echipei se poate face simplu pe baza convențiilor de denumire: clasele de test încep sau se termină cu Test în denumire. Făcând mining în sistemul de versionare descoperim că Bumblebee a scris 6 teste unitare în ultimele 4 săptămâni. Ce spuneți? Este bine sau rău?

Cum afirmam și mai sus, contextul este esențial. La prima vedere, am putea spune ca 6 teste unitare în 4 săptămâni este foarte, foarte puțin. E undeva la un test la fiecare trei zile. Dar dacă ceilalți membri ai echipei nu au scris niciun test? Atunci Bumblebee este campionul testelor unitare?

La fel putem aplica și pentru CSS, Javascript, SQL, scripturi de configurare, sau orice altă activitate particulară.

Revenind acum la Bus Factor. Dacă tot codul de SQL este scris doar de o persoană din echipă, ce credeți că se va întâmpla când persoana respectivă pleacă din echipă?

Aceleași principii se pot aplica și pentru interacțiuni mai complicate cum ar fi specializarea pe anumite componente sau zone de business.

Sindromul Îmi iubesc jobul sau Monitorizarea productivității

Monitorizarea metricelor nu trebuie să fie mereu în zona de lipsuri. Putem să ne concentrăm și înspre zone pozitive cum este cazul sindromului curent.

Simptome:

Diagnostic:

Considerăm că Bumblebee a adăugat 200 de linii de cod (LOC) în ultimele patru săptămâni. Poate fi considerat un membru al echipei productiv sau nu? Cum deja ne-am învățat lecția, totul depinde de context. Dacă toți ceilalți membri ai echipei au adăugat peste 700 de linii de cod, atunci Bumblebee nu mai e chiar într-o poziție favorabilă.

Sau este? Dacă ceilalți membri ai echipei au adăugat doar boilerplate code și cele 200 de LOC ale lui Bumblebee sunt doar logică de business?

Dar cum putem măsura aceasta? Destul de simplu. Putem interoga sisteme de monitorizare a calității codului precum Sonarqube care oferă acest gen de informații. Așa că adăugăm și aceasta pe lista de diagnosticare.

Sindromul Perfecționistului sau Monitorizarea Refactorizării

Simptome:

Diagnostic:

Dacă luăm iarăși exemplul lui Bumblebee. Considerăm că Bumblebee este un adept al refactorizării. Făcând mining în sistemul de versionare descoperim că majoritatea comiturilor din ultimele 4 săptămâni implică și numeroase refactorizări. Credeți că acest lucru este benefic pentru proiect? La prima vedere am putea spune că da. Prin refactorizările făcute, calitatea codului crește, codul devine mai ușor de înțeles, de extins, etc. Dar, iarăși, haideți să vedem contextul. Dacă în ultimele 4 săptămâni numărul de bug-uri s-a triplat și aceasta este principala cauză? Sunt suficient de multe teste automate care să valideze scenariile din zonele refactorizate? Avem suficient de multe cunoștințe de business din zonele afectate de refactorizare? Contextul este esențial!

Sindromul Eu Știu Mai Bine sau Monitorizarea Calității Codului

Simptome:

Diagnostic:

Să presupunem că în ultimele două săptămâni codul scris de Bumblebee a primit 20 de defecte în Crucible și 40 de violations în Sonarqube, iar ceilalți membri ai echipei niciunul? Evident nu pare un lucru bun. Însă luând în considerare contextul, dacă motivul pentru care codul celorlalți arată așa de bine este pentru că au adăugat doar boilerplate code, iar codul scris de Bumblebee conține doar logică de business? Măcar Bumblebee își dă silința!

Sindromul Eu Nu Fac Asta sau Reducerea Comodității

Cel mai mare adversar a lui Great este Good. Zona de confort este plăcută și foarte multe persoane evită să iasă din ea și să învețe lucruri noi.

Simptome:

Diagnostic:

Dacă Bumblebee face toate merge-urile în echipă și un decepticon malefic îl elimină, proiectul va avea serios de suferit. La fel putem considera și alte activități similare: deployment, testare de performanță, folosirea anumitor tool-uri, etc. .

Sindromul Sunt Prea Bun Ca Să Fiu Real sau Monitorizarea Supra-Încrederii

Simptome:

Diagnostic:

Câteva exemple care surprind supra-încrederea:

Sindromul Suntem Agili sau Monitorizarea Angajamentului

Simptome:

Diagnostic:

Să presupunem că echipa Transformers a livrat 6 story points în sprint-ul curent. Cum vi se pare?

Un manager pentru care 6 este doar un număr ar spune că s-a livrat destul de puțin. La urma urmei, echipa cealaltă a livrat 25 de story points în aceeași perioadă de timp. Cu toții știm că motivul pentru care folosim story points, o unitate de măsură abstractă, este tocmai acela de a face să nu existe termeni de comparație cu velocitatea altor echipe. Însă managerul poate avea dreptate. Dacă echipa Transformers livrează constant 20 de story points și în sprint-ul curent doar 6, atunci e clar că este o problemă. Încă o dată, contextul este esențial.

Sindromul Suntem Agili sau Monitorizarea Acurateții Estimărilor

Simptome:

Diagnostic:

Puține echipe se uită retrospectiv la acuratețea estimărilor date. Mai ales în contextul în care story point-urile sunt ceva abstract ca unitate de măsură. Poate nu de fiecare dată merită să intrăm în detalii foarte fine să vedem dacă un user story are 3 sau 5 story points, dar cred că e important să țintim un anumit nivel de predictibilitate.

Să presupunem că avem două user story-uri, ambele estimate la 5 story points. Primul user story a presupus modificarea a două scripturi de DB, adăugarea de trei clase CSS și o clasă Java, iar pentru al doilea am adăugat doar un IF. Oare cum se compară cele două? Poate fi cazul când adăugarea acelui IF a presupus o muncă de investigare laborioasă care este comparabilă cu efortul depus în implementarea celuilalt user story, dar și acest lucru poate ascunde diverse lipsuri: echipa nu are suficient de multă experiență cu anumite tehnologii, nu are cunoștințe de business suficiente sau poate membrul echipei care a implementat task-ul nu a beneficiat de ajutorul celorlalți membri din echipă. Mereu există o explicație și cred că e o conversație care ar trebui să existe în echipă din când în când.

Sindromul Dezvoltatorului Full Stack sau Cunoașterea este Putere

Simptome:

Diagnostic:

Acest sindrom este în zona pozitivă. Acest tip de comportament ar trebui recunoscut și încurajat pentru toți membrii echipei. Dacă Bumblebee a modificat toate tipurile de fișiere în ultimul sprint (SQL, UI, deployemnt, etc.) și a comis modificări pe majoritatea componentelor proiectului, este în mod clar o persoană de valoare care merită încurajată să continue acest comportament și în același timp să fie un exemplu și pentru ceilalți membri ai echipei.

Sindormul Cuantum sau Monitorizarea Fragilității

Simptome:

Diagnostic:

Odată identificate zonele fragile se pot lua diverse acțiuni pentru remediere. Clasele respective pot fi marcate cu prioritate ridicată în timpul review-urilor de cod, se pot lua decizii de a crește acoperirea de teste unitare pe zona respectivă sau acoperirea de teste funcționale pe zonele de business care folosesc acele clase. Aceasta ar trebui să fie o decizie de echipă și orientată spre zona care aduce beneficiile cele mai multe.

Cam aceasta ar fi lista celor 10 sindroame patologice la care m-am gândit că pot fi diagnosticate relativ ușor folosind informații din tool-urile folosite de echipe. Poate vă întrebați ce legătură au toate acestea cu Mastery, Autonomy and Purpose? Cu siguranță nu recomand folosirea acestor metrici pentru măsurarea performanțelor membrilor echipei. Se poate ajunge la discuții interminabile despre ce înseamnă un număr de teste normal într-o perioadă de două săptămâni, planuri de dezvoltare personală și alte lucruri manageriale. Aceste metrici ar trebui să servească liderilor pentru a influența diverse acțiuni în echipă.

Folosind acești indicatori obiectivi, liderii echipelor pot crea mediul propice în care membrii echipelor să devină cât mai autonomi și să le ofere și ocazia să exceleze în zonele ce le cunosc cel mai bine. Să luăm spre exemplu zona de teste unitare. Observăm ca doi membri ai echipei nu sunt foarte confortabili cu a scrie astfel de teste și avem un membru al echipei care pare să se descurce foarte bine în zona aceasta. În loc să avem discuții nu tocmai plăcute în care să le explicăm cât de greu se descurcă, mai bine rugăm persoana care excelează să pregătească un training practic. Recunoaștem astfel drept expert pe cel care organizează trainingul (Mastery) și creștem autonomia celorlalți doi (Autonomy). Toată lumea are de câștigat.

Pentru partea de purpose lucrurile stau puțin mai complicat. Pentru companiile de outsourcing este foarte dificil să conectezi echipa la scopul final. Sunt prea multe nivele între . Chiar dacă nu cred că se poate ajunge într-o zonă asemănătoare cu ce se întâmplă într-un start-up, cred că putem face acțiuni care să conecteze echipa cât mai mult la end goal. E important ca echipa să primească o viziune asupra proiectului din partea product owner-ului și să fie continuu conectată la această viziune. De asemenea, e și mai important ce se întâmplă după ce proiectul merge live. Câteva detalii periodice legate de modul în care este folosită funcționalitatea vor aduce cu siguranță impuls de încredere echipei și vor avea cu toții sentimentul că efortul depus are un scop.

Bineînțeles că în practică lucrurile nu vor sta atât de simplist, dar este o bază pe care puteți construi și care vă poate oferi indicii clare și obiective cu ajutorul cărora puteți alege o direcție sau alta.

În final, totul se rezumă la genul de echipă pe care vreți să îl creați.

NUMĂRUL 149 - Development with AI

Sponsori

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