Scrum (Scrum) și metodologii de dezvoltare flexibilă

Să presupunem că te duci la casa lui, care stau pe canapea vechi, care este ieșită din primăvară, uita-te la vechi, peeling mobilier și spune-te „astfel încât nu se poate merge mai departe!“. Cu siguranta doriti sa va schimbati mobila veche, uzata intr-o noua, ecologica si functionala, adaptata la nevoile dumneavoastra. Și varianta de bunuri de consum de la IKEA - nu este luată în considerare, deoarece aveți propriile cerințe specifice clar definite pentru mediul acasă.







Mergeți la un maestru foarte abrupt, crezând sincer că doar profesioniștii pot să vă transpună dorințele în realitate. Se pare că va dura aproximativ o lună pentru a aștepta. Acest lucru ți-a diminuat într-o oarecare măsură fervoarea, dar decizia a fost deja luată. Da, și foarte inconfortabil să se întoarcă la viermășitorul. Faceți o plată în avans, spuneți-vă ideilor proiectantului care detaliază totul în detaliu, vă întreabă întrebări inteligente, semnați contractul și

Stai. Așteptați o lună lungă, pentru care ați promis că veți face totul. Și tot acest timp - mobilierul vechi și inconfortabil veni peste ochii tăi și sub picioarele tale, te enervează. Stai. A dispărut bucuria cumpărării spontane? Nimeni din atelier nu te deranjează, nu raportează, nu pune întrebări ... Așteaptă.

Și apoi așteptați încă două săptămâni. Și tu deja ești furios. De la determinarea anterioară nu a rămas atât de mult - și dacă merită să înceapă o modificare? Și mai aștepți, mai mult și încă trei ore, pe care ai plecat mai devreme. Și aici aduceți un nou kit. Ei se adună, se aranjează și un gând perfect clar îți lovește mintea. Nu asta!

Dacă nu folosiți Scrum

Aceasta nu este ceea ce ați imaginat. Deși acest lucru poate fi în concordanță cu ceea ce ați spus designerului, dar acest lucru nu este ceea ce aveți nevoie. Tapițeria este prea ușoară și absolut nu ca noua ta iubită. În plus, sa dovedit că câinele dvs. - o alergie la puf în perne. Masa este prea înaltă, iar scaunele sunt prea voluminoase. Dar este deja de acord cu producătorul și au semnătura dvs. Nu puteți schimba nimic, sau mai degrabă puteți, dar va costa aceeași sumă de bani și va lua cât mai mult timp. Despre garanția rezultatului, nu puteți spune deloc.

Gestionarea dezvoltării software-ului este aproape ca și gestionarea unei fabrici de mobilă

Apropo, știi de ce a durat atât de mult să aștepți? Ați putea fi încântați să cred că maestrul a lucrat timp de săptămâni la bord fiecare dintre căști sau gherghef dvs. de zile realizate cusatura de cusatura, să-l facă în timp pentru a face o broderie de înaltă calitate. Că toate acestea au fost verificate pe oră cu designul, iar managerul de calitate supraveghea vigilent producția.

În primul rând, puteți dispune o dezvoltare pas cu pas a mobilierului, a cărei dezvoltare ar trebui să se desfășoare în funcție de prioritățile dvs. Să presupunem că de cele mai multe ori aveți nevoie de o canapea, deoarece cea veche este deja aceeași, iar fotolii și masa pot suferi un pic mai mult. În consecință, canapeaua va fi prima din lista priorităților, iar studioul se angajează să o producă și să o livreze în primul rând.

Ce dă? În primul rând, îți satisfacă în primul rând nevoia cea mai importantă, iar izvoarele nu mai scârțâie noaptea. Și, în al doilea rând, în cazul în care noua ta prietena pur și simplu nu-mi place tapițeria si culoare puternic doriți să-l schimbe (tapițeria, nu prietena) - costurile vor fi doar pe canapea, fără a fi nevoie să schimbe tapițeria de pe scaune (de exemplu, pentru cei care nu sunt încă gata .. ). Sau, în general, puteți schimba compoziția ordinului fără nici un cost pentru dvs., eliminând scaunele din acesta și adăugând scaune cu căptușeală.

În al doilea rând, puteți să cereți studioului să vă informeze în fiecare zi despre progresul lucrării. Doar trei întrebări simple: ce sa făcut ieri, care sunt planurile pentru ziua de azi, care sunt problemele - și obțineți control complet asupra situației. Și e bine!

SCRUM vă va ajuta într-o situație în care ...






  • O mulțime de bani și timp au rămas pentru dezvoltarea TK, dar în cursul lucrărilor asupra proiectului, conceptul sau procesele de afaceri s-au schimbat. Pentru a aduce proiectul la capăt în forma descrisă în TOR - nu are sens. Banii pe TK sunt aruncați în zadar. Dezvoltatorul refuză să facă schimbări în timpul desfășurării activității, referindu-se la TOR.
  • Dezvoltatorul prezintă proiectul în ultima zi înainte de a începe. Cu toate acestea, totul nu se face așa cum v-ați imaginat. Aveți nevoie de o modificare semnificativă. Dezvoltatorul în felul său interpretează cerințele descrise în TOR și refuză să facă modificări la proiect pe această bază.
  • Trebuie să executați coloana vertebrală a proiectului Internet, cu un buget și un calendar minim posibil. Funcțiile suplimentare ar trebui dezvoltate după lansare, când proiectul începe să descurajeze investiția inițială.

