Metodologie de dezvoltare agilă „Scrum”

În continuare lucrez la disertația mea în managementul proiectelor. Astăzi vom analiza rapid Scrum, vom analiza greșelile obișnuite care duc la probleme. Această postare nu pretinde a fi completă, este o prezentare generală și se adresează celor care nu sunt încă familiarizați cu Scrum sau sunt doar parțial familiarizați (de exemplu, lucrează în Scrum modificat).

În prezent, Scrum este una dintre cele mai populare „metodologii” de dezvoltare software. Prin definiție, Scrum este un cadru de dezvoltare cu care oamenii pot rezolva problemele emergente, în timp ce produc și produc produse de cea mai mare valoare (din punctul de vedere al clientului - nota autorului).

Acest lucru sugerează că în Scrum este imposibil să găsești răspunsuri la toate întrebările și instrucțiunile de acțiune în toate situațiile (de exemplu, descrierea oficială a Scrum indică doar necesitatea estimării timpului necesar pentru finalizarea lucrării, dar nu specifică tipul de evaluare. poate fi planificarea pokerului și un alt mod de evaluare). Astfel, numele subiectului în sine nu este corect :)

Când vorbesc despre metodologia Scrum, înseamnă cel mai adesea o metodologie de dezvoltare software agilă construită pe baza regulilor și practicilor Scrum, deci se poate dovedi că Scrum-ul tău este mai rece decât Scrum-ul meu și, de asemenea, este la fel de departe de el VAZ 7 este de la BMW Seria 7 :)

Roluri în Scrum

Există 3 roluri de bază în clasicul Scrum:
-Proprietarul produsului
-Scrum master
-Echipă de dezvoltare

Proprietarul produsului(PO) este legătura dintre echipa de dezvoltare și client. Scopul PO este de a maximiza valoarea produsului dezvoltat și munca echipei.

Unul dintre principalele instrumente PO este Backlog-ul produselor. Product Backlog conține sarcinile de lucru necesare pentru a finaliza (cum ar fi Story, Bug, Task etc.), sortate în ordinea priorității (urgență).

Scrum master(SM) este un servitor-lider. Sarcina Scrum Master este de a ajuta echipa să-și maximizeze eficacitatea, eliminând obstacolele, ajutând, predând și motivând echipa, ajutând OP

Echipă de dezvoltare(Echipa de dezvoltare, DT) este formată din specialiști care lucrează direct la produsul fabricat. Conform Ghidului Scrum (un document care este descrierea oficială a Scrum de la autorii săi), DT trebuie să aibă următoarele calități și caracteristici:
-Fii auto-organizat. Nimeni (inclusiv SM și PO) nu poate spune echipei cum să transforme restanța produsului într-un produs funcțional
-Să fie multifuncțional, să aibă toate abilitățile necesare pentru a lansa un produs funcțional
-Întreaga echipă este responsabilă pentru munca prestată, nu membrii individuali ai echipei

Dimensiunea recomandată a echipei este de 7 (plus sau minus 2) persoane. Potrivit ideologilor Scrum, echipele mai mari necesită prea multe resurse de comunicare, în timp ce echipele mai mici cresc riscurile (datorită lipsei de competențe necesare) și reduc cantitatea de muncă pe care o echipă o poate face pe unitate de timp.

Procesul Scrum

Baza Scrum este Sprint, în timpul căruia se lucrează la produs. La sfârșitul Sprint, ar trebui să fie primită o nouă versiune de lucru a produsului. Sprintul este întotdeauna limitat în timp (1-4 săptămâni) și are aceeași durată pe toată durata de viață a produsului.

Înainte de începerea fiecărui Sprint, se efectuează Sprint Planning, care evaluează conținutul Backlog-ului produsului și generează Sprint Backlog, care conține sarcinile (Story, Bugs, Tasks) care trebuie finalizate în sprint-ul curent. Fiecare sprint ar trebui să aibă un obiectiv care să motiveze și să fie atins prin finalizarea sarcinilor din Sprint Backlog.

În fiecare zi există un Daily Scrum, în care fiecare membru al echipei răspunde la întrebările „ce am făcut ieri?”, „Ce intenționez să fac azi?” Sarcina Daily Scrum este de a determina starea și progresul muncii la Sprint, detectarea timpurie a obstacolelor apărute și dezvoltarea de soluții pentru schimbarea strategiilor necesare pentru atingerea obiectivelor Sprint. "

La sfârșitul Sprintului, se produc Sprint Review și Sprint Retrospective, sarcina cărora este de a evalua eficacitatea (productivitatea) echipei în Sprint trecut, de a prezice eficiența (productivitatea) așteptată în următorul sprint, de a identifica problemele existente. , evaluați probabilitatea de a finaliza toate lucrările necesare asupra produsului și multe altele ...

