Este greu să conduci o echipă de dezvoltatori. Încercarea de a coordona un munte de muncă, menținând în același timp pe toată lumea productivă, este o provocare în sine. Dar, pe deasupra, trebuie să păstrați comunicări deschise cu un client. Cum putem folosi agil pentru a ameliora unele dintre aceste puncte de durere?
- Ce este agil?
- Care sunt câteva concepte pe care ar trebui să le cunoașteți?
- Povești
- Epopee
- Sprinturi
Ce este agil?
Agile este o metodologie de dezvoltare software care provine din ideea de a împărți cantități mari de muncă în bucăți mai mici. Acest lucru oferă managerilor de produse, dezvoltatorilor și oricărui actor interesat o mai bună înțelegere a activității.
Din punct de vedere istoric, dezvoltarea software-ului a fost un proces lent, în care modificările majore ale cerințelor ar putea pune eforturi mari asupra echipelor.
Când urmează metodologia agilă, bucățile mai mici de lucru ajută echipele să devină mai flexibile și îndrăznesc să spun agil. Și în acest proces îi ajută să livreze caracteristici mai rapid și să răspundă mai rapid la schimbări.
Aceste idei au fost împărțite în diferite cadre de abordare a acestei metodologii. Două dintre cele comune sunt Scrum și Kanban.
Pentru această prezentare generală, majoritatea acestor concepte urmează de-a lungul cadrului Scrum, dar există cu siguranță concepte care se aplică atât ambelor, cât și altora.
Care sunt câteva concepte pe care ar trebui să le cunoașteți?
Aș argumenta că jumătate din a fi productiv ca dezvoltator într-o lume agilă este pur și simplu înțelegerea termenilor. În mod obișnuit, managerul de proiect rulează spectacolul, așa că, dacă puteți fi pe aceeași pagină cu ceea ce vorbesc, va ușura procesul.
Există cărți, cursuri și certificări bazate pe învățarea nuanțelor metodologiei agile. Nu am de gând să intru adânc în unele aspecte filosofice sau în unele părți mai profunde, dar voi acoperi un set bun de concepte cheie care vă vor ajuta să vă loviți de pământ atunci când vă începeți noul loc de muncă cu un echipă agilă.
Povești
O poveste este de obicei cea mai mică piesă definită. Acest lucru vine de obicei sub forma unui nou bilet pe care îl creați în instrumentul de proiect pe care îl utilizați, indiferent dacă este Jira sau chiar Probleme Github.
Exprimarea poveștilor
Când lucrați la un proiect, veți întâlni probabil o varietate de moduri în care oamenii exprimă povești. Dar un bun ghid este să treci prin conceptul cuvântului „poveste” în sine și să explici munca care trebuie făcută în acest fel.
De exemplu, dacă doriți să oferiți persoanelor care vă utilizează site-ul web posibilitatea de a partaja o postare de blog pe Twitter, vă recomandăm să scrieți povestea astfel: În calitate de cititor, vreau să împărtășesc postarea pe care tocmai am citit-o pe Twitter .
Folosind acel model de „ca un [person], Vreau sa [action]„ajută la furnizarea contextului, în ce stare se poate afla cineva când își vizitează site-ul și ce încearcă să realizeze. Acest lucru poate fi deosebit de util dacă dezvoltați funcții pentru persoanele conectate care sunt diferite de invitați.
Detalii și cerințe
În timp ce titlul unei povești este o reprezentare importantă a operei, veți dori, de asemenea, să oferiți informații suplimentare.
Cel puțin, acest lucru ar trebui făcut prin adăugarea unei descrieri amănunțite și a unui set de criterii de acceptare care pot contribui la crearea contextului și cerințelor dezvoltatorului. În funcție de echipă, aceasta poate include, de asemenea, instrumente precum etichete sau categorizări care facilitează vizualizarea echipelor de grupuri de lucru.
Furnizarea unui set puternic de cerințe ajută atât dezvoltatorul care lucrează la poveste, cât și persoana care o revizuiește să aibă o măsurare pentru a determina dacă este completă. Fără asta, toată lumea doar ghicește.
O modalitate bună de a sintagma acestea sunt: verificați [requirement]. Înapoi la exemplul meu de a distribui o postare pe Twitter, poate că unele dintre cerințele acestei povești ar fi:
- Verificați când faceți clic pe butonul de partajare este creat un nou tweet
- Verificați dacă tweet-ul include un link către postarea curentă pe blog
Cantitatea de muncă sau nivelul de dificultate
Fiecare poveste este reprezentată de un număr de puncte. Aceste puncte sunt o modalitate de a exprima cât de mult efort se așteaptă o echipă de dezvoltatori la o poveste. Acest efort poate însemna o varietate de lucruri, deși este pur și simplu cât de dificil se așteaptă echipa să fie munca sau riscul sau incertitudinea pe care o are o anumită poveste.
Un mod în care echipele reprezintă acest lucru este cu secvența Fibonacci, unde cantitatea de puncte poate fi 1, 2, 3, 5, 8 etc. În cazul în care o actualizare neglijabilă a textului poate fi de 1 punct, adăugarea unui nou formular la o pagină ar putea fi de 3 puncte.
De obicei, veți dori să evitați să arătați povestirile prea sus, deoarece obțineți peste 5 puncte, există mai mult decât probabil o modalitate prin care puteți rupe munca pentru ao face mai ușor de gestionat. În timp ce ați putea crea cu ușurință o poveste masivă de 13 puncte pentru a realiza toate aspectele unei caracteristici, de obicei are sens să abordați munca în bucăți mai mici și mai concentrate.
Oricum, aceste puncte se adună toate împreună pentru a oferi echipei dvs. o estimare aproximativă a cantității de muncă pe care ar trebui să o îndeplinească un grup de povești.
Epopee
În timp ce poveștile au ca scop definirea unei lucrări de dimensiuni mușcate, epopeile sunt o modalitate de a grupa acele lucrări împreună pentru a reprezenta o caracteristică.
Definirea poveștilor ca o caracteristică
O modalitate bună de a explica acest lucru este cu un alt exemplu. Dacă lucrați la o aplicație care necesită integrarea autentificării, vă recomandăm să creați o nouă epopee numită pur și simplu „Autentificare”.
În acea epopee, puteți găsi povești precum:
- Ca invitat, vreau să mă conectez la aplicație cu adresa mea de e-mail
- În calitate de utilizator autentificat, vreau să îmi schimb parola
- În calitate de echipă de securitate, vreau să previn spamul și abuzul de autentificare a utilizatorilor
Odată cu epopeea definită, oferiți echipei dvs. o cale de a apela o caracteristică completă, în timp ce înțelegeți întreaga gamă a acelei activități. Acest lucru este important atunci când vine vorba de planificarea muncii de făcut.
Definirea poveștilor dvs. în epopeea dvs. vă oferă o impresie despre cât de multă muncă necesită ceva, dar nu vă ajută să vă dați seama cât timp ar dura, care este locul în care intervin sprinturile.
Sprinturi
Sprinturile sunt un mod de a planifica modul în care se va efectua munca. Deși sunt similare cu epopeile prin faptul că sunt o modalitate de a grupa bucăți de lucru, sprinturile reprezintă de obicei o perioadă de timp în care se va face o anumită bucată de muncă.
Timp pe sprint
Un mod obișnuit de a defini un sprint este de două săptămâni de muncă. În timpul celor două săptămâni, echipa dvs. va avea o anumită viteză sau o cantitate medie de muncă pe care o puteți îndeplini, pentru un sprint individual. Această viteză este reprezentată de un număr de puncte care reprezintă o sumă a vitezei medii a fiecăruia dintre dezvoltatorii care lucrează la acel sprint.
Puncte pe sprint
Deși mulți susțin cu înverșunare că nu ar trebui să folosiți timpul pentru a reprezenta această viteză, punctele se vor traduce aproximativ într-un timp mediu de lucru pentru fiecare dezvoltator. În timp ce 1 punct pentru un dezvoltator cu experiență ar putea fi de 1 oră, același 1 punct ar putea însemna 3 ore pentru un dezvoltator mai puțin experimentat.
Dar, odată ce ai acest număr de puncte pe care echipa ta le calculează în medie într-un sprint, vei ști câte puncte de poveste te poți aștepta să fie finalizate. Această planificare merge sprint în sprint pe măsură ce răspândești un grup de povești sau o epopee, astfel încât să poți prevedea când o caracteristică va fi completă.
Cât de agil se potrivește cu echipa ta
Încercați să vă amintiți că metodologia Agile prin Scrum, Kanban sau orice alt cadru este doar asta – un cadru. Deși este probabil o idee bună să urmați procesul atunci când începeți pentru prima dată, ascultați-vă echipa și încercați să-l adaptați la propriile experiențe.
Fiecare echipă funcționează puțin diferit și forțarea unui proces către acea echipă poate provoca mai mult rău decât bine, dar va exista întotdeauna o curbă de învățare pentru orice proces. Luptați cu ochii până când toată lumea îl obține și aveți frecvente retrospective pentru a vedea ce funcționează și ce nu.
La sfârșitul zilei, procesele pe care le urmează echipa dvs. ar trebui să fie în mare parte invizibile, lucrând pentru dvs. în loc să fie împotriva dvs. Găsiți ce funcționează cel mai bine pentru echipa dvs. și împărtășiți-vă experiențele pentru ca ceilalți să învețe!
Care sunt procesele echipelor tale?
Distribuiți cu mine pe Twitter!