Familiar? Cel mai probabil în dezvoltarea a fost folosit modelul "cascadă", sau toate în general a mers ca-oribil. Scrum este o alternativă fără dezavantajele enumerate mai sus. Iată de ce:

Mecanica proceselor în dezvoltarea web-ului

Ok, să trecem la dezvoltarea web personalizată. Despre modalitatea de a formaliza relația contractuală, voi vorbi la sfârșitul articolului. Între timp, hai să vedem cum va fi construit procesul de lucru. Presupun că principalul criteriu pentru fericirea clientului - acest lucru este atunci când nu devine doar un produs este conform cu cea specificata in ToR, dar ceea ce a dorit cu adevărat. Și primește acest produs cât mai repede posibil. Să nu pierdem câteva funcții și ele vor fi implementate în mișcare, dar proiectul va începe imediat să aducă bani, fără a aștepta realizarea completă a tuturor părților interne mici.

Apoi, vom lua în considerare doar faza de programare (pentru simplitate), deși, dacă se dorește, această abordare poate fi extinsă la alte faze ale lucrării. Voi remarca faptul că Scrum se prezintă cel mai bine pe proiecte complexe din punct de vedere tehnic, cu o cantitate mare de programe (deși, cu anumite adaptări, este, de asemenea, potrivit pentru asamblarea site-urilor tipice). Deci, lucrul la Scrum este construit după cum urmează.

Înapoi în loc de cerințele tehnice

Backlog - un document care conține o listă a tuturor cerințelor pentru proiect (viziunea proiectului, o listă a ceea ce ar trebui implementat). Elementele din listă sunt ordonate în ordinea importanței. În cursul proiectului, lista și prioritățile pot varia, în funcție de nevoile clientului, idei noi sau condiții în schimbare.

Da, în clasicul Scrum se înțelege că clientul proiectului poate face orice schimbări chiar în cursul proiectului (dar nu în stadiul actual de dezvoltare). Cu toate acestea, în cazul dezvoltării site-ului, bugetul este în mare parte fix (excepție - unele proiecte de pornire). Aceasta înseamnă că abilitatea clientului de a influența procesul de implementare este, de asemenea, limitată.

Cu toate acestea, consider că nevoia de a adăuga sau de a schimba orice funcții de proiect pentru client este foarte relevantă. Acest lucru ajută la dezvoltarea unui proiect pe care clientul are într-adevăr nevoie, și nu ceea ce este descris formal în TOR. Prin urmare, ca întârziere, folosim de obicei o listă de sarcini din termenii de referință descriși și stabiliți în contract, plus fixați în plus. acorduri de rafinament care apar în timpul desfășurării activității.

Sprint - stadiul de dezvoltare. Întreaga dezvoltare a proiectului se desfășoară pe etape scurte (sprint). Funcțiile care trebuie implementate pe fiecare sprint sunt fixe (nu pot fi modificate în timpul sprintului). Ele sunt împărțite în sarcini, iar sarcinile au evaluări și priorități.

În clasicul Scrum se presupune că durata sprintului este fixă ​​și, de regulă, este de la 2 la 4 săptămâni, în funcție de experiența echipei. Deoarece nu toate site-urile au nevoie de o astfel de fază de dezvoltare îndelungată (în special având în vedere că dezvoltarea este efectuată în paralel de 2-3 programatori), am decis să limităm doar durata maximă a sprintului. Am fost abordați de sprinturile de două săptămâni. Cu toate acestea, dacă echipa poate colecta proiectul în 3 zile - atunci vom forma un sprint de 3 zile.

Rezultatul muncii fiecărui sprint este un proiect complet testat, în care sunt implementate toate funcțiile sprinturilor anterioare + creșterea funcționalității față de cea actuală. Acest lucru permite lansarea proiectului în primele etape, implementând doar funcționalitatea minimă necesară și deja în paralel cu activitatea site-ului, dezvoltarea următoarelor părți importante ale proiectului.

Această abordare este bună, de exemplu, pentru magazinele online care pot lansa vânzări (începe să câștige profit pentru client) chiar înainte de punerea în funcțiune a tuturor funcțiilor planificate.

Hu de la hoo pe proiect

Când se dezvoltă scrum la proiect, există câteva roluri cheie. Proprietarul produsului este proprietarul produsului. Responsabil de reprezentarea intereselor clientului și ale utilizatorilor finali asupra proiectului. Nu este membru al echipei de dezvoltare. În mod ideal, ar trebui să fie reprezentantul clientului. Cu toate acestea, deoarece acest rol impune cerințe foarte ridicate cu privire la experiența și competența individului în proiectarea și dezvoltarea de proiecte pe internet, precum și necesită o implicare constantă personală în proiect (care nu este întotdeauna posibil pentru client) - în acest caz, acest rol este îndeplinit de către managerul de proiect.

Și, desigur, există o echipă de dezvoltatori pe proiect :-) Și în ea: Scrum Master este un membru al echipei care urmează principiile Scrum și desfășoară întâlniri zilnice. Rolul nu implică nicio autoritate suplimentară pentru proiect, cu excepția Scrum-ului însuși.

Lucrări pe etape și priorități







Trimiteți-le prietenilor: