boBYTE CONSULTING

Metodologia de Management a Proiectelor Software SCRUM se bazeaza pe SPRINT-uri. Asa cum un alergator de maraton incearca sa obtina un ritm constant pentru a ajunge linia de finish, echipele SCRUM trebuie sa dezvolte produse cu o anumita viteza pentru a reusi livrarea in timpul alocat proiectului.

Un SPRINT are o data de start si una de incheiere. Sunt evenimente fixate in timp, in care nicio modificare nu este permisa. Terminarea unui SPRINT poate fi considerata milestone pentru proiect, deoarece livreaza rezultatele muncii depuse pe durata timpului de executie: versiune intermediara, actualizarea planului de proiect sau project backlog, status report-uri, etc.

Se recomanda folosirea de SPRINT-uri egale ca durata, pentru a putea usura munca de masurare a progresului proiectului. Acestea ar trebui sa nu fie mai lungi de 3 saptamani, nici mai scurte de o saptamana. Dimensiunea unui sprint variaza de la proiect la proiect, functie de numarul de pachete de lucru incluse.

Cum trebuie definite sprinturile?

Incercati sa impartiti timpul total de executie al proiectului in ferestre egale folosind regula de mai sus si pastrand in atentie toate pachetele de lucru definite in planul de dezvoltare. Spre exemplu pentru o versiune de aplicatie care trebuie livrata in 3 luni, recomandam 10 sprint-uri (de 7 zile lucratoare) si unul final (ultimele 5 zile) pentru a pregati versiunea de release si documentatia aferenta.

Project Managerul ar trebui sa pastreze ultimul sprint atat de scurt cat sa se simta confortabil in a-si rezolva sarcinile legate de inchiderea proiectului, si este si ultima sansa de a asigura un release bug-free, documentat, etc. In aceasta ultima etapa, in cazul in care mai exista probleme, doar cele majore se mai pot rezolva.

Primul sprint ar trebui intotdeauna consacrat etapei de analiza. Fiti siguri ca doua or de analiza pot salva doua zile de re-work. In aceasta faza SCRUM Master-ul si Product Owner-ul ar trebui sa se intalneasca sa discute despre ce trebuie executat, care sunt prioritatile si ce resurse se pot aloca. Principalul scop este livrarea unui Project Development Plan coerent, pe care dezvoltatorii sa-l poata urmari.

Numarul de pachete de lucru sau continutul acestora nu se mai modifica odata ce un SPRINT a fost demarat. In cazul in care se descopera probleme sau apar cereri de schimbare pe pachetele existente, acestea vor fi incluse in planul de dezvoltare pentru SPRINT-urile urmatoare, astfel incat sa nu existe interferente in planul curent de lucru.