O reprezentare schematică a procesului este prezentată în figura următoare:

Funcții importante, adesea trecute cu vederea

Veți auzi adesea că Scrum nu funcționează sau că are performanțe mai slabe decât se aștepta. Trebuie remarcat faptul că cel mai adesea acest lucru se întâmplă din unul dintre următoarele motive:

1. Scrum este aplicat incorect sau incomplet.
Potrivit autorilor Scrum, experiența empirică este principala sursă de informații fiabile. Necesitatea implementării complete și exacte a Scrum este indicată în Ghidul Scrum și se datorează organizării atipice a procesului, absenței unui lider formal și a unui lider.

2. Importanța muncii pentru a asigura motivația echipei este subestimată.
Echipele multi-funcționale care se auto-organizează sunt unul dintre principiile de bază ale Scrum. Conform cercetărilor efectuate de sociologi, numărul angajaților auto-motivați capabili de autoorganizare nu depășește 15% din populația activă.
Astfel, doar o mică parte din angajați sunt capabili să lucreze eficient în Scrum fără modificări semnificative în rolurile de master Scrum și de proprietar de produs, ceea ce contrazice ideologia Scrum și poate duce la utilizarea incorectă sau incompletă a Scrum.

3. Scrum este utilizat pentru un produs, ale cărui cerințe sunt contrare ideologiei Scrum.
Scrum aparține familiei Agile, astfel încât Scrum salută modificările cerințelor în orice moment (restanța produsului poate fi modificată în orice moment). Acest lucru face dificilă utilizarea Scrum în proiecte cu cost fix / timp fix. Ideologia Scrum afirmă că este imposibil să se prevadă toate schimbările în prealabil, deci nu are rost să planificăm întregul proiect în avans, limitându-ne la planificarea just-in-time, adică să planificăm doar munca care trebuie făcută în actualul Sprint. Există și alte restricții.

Avantaje și dezavantaje

Scrum are câteva virtuți destul de convingătoare. Scrum este orientat către client, receptiv. Scrum oferă clientului posibilitatea de a face modificări cerințelor la un moment dat (dar nu garantează că aceste modificări vor fi implementate). Capacitatea de a modifica cerințele este atractivă pentru mulți clienți de software.

Scrum este destul de ușor de învățat, economisește timp eliminând activitățile non-critice. Scrum vă permite să aveți un produs potențial funcțional la sfârșitul fiecărui Sprint.
Scrum se concentrează pe o echipă multi-funcțională care se auto-organizează, capabilă să rezolve sarcinile necesare cu o coordonare minimă. Acest lucru este deosebit de atractiv pentru companiile mici și start-up-uri, deoarece elimină necesitatea angajării sau instruirii personalului executiv specializat.

Desigur, Scrum are și dezavantaje importante. Datorită simplității și minimalismului său, Scrum stabilește un număr mic de reguli destul de rigide. Cu toate acestea, acest lucru este în contradicție cu ideea de concentrare a clienților în principiu, deoarece clientului nu îi pasă de regulile interne ale echipei de dezvoltare, mai ales dacă restricționează clientul. De exemplu, dacă este necesar, la decizia clientului Sprint, restanțele pot fi schimbate, în ciuda contradicției evidente cu regulile Scrum.

Problema este mai mare decât pare. pentru că Scrum aparține familiei Agile, în Scrum nu este acceptat, de exemplu, să creezi un plan de comunicare și să răspunzi la riscuri. Astfel, făcând dificilă sau imposibilă rezistența formală (legală sau administrativă) la încălcarea regulilor Scrum.

O altă slăbiciune în Scrum este accentul pus pe o echipă multi-funcțională care se auto-organizează. Cu o scădere aparentă a costurilor de coordonare a echipei, acest lucru duce la o creștere a costurilor de selecție a personalului, motivație și instruire. În anumite condiții de pe piața forței de muncă, este posibil să nu fie posibilă construirea unei echipe complete și eficiente Scrum.

Lista surselor utilizate

Ghidul Scrum. Ghidul definitiv pentru Scrum: Regulile jocului. (Ken Schwaber, Jeff Sutherland)
Psihologia managementului, ghid de studiu. (A. A. Trus)
Cum se transformă un manager de proiect tradițional în Scrum: PMBOK vs. Scrum. (Jeff Sutherland, Nafis Ahmad)

Vă mulțumim anticipat pentru erorile și inexactitățile indicate!

 

Ar putea fi util să citiți: