Scrum nu este pentru toată lumea, rusbase

Izzat Shukurov, manager de proiect, Workly. spune cine și de ce este nevoie de Scrum, cu ce probleme se poate întâmpina implementarea metodologiei și ce rezultate - pentru a realiza.

Scrum - metodologia managementului de proiect, care este folosită când este necesar pentru o dezvoltare flexibilă. Conducătorii Scrum acordă atenție controlului calității procesului de dezvoltare.

Astăzi vă voi spune cum am implementat Scrum în lucrul la proiectul nostru Workly - un serviciu care ajută la optimizarea activității echipei.

La început, am avut multe probleme. Principalul lucru este că oricine ar putea influența procesul. Șeful stabilit sarcina de a adăuga o caracteristică nouă, managerul parohiile indignată că dezvoltatorii efectua nu este ceea ce ai nevoie, sarcina întreruptă ... Ca urmare, un grup de profesioniști transformat în artiști. Nimeni nu a înțeles motivul pentru performanța slabă a companiei și echipa nu a vrut să își asume responsabilitatea pentru munca lor.

Lipsa de sincronizare în gestionarea dezvoltatorilor a ucis responsabilitatea pentru rezultatul, le-a privat de "victorii mici". Toate acestea au demotivat colectivul în ansamblul său - și, drept rezultat, au devenit cea mai mare problemă a lucrării. Echipa nu a văzut valori comune și nu sa simțit solidă.

Pentru a rezolva această problemă, am decis să încercăm să reconstruim lucrarea privind metodologiile flexibile, și anume, potrivit lui Scrum.

Proiectul implică mulți oameni: dezvoltatori, manageri, contabili, directori. Totul depinde unul de altul. Eroarea oricarei link-uri poate afecta clientii. Scrum învață: pentru a evita acest lucru, întregul personal ar trebui să-și sincronizeze acțiunile între ele.

De ce a fost selectat Scrum? Ajută la reacția rapidă la schimbările de pe piață. Și deoarece proiectul nostru este un startup, a fost nevoie de flexibilitate, predictibilitate și performanță.

În plus, Scrum vă permite să produceți rapid și permanent un rezultat care să satisfacă clientul.

Începutul. Cum să treci la Scrum?

Nu am reușit să implementăm imediat Scrum - echipa nu era gata pentru asta. Solul trebuia pregătit treptat - fiecare inovație a apărut în etape, ca o soluție la problemă, și nu ca o regulă.

Unde ar trebui să începem?

1. Îndepărtați temerile

Când se implementează Scrum, poate apărea o problemă - echipa percepe cu atenție inovațiile, oamenii nu înțeleg de ce este necesar. Dacă tratați echipa nu ca un grup de artiști, ci ca un grup de specialiști, trebuie să le explicați de ce sunt create noi condiții și care este scopul.

2. Pentru a crește importanța unui individ

Este foarte important ca oamenii să se simtă ca o echipă, nu executorii. Nu am împărțit colectivul în "noi" - echipa, și "ei" sunt liderii.

Am lucrat la eradicarea poziției: "Sunt programator și nu vreau să decid nimic". Ei doreau să-i motiveze pe oameni să-și folosească potențialul creativ.

3. Definirea obiectivului principal și a valorilor companiei

Am definit scopul - de a crea un serviciu de calitate care să funcționeze stabil și să ajute oamenii. Valorile echipei au permis tuturor să își asume responsabilitatea în mod responsabil. Dezvoltatorii au înțeles că nu scriu doar coduri, ci oferă o soluție nouă.

4. Îndepărtați sarcinile neprogramate

Cum am scăpat de sarcinile care vin haotic? Singura cerință era să lase un mediator între conducere și echipă. Punerea în aplicare a acestui punct a durat trei luni, dar, ca rezultat, sarcinile au început să vină de la o persoană, au fost aprobate și ordonate prioritar.

5. Pentru a putea spune șefului "nu"

O parte din timp a fost petrecut învățând cum să spui "nu" conducerii. A fost dificil. Nu toată lumea știa cum și era gata să spună "nu" șefului sau colegului superior. Dar, să învețe să renunțe, era important ca oamenii nu își asumă responsabilitatea pentru, evident, o sarcină imposibilă, care trebuie să se facă într-un timp scurt și cu anumite cerințe de calitate.

Complexitate mică

Procesul de pregătire pentru trecerea la Scrum a durat nouă luni. Bineînțeles, nu fără dificultăți. În ansamblu, au existat doar două: o anumită rezistență la deschiderea metodologiei din partea angajaților și o reticență de a păstra o evidență permanentă în Trello ales de noi.

