Identificarea blocanților este modul în care rezolvați provocările ca o echipă
Povestea unei întâlniri „scrum” pentru un inginer de software este destul de standardizată: fiecare dezvoltator își listează munca din ziua anterioară, ce vor face astăzi și descriu dacă a întâlnit vreun blocant.
„Scopul acestei întâlniri” este de a permite membrilor echipei să împărtășească contextul. Metodologiile agile doresc ca dezvoltatorii să trăiască în „starea de flux”: productivitate maximă cu distrageri minime. Dar cum pot face asta și să fie totuși parte dintr-o echipă?
Cum se coordonează dezvoltatorii cu colegii lor? Cum pot managerii să urmărească ceea ce se întâmplă și să alinieze resursele pentru a rezolva problemele? Cum poate un proprietar de produs să identifice un risc în proiectul său? Asta ar trebui să rezolve o întâlnire zilnică de scrum - și de ce există blocante.
Cu toate acestea, dezvoltatorilor le este adesea greu să spună că sunt blocați. De ce este asta?
Reducerea impactului ego-ului tău
Dezvoltatorii pe care îi cunosc sunt mândri de munca lor și le pasă de realizările lor, precum și de reputația lor printre alți dezvoltatori. Munca lor zilnică este să înțeleagă o problemă și să o depășească, deci ce înseamnă să fii blocat?
Indiferent dacă dezvoltatorul implementează o nouă caracteristică, încearcă să identifice cauza unei erori sau se integrează cu un nou sistem, munca zilnică de programare este aceeași. Dezvoltatorul se uită la o problemă suficient de mult, încearcă diverse soluții și, în cele din urmă, ajunge la o concluzie care le permite să treacă la următoarea sarcină.
Pentru unii dezvoltatori, a fi blocat se simte la fel ca a nu putea funcționa. Poate fi ca și cum ai recunoaște înfrângerea să spui că o persoană nu poate rezolva o problemă. Nu ajută cu nimic dacă managerii și colegii de echipă se încruntă și geme de fiecare dată când un blocator este anunțat.
Ceea ce trebuie să facem este să reducem stigmatizarea în jurul identificării unui blocant. Să examinăm câteva modalități de a aborda acest lucru.
Recunoașterea blocanților în activități obișnuite
Prima sarcină importantă este schimbarea asocierii mentale a cuvântului „blocant”. Ajutați-vă echipa să înțeleagă că ne confruntăm cu blocanți în fiecare zi – chiar și provocările banale ar trebui considerate blocante, deoarece ne afectează productivitatea.
- Dependențe— Când așteptați o dependență, sunteți blocat, chiar dacă știți exact cum să rezolvați povestea utilizatorului. Aveți nevoie de dependență pentru a ateriza mai întâi.
- Programe— Uneori, managerii spun: „Așteptați această modificare a codului până după lansarea de marți”. Poate că aștepți o întâlnire cu un partener sau echipa decide să facă o schimbare majoră numai după ce se termină vacanța. Ești încă blocat chiar dacă codul este gata.
- Aprobari: unele proiecte necesită aprobarea membrilor echipei interne, a partenerilor sau a clienților externi. De îndată ce ați terminat munca, marcați-vă blocat în timp ce așteptați clarificarea.
- Decizii—Un proiect se poate opri uneori când au loc prea multe dezbateri cu privire la o anumită decizie. Ar trebui să rezolvăm acest lucru în stratul de date sau în stratul de afaceri? Ar trebui să adăugăm un nou API sau nu? Ești blocat pentru că echipa trebuie să ajungă la un acord.
- Povestiri lipsă— O problemă nefericită este atunci când unui membru al echipei i s-a spus să lucreze la un proiect, dar proprietarul produsului sau Scrum Master sau managerul său nu a scris sau finalizat încă biletele. Da! Trebuie să-l prinzi devreme. Timpul dezvoltatorului este scump și nu vrem să-l pierdem!
Odată ce echipa dvs. vede că un blocant poate fi mai mult decât „Nu înțeleg documentația și codul meu nu funcționează”, vă puteți elibera echipa pentru a vorbi mai multe despre locurile în care sunt blocate și pentru a apela la ajutor.
Lucrul esențial de reținut este că sunteți blocat atunci când nu mai există impact pe care îl puteți oferi pe cont propriu. Ați făcut tot ce puteți face, iar următorul pas este ca managerul sau colegii dvs. să intervină și să ajute la rezolvarea blocajului.
Algoritmi de programare pentru oameni și procesoare
Când un procesor modern ajunge la un blocator - poate că trebuie să aștepte pe un hard disk lent, pe rețea sau pe tastatură - schimbă sarcinile. În timp ce scriu asta, procesorul meu are 257 de procese și aproape trei mii de fire active.
Pe de o parte, vă puteți ajuta echipa să continue să aibă impact, oferindu-le alte sarcini. Dacă un membru al echipei este blocat la o sarcină, poți deschide alta la care să contribuie? Dacă echipa are nevoie de o decizie finală pentru a putea lansa un proiect, poate că poate începe cu următorul?
Cu toate acestea, schimbarea prea mare a sarcinilor poate fi, de asemenea, un semn al unei echipe care nu face suficient pentru a rezolva blocanții. Un membru al echipei care are trei proiecte active este probabil blocat pe unul dintre ele. Este managerul atent? Coechipierii provoacă probleme prin nehotărâre? Ce se întâmplă cu fiecare dintre acestea? Ne putem concentra pe cauzele principale ale blocantelor și să le rezolvăm?
Eliberați revendicări pentru sarcini care nu sunt active
O provocare comună este gestionarea interesului dezvoltatorului în diferite domenii. Un dezvoltator talentat poate vedea o sarcină viitoare, o poveste de utilizator sau o eroare pe care chiar dorește să o rezolve. Poate că este o tehnologie pe care o iubesc sau o caracteristică la care țin.
În orice caz, un dezvoltator poate revendica proiectul sau biletul sau bug-ul cu săptămâni în avans - și asta înseamnă că nimeni altcineva nu o poate face.
Managerul sau Scrum Master ar trebui să ajute la identificarea și atenuarea acestei probleme cât mai mult posibil. Dorim ca dezvoltatorii noștri să fie pasionați de munca lor și vrem să încurajăm membrii echipei noastre să aleagă biletele la care țin.
Dar când un dezvoltator are cinci până la zece povești de utilizator în starea „Activ”, poate că încearcă să facă prea multe. Cereți-le să se concentreze pe două sau trei sarcini simultan și s-ar putea să deblocați munca pentru alți membri ai echipei.
Utilizați comiteri mici și solicitări de extragere regulate
O modalitate utilă de a reduce blocarea biletelor este să vă încurajați echipa să facă „comite mici în mod regulat în timp”. Fiecare cerere de tragere mică poate fi o parte a proiectului general. Un filtru constant de cereri de tragere mici arată că membrul echipei nu este blocat.
Când o anumită poveste de utilizator este activă pentru un dezvoltator și acel dezvoltator nu a trimis o cerere de extragere în câteva zile, acesta ar putea fi un semn că un blocant s-a strecurat neobservat - sau ar putea fi că povestea utilizatorului a fost mult prea mare. mare și ar fi trebuit rupt în bucăți mai mici.
O abordare pe care o folosesc managerii pentru a aborda poveștile mari este „rotirea responsabilității” pentru sarcină – dar aceasta ar trebui folosită doar ca ultimă soluție. A lua o sarcină de la un dezvoltator și a o reatribui altuia poate fi o pedeapsă și nu ar trebui privită în acest fel.
O modalitate mai bună de a o gestiona este să mulțumești dezvoltatorului pentru munca depusă de până acum și să spui: „Acest bilet este clar prea mare. Să o împărțim în jumătate. Vom închide acest bilet și vom deschide două noi. Puteți lucra la biletul A și această persoană va lucra pe biletul B.”
Monitorizați-vă reacția la blocanți
Dacă pot încheia această conversație cu un singur sfat puternic, acesta este: Mulțumesc echipei pentru identificarea blocanților. Când cineva ridică mâna și identifică o problemă, asigurați-vă că spuneți: „O, bună prinsă! Să vedem ce putem face.”
De-a lungul timpului, echipa ta ar trebui să înțeleagă că poate primi ajutor atunci când este nevoie, iar blocanții ar trebui să înceteze să mai fie un lucru negativ și, în schimb, să devină ceea ce ar fi trebuit să fie întotdeauna: un instrument pentru a concentra energiile echipei pe o soluție pentru o problemă complexă.
Ted Spence predă la Bellevue College și conduce inginerie la Lockstep. Dacă sunteți interesat de ingineria software și analiza de afaceri, mi-ar plăcea să aud de la dvs. pe LinkedIn.
