În articolul meu anterior, am început discuția despre obiceiurile slab dezvoltate în interiorul unei echipe scrum care vor duce în cele din urmă (mai devreme sau mai târziu) la un eșec în livrare. În acest articol, aș dori să extind încă o dată acest subiect și să mă concentrez acum pe procesele funcționale din interiorul echipei.
Acestea sunt la fel de importante ca excelența tehnică a echipei. Chiar dacă oamenii din interior sunt super calificați pentru jobul pe care urmează să îl livreze, există totuși domenii care le pot distruge efortul pentru perfecțiune. Și nu va fi atât de mult vina lor, deoarece va fi responsabilitatea directă a deciziilor de management de proiect și capacitatea lor de a servi echipa cu procese adecvate scopului pentru a sprijini echipa cu intenții clare și activități previzibile.
Cuprins
Echipă foarte separată, cu abilități distincte
Imaginați-vă că echipa are dezvoltatori calificați, perfect independenți și cu capacitatea de a-și respecta promisiunile și de a livra conținutul de sprint convenit chiar la timp înainte de sfârșitul sprintului. Chiar și într-un scenariu atât de perfect (ceea ce este foarte puțin probabil să se întâmple oricum), echipa va avea probleme în a ține pasul cu funcțiile în așteptare (în continuă creștere) dacă abilitățile sunt strict separate între membrii echipei.
Câteva Exemple
- Echipa are 1 sau 2 ingineri DevOps capabili să facă orice modificări ale conductelor automate sau să se ocupe de serviciile din interiorul platformei, dar restul echipei nu are nicio idee despre astfel de lucruri. Apoi, discutarea acelor povești despre ceremoniile scrum, precum perfecționările, va duce la pierderea timpului pentru majoritatea echipei, agățat de întâlnire fără nicio participare și invers – dezvoltatorul DevOps nu va fi interesat de restul poveștilor orientate spre funcționalități și timpul de întâlnire va fi în mare parte pierdut și el.
- Există un singur expert în baze de date pentru întreaga echipă. În funcție de complexitatea și utilizarea soluțiilor de date din sistemul pe care echipa îl dezvoltă, această persoană ar putea fi în mod constant supraîncărcată cu povești pe care nu au șanse să le finalizeze suficient de curând, mai ales când ia în considerare prioritățile. Și mai rău, și alte povești vor trebui să aștepte, deoarece acestea depind de sursa de date furnizată de poveștile bazei de date.
- Când un anumit produs este orientat în mare parte spre dezvoltarea backend, singurul dezvoltator front-end este acolo pentru orice eventualitate (pentru că din când în când, oricum, este nevoie de o mică schimbare chiar și în aplicația UI). În acest caz, din nou, majoritatea ceremoniilor de scrum sunt o pierdere de timp pentru acest membru al echipei, deoarece cunoștințele lor sunt limitate doar la front-end și nimic altceva nu contează.
Unde se încheie
În oricare dintre cazurile de mai sus, rezultatul este că oamenii fie își pierd timpul, fie, alternativ, nu reușesc să atingă cererea întârziată. Ei blochează restul echipei să înceapă să lucreze la poveștile următoare sau scad efectiv eficiența generală a echipei scrum, deoarece există prea mult timp care nu este utilizat în sprint.
Echipa, însă, mai are acest număr de dezvoltatori. Din exterior, nu se vede (chiar nu doresc să fie expuși) că oamenii din interiorul echipei nu sunt capabili să preia niște povești doar pentru că sunt prea orientați către un anumit set de abilități. Așa că nu îi pot ajuta pe ceilalți membri ai echipei cu poveștile, chiar dacă capacitatea lor le-ar permite, iar prioritățile pentru povești l-ar favoriza și ele.
Este chiar dificil pentru proprietarul produsului să compună un conținut de sprint semnificativ pentru echipă, deoarece proprietarul produsului trebuie să țină cont întotdeauna de câți oameni pot lucra la fiecare poveste și dacă mai multe povești similare sunt aduse la sprint în același timp. , în cele din urmă capacitatea echipei este depășită, chiar dacă există, de fapt, oameni care ar putea lucra la acele povești, dar nu au aptitudinile necesare pentru a începe cu acelea.
Rezolvarea Dilemei
Este o dilemă care trebuie rezolvată, iar managerii de proiect trebuie să fie conștienți de calea de a alege. Mai exact, o alegere între:
- Având mulți dezvoltatori full-stack capabili să lucreze la conținut mai larg, dar nu chiar experți în multe subiecte. Deci pot merge lat, dar nu adânc. Apoi livrarea poate progresa rapid, dar calitatea ar putea avea de suferit.
- Având experți dedicați pentru fiecare tehnologie, dar apoi acceptând limitarea și lucrând mai mult la conținut imprimat mai bine adaptat. Apoi oamenii pot merge în profunzime și pot construi povești grozave, dar poveștile vor trebui abordate secvențial, astfel încât să dureze mai mult timp să fie livrate.
Proprietar slab de produs
Aceasta nu este neapărat o „problemă de proces” prin definiție, dar o tratez așa doar pentru că crearea de povești solide poate fi înțeleasă ca un proces pe care echipa ar trebui să-l aibă solid și compatibil cu echipa de dezvoltare.
Ceea ce vreau să spun prin slab nu trebuie să se refere la proprietatea cunoștințelor unei persoane, ci mai degrabă la capacitatea proprietarului produsului de a servi poveștile echipei pe care dezvoltatorii le pot înțelege și care au un sens clar din perspectiva foii de parcurs a produsului. Ambele sunt foarte importante pentru o echipă scrum de succes.
Dacă poveștilor le lipsesc detalii pentru ca dezvoltatorii să poată înțelege clar scopul, valoarea funcțională sau așteptările tehnice, atunci se pot întâmpla practic două scenarii:
- Dezvoltatorii vor construi ceva diferit de ceea ce și-a dorit de fapt proprietarul produsului. Este chiar greu de prins în timpul sprintului în sine, deoarece în mare parte proprietarul produsului nu a avut capacitatea de a urmări progresul poveștilor la un nivel atât de detaliat, iar în cea mai mare parte PO se va aștepta ca lucrul să se întâmple (în mod magic).
- Dezvoltatorii vor petrece mult prea mult timp clarificând poveștile și discutând despre ele din nou și din nou, decât să înceapă să le construiască. Acest lucru implică multe apeluri suplimentare, acorduri repetate și amânarea lucrărilor la faza de sprint târziu. Se ajunge la un punct în care estimările inițiale pentru povești nu mai pot fi considerate exacte, iar poveștile nu sunt posibile să se închidă în sprint și se rulează în următoarele sprinturi. În cel mai rău caz, situația se repetă apoi în sprinturile ulterioare.
Timp pentru auto-reflecție
De obicei, este greu de recunoscut, dar proprietarul produsului ar trebui să găsească timp să reflecteze, să se uite la poveștile întârziate create și, în cele din urmă, să o compare cu viziunea foii de parcurs pentru produs, dacă există încă vreo legătură sensibilă între cele două – dacă există vreo foaie de parcurs. deloc. Dacă nu, acesta este primul lucru de rezolvat. Uneori, soluția este să admitem că proprietarul produsului este prea departe de echipă și prea departe de propria țintă.
Într-un astfel de caz, partea de proprietar de produs a echipei urmează să fie rezolvată. Dacă nimic altceva, aducerea în echipă a unui analist de afaceri solid, orientat mai degrabă către conținutul echipei decât către conținutul business (pentru asta, avem deja un proprietar de produs în acest caz) ar putea fi o opțiune valabilă, chiar și pentru prețul de costuri totale crescute ale echipei.
Procese de testare fără cronologie fixă
Ce se întâmplă dacă activitățile de testare nu sunt strânse la un program concret în cadrul unui sprint scrum?
La prima vedere, acest lucru ar putea părea ca ceva bun pe care ni-l dorim pentru o echipă agilă / scrum. Flexibilitatea este întotdeauna binevenită și sună bine atunci când este prezentată afară.
Experiența mea arată că rezultatul acestei libertăți este mai mult haos decât flexibilitate. Nu înseamnă că soluția ar trebui să fie crearea de „cascade în interiorul sprintului”, cu faze de testare dedicate urmate imediat după finalizarea dezvoltării. Aceasta nu este deloc abordarea corectă în acest caz. Puteți citi mai multe despre asta în postările mele despre strategia de testare scrum și ciclul de viață al testării agile.
Putem permite totuși o oarecare flexibilitate și să alegem programul de testare, deoarece pare cel mai potrivit pentru echipa de dezvoltare actuală și pentru proprietățile produsului dat pe care echipa le oferă. Există, totuși, două obiective principale care ar trebui atinse prin această alegere:
Dacă aceste condiții vor fi îndeplinite, echipa se va adapta în mod natural la procesul de montare, iar programul de livrare nu va fi afectat de activități de testare prelungite neplanificate.
În cele din urmă, ceea ce contează cel mai mult este lansarea de sprint fiabilă și previzibilă, ceea ce mă duce la ultimul punct al acestui blog.
Proces de lansare nedefinit
Acum, acesta este un lucru atât de evident pentru fiecare echipă scrum. Cu toate acestea, destul de curios, este de obicei unul dintre cele mai subestimate procese.
Foarte des, o echipă scrum va spune doar că lansarea va avea loc după fiecare sprint, dar nu este susținută de un proces solid. Ceea ce se întâmplă atunci, în realitate, este o mulțime de activități haotice, imprevizibile, în timpul lansării. Dintr-o dată, toți oamenii sunt ocupați cu „sarcini de lansare” și nimeni nu se poate concentra pe continuarea dezvoltării de noi povești de sprint. Valorile de sprint sunt dezactivate, iar lansarea arată ca o activitate aleatorie, imprevizibilă din punctul de vedere al celei de-a treia persoane (de obicei, clientul).
Oamenii sunt atât de concentrați pe backlog, conținutul sprintului, dezvoltare, testare și, în cele din urmă, să prezinte rezultatele încât uită că odată ce au terminat cu toate acestea, următorul sprint este deja în desfășurare și pierd deja timp.
Caut un moment bun pentru a elibera
Deci, când anume ar trebui echipa să facă lansarea efectivă în producție? Singurul lucru important care contează la sfârșit.
Răspunsul la această întrebare se află în proces, presupunând că aveți unul. În funcție de:
- complexitatea conținutului pe care echipa îl produce în sprinturi,
- durata unui sprint,
- numărul de componente afectate din sistem
- numărul de persoane care utilizează și solicită modificările,
un proces de eliberare repetat ar trebui să fie stabilit și urmat în continuare. Regulile exacte ale procesului pot fi din nou flexibile în definire. Dar, așa cum este cu activitățile de testare, făcându-l un obicei solid, previzibil și programat pentru zile concrete în viitor, îl face ceva pe care să te bazezi și la care să te referi.
Alegeri de ales
Formele posibile ale unui astfel de proces pot fi oricare dintre următoarele sau altele:
- Finalizați testarea caracteristicilor din sprintul curent în timpul următorului sprint și eliberați conținutul la sfârșitul acelui sprint (odată ce testarea este finalizată). Aceasta înseamnă că fiecare lansare nu va avea niciun conținut de la ultimul sprint, dar va conține povești din cele 2 sprinturi anterioare.
- Ultimul sprint înainte de lansare este întotdeauna dedicat testării conținutului din ultimele două sprinturi.
- Acest lucru nu înseamnă că dezvoltarea în timpul „sprintului de testare” va fi oprită; spune doar că conținutul dezvoltat în acel sprint de testare nu va fi inclus încă în următoarea ediție.
- Dacă există deja suficiente activități de testare automată, străduiți-vă să faceți lansarea după sfârșitul fiecărui sprint. Atunci acesta trebuie să fie un proces foarte strict, cu oameni dedicați care se concentrează pe acele câteva zile pentru 100%. Totuși, nu ar trebui să afecteze în niciun fel restul echipei de dezvoltare.
- De asemenea, puteți alege să lansați o dată pe lună sau o dată pe N luni, în principal dacă acest lucru va fi bine din perspectiva utilizatorilor finali. Acest lucru va crește efortul din partea de testare pentru fiecare sprint (deoarece conținutul va fi mai mare pentru fiecare lansare). Dar, pe de altă parte, va însemna mai puțină cantitate de activități repetate în timp, ceea ce, în acest caz, poate avea beneficii pentru echipă. Ca rezultat, poate permite echipei să construiască mai multe funcții noi între versiuni, în ciuda faptului că caracteristicile vor intra de fapt în producție cu o cadență mai lentă.
Dar, așa cum sa spus deja de câteva ori înainte, nu este atât de important care dintre aceste procese va fi ales. Este mult mai important cât de bine se va ține echipa apoi de acel proces și îl va transforma într-un obicei rezistent.
De asemenea, puteți citi acest ghid pentru procesul și practicile de gestionare a versiunilor.