Da li Scrum Development Team daje podršku korisnicima tokom trajanja Sprinta?

Danas sam dobio još jedan zanimljiv email sa pitanjima koja se odnose na implementaciju Scrum procesa u jednom velikom posllovnom sistemu. Email sa pitanjima i moje odgovore prenosim u celosti.

Email sa pitanjima:

“Kako planirati customer support i rješavanje bugova u sprintu? Kako je projekt veliki i prekonekoliko komponenti (mi smo jedna) se integrira u finalni proizvod – naravno da bude grešaka, a i recimo potreba za intervencijom direktno na bazi (customer je nešto krivo odradio ili ide neki mass-data import za koji još nemamo sučelje napravljeno, pa da se ne radi dugotrajan jedan-po-jedan proces kako bi to ustvari trebalo, onda mi to direktno napravimo na bazi, ali naravno potrebno je to ipak istestirati sa naše strane na nekom dumpu što oduzima vrijeme). Na zadnjem sprintu to nam je odnijelo minimlano 50% vremena. Inače sprint planiramo sa dnevnih 5 ili 6 sati, ostalo je za customer support i bug resolution. Backloog grooming isto se radi za vrijeme sprinta, i kaže da to treba uzeti maksimlano 10% vremena – ali gdje i kako se to sve vrijeme uračunava?

Pošto je u pitanju veliki projekt sa integracijom svih komponenti, jasno je da mora biti i testa svega toga integiranog kao cjeline jer znamo da komponent test sa mockovima nije isto što i “pravi” test cijeline – kako se to uklapa u scrum?”

Moj email sa odgovorima:

Što se tiče bagova:
– Scrum proces bagove tretira tako što ih dodaje kao stavke u Product Backlog,
– Scrum kroz stalna poboljšanja Definition Of Done teži tome da nema bagova u isporučenom inkrementu ili da bagovi budu takvog uticaja na rad softverskog sistema da mogu da sačekaju završetak aktuelnog Sprint-a da bi u sledećem Sprint Planning-u ušli, zbog visokog prioriteta, u sledeći Sprint Backlog,
– Development Tim sprovodi standarde u toku Sprinta , koji su definisani u Definition Of Done, da bi stalno održavali i poboljšavali kvalitet svog rada i kvalitet proizvoda. Standardi na koje može da se oslanja Definition Of Done mogu da budu interno ili eksterno definisani.

Što se tiče podrške:
– Scrum Development Tim ne pruža podršku u toku Sprinta.

Što se tiče faze Razvoja:
– Dekompozicija preuzetih stavki Product Backlog-a u stavke Sprint Backloga i dalje redefinisanje i poboljšanje definicije već urađenih stavki Sprint Backloga se radi u toku faze Razvoja. U toku faze razvoja Development Tim ne radi samo razvoj. Vreme potrebno da se radi na definisanju i poboljšanju definicije Sprint Backlog stavki u toku Razvoja a i na ostalim aktivnostima, kao što su Testiranje ili recimo pisanje dokumentacije za održavanje i pisanje korisničkih uputstava, je vreme koje Development Tim mora da ima na umu kad na Sprint Planning-u preuzima stavke Product Backloga.

Ovo je u skladu sa Scrum-om koji je definisan Scrum Guide-om na scrum.org.

Mislim da je očigledno zašto se u Scrum Guide-u (jul 2013) kaže:
“Scrum (n): A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.
Scrum is:
– Lightweight
– Simple to understand
– Difficult to master”.

Da, teško ga je implementirati a da sve bude  urađeno u skladu sa definicijom Scrum-a.

To da vaš Developer tim radi dnevno 5 sati na projektu, a ostalih 3 sata na podršci i ispravljanju bagova, nije u skladu sa Scrum-om i dovodi do smanjene produktivnosti Development Tima. Vi nemate implementiran puni Scrum proces već neku svoju modifikaciju Scrum-a.