Rezistența a apărut la început, din cauza lipsei de încredere în maestrul de spammagiu. Echipa a avut o impresie falsă că prin dezvăluirea procentului real al muncii efectuate, ei ar fi supraîncărcați cu sarcini. Această complexitate a fost rezolvată prin antrenorul fiecărui angajat, explicând esența metodologiei și a obiectivelor lucrării.

Treptat, personalul a început să realizeze că această deschidere face posibil să nu le distragă atenția de la munca lor, nu pentru a cere din nou cu privire la rezultatele fiecare oră și set de sprint obiectivele rămân aceleași - în cazul în care angajatul a terminat partea sa din lucrare, el poate, dacă se dorește pentru a ajuta un coleg, dar nu adăuga sarcini suplimentare pentru a-l "Nu am fost inactiv."

Era mult mai dificil, cu raportarea constantă în Trello - angajații pur și simplu au uitat să marcheze disponibilitatea proceselor în lista de verificare și să tragă cărțile peste proiecte. Dar, ca urmare a amintirilor constante și a explicațiilor minuțioase de ce acest lucru este necesar, echipa sa obișnuit cu aceste procese de rutină și a început să le execute fără conversații inutile.

Primele rezultate

Echipa a fost pregătită să lucreze cu metodologia numai după ce am oferit condițiile pentru lucru:

Un mediator între conducere și dezvoltatori,
Termenul condițional pentru îndeplinirea sarcinilor,
Interesul pentru rezultatul fiecăruia,
Concentrați-vă pe obiectivele și valorile dvs.

Echipa avea valori. Iată valorile pe care le-am determinat:

Rezolvăm probleme, dar nu scriem coduri.

Dacă regula ne împiedică să fim eficienți, o refuzăm.

Problema ideală arată ca o necesitate, nu o cerință. Vom decide ce și cum să facem pentru a rezolva problema.

Suntem cinstiți unul cu celălalt și, prin urmare, avem încredere.

Toată lumea face tot ce depinde de el, la fel cum poate și cu ceea ce are în situația actuală.

Nu căutăm vinovații, căutăm cele mai bune căi de a rezolva problema.

Încercăm să nu repetăm greșelile, nu ne este rușine de ei. Greselile sunt calea noastra de a ne imbunatati pe noi insine si produsul nostru.

În calitate de profesioniști avem încredere în sarcini și alegem soluții - și, prin urmare, suntem responsabili pentru rezultat, când începem activitatea.

Nu spunem "se pare (teoretic / teoretic, funcționează așa)", spunem - "funcționează așa".

Dacă trebuie să rezolvăm problema, ne ridicăm și ne hotărâm, mergem și ne întrebăm, vorbim deschis despre probleme - pentru că nu vrem să căutăm vinovații după aceea.

În cele din urmă, am prioritat corect și am indicat obiectivele pe care echipa le poate atinge cu adevărat. Angajații au început să înțeleagă când produsul va avea aceste sau alte caracteristici. A avut loc o concentrare de două săptămâni pe un singur obiectiv care nu poate fi schimbat.

Acum, echipa, folosind oricare dintre sculele scumpe, oferă produsul finit la intervale strict definite. Datorită unui număr limitat de persoane, dezvoltatorii se concentrează pe obiectiv cât mai mult posibil. Realizând limitele de timp, echipa nu o pierde, formează competent un sprint și de fiecare dată primește o mică victorie în echipă.

Cum sa schimbat formatul?

Două ore pentru planificarea sprintului. Sarcina este setată și durata sprintului este determinată.
Timp de 15 minute pe scrum-standup. Fiecare membru al echipei discută despre îndeplinirea sarcinilor, a problemelor și a soluțiilor emergente.
Un an și jumătate de prezentare la sfârșitul sprintului. Un alt instrument important în metodologie, tonifică echipa și vă permite să vă mândriți de rezultatele obținute.
Retrospectivă după prezentare. Echipa de lucru pe bug-uri, în cursul căruia motivele sunt explicate de ce sprintul nu a mers atât de bine cum era de așteptat, și ceea ce a împiedicat munca ideală. Este important ca, în timpul sprintului, toți membrii echipei să fie cât mai direct posibil și cinstiți unul cu celălalt.
În metodologia Scrum, interschimbabilitatea membrilor echipei este importantă. Particularitatea fluxului de lucru a fost rotația dezvoltatorilor între departamente - finalizarea lucrărilor într-un singur proiect, angajatul (dacă se dorește) poate trece la un alt proiect și poate împărtăși experiența. Ca rezultat, toți membrii echipei au fost pregătiți să rezolve problemele apărute, au devenit organizate și interschimbabile.

Articole similare

Pagina anterioară

Pagina următoare