Ono što ja vidim kao vaše ključne probleme, a koji su doveli do toga da na pomenutom projektu niste mogli da implementirate puni Scrum:
– Vaš nadređeni management nije upoznat sa Scrum-om a ako i jeste onda ga nije prihvatio,
– Vaš klijent nije upoznat sa Scrum-om i ako jeste onda nije prihvatio vašu želju da radite u skladu sa Scrum-om,
– Pretpostavljam da je u procesu ugovaranja bilo zahtevano da se da procenjeno vreme potrebno za realizaciju projekta i da je data pogrešna procena (ne ulazim u razloge). Ugovaranje je izuzetno bitan proces (preduslov) da bi moglo da se radi u skladu sa Scrum preporukama,
– Projekat od početka nije bio predviđen da bude realizovan u skladu sa Scrum-om i vi samo interno (na nivou vašeg internog razvojnog tima) pokušavate da na tom projektu primenjujete Scrum,
– Evidentan je manjak ljudi (organizovanih u više Scrum timova) koje treba da imate da bi mogli da realizujete projekat u zadatim vremenskim okvirima,
– Neophodno je da imate tim koji će da radi na podršci (To se obično zove drugom linijom podrške. Prva linija podrške je HelpDesk.) i uklanjanju bagova (naravno onih manjih). Ovo je organizaciona stvar i nije u suprotnosti sa Scrum-om. Ti ljudi koštaju ali nezadovoljni korisnici koštaju više. Znam da, nažalost veoma često, to funkcionalni management ne može da shvati ali treba raditi na tome da promene svoje stavove.

Na kraju imam potrebu da vam prenesem neke moje zaključke koje baziram na iskustvu koje imam u radu sa softverskim timovima u poslovnim sistemima kojima osnovna delatnost nije proizvodnja i prodaja softvera:

– Mislim da ste vi uradili ono što ste mogli da bi vaš tim mogao da radi i razvoj i podršku tj. da zadovolji zahteve poslovanja vašeg poslovnog sistema,
– Mislim da vam definitivno treba tim za podršku (to sam napisao i u prethodnom emailu) za drugu liniju podrške (ili prvu ako nemate help desk) koji mora da zna i da rešava i slučajeve recimo pogrešnog importa podataka u bazama itd…,
– Kad su u pitanju timovi koji su zaposleni u firmama čija osnovna delatnost nije proizvodnja softvera, nemoguće je imati tim koji radi samo razvoj tj. on obično radi i podršku ali ga makar treba dovesti samo do toga da radi samo podršku za koju nije sposobna prethodna linija,
– Veći bagovi na produkciji prekidaju sve aktivnosti razvojnog tima i svi rade na rešavanju baga,
– Mislim da treba da imate par osoba koje će jedine biti odgovorne (pored ostalih zaduženja) da kreiraju bild (verziju) tj. da sastave sve što nekoliko razvojnih timova uradi u nekom periodu i donešena je odluka da to ide u bild,
– Mislim da obavezno morate da imate Testni tim sa svim potrebnim znanjem, definisanim procedurama i uputstvima (dokumenta koja definišu organizaciono rad testnog tima, zatim recimo ko i kako definiše metriku itd. (za ovo su dobri ISO standardi ako nemate svoje)), testnim okruženjem i adekvatnim alatima.

Odgovor na moj email:

“Mi ne radimo po scrumu, težimo tome, ali želimo mijenjati stvari (barem se nadam 🙂 – to je ono kako ja to vidim i doživljavam i čini mi se da ide na bolje, a to je ustvari jedino važno. Onom visokom managementu je važno samo da stvari budu odrađene na zadovoljstvo kupca, što je dobro naravno, ali se boje promjena i ne vjeruju im baš i to ide dosta teško. A implementirati scrum samo interno – nije to – to. Velike firme su ustrojene pomalo po vojnom principu, gdje se ovakove odluke (promjena metodologije recimo) donose iz generalštaba koji nema uvijek direktnu vezu i osjećaj za stanje na terenu 🙁 “

Leave a Reply

%d bloggers like this: