„scrum klaidos“

Kaip išvengti Scrum klaidų

Produkto savininkas kaip kompetentingas asmuo. Produkto savininkas turi būti visada integruotas į programavimo procesą ir aktualų programavimo statusą kaip prailginta kliento ranka ir būti visada pasiekiamas kolektyvui iškilus klausimams ir neaiškumams. Taip pat jis rūpinasi nuolatine komunikacija su klientu.

Jokių nurodymų „iš išorės“. Kolektyvas pats vienas nusprendžia, kiek užduočių bus atliekama viename sprinte. Nurodymų „iš išorės“ reikėtų būtinai vengti, kad būtų garantuota geriausia kokybė.

Jokių individualistų kolektyve. Scrum egzistuoja kolektyvo ir bendro darbo su projektu pagalba. Kolektyvo nariai turėtų vengti individualumo ir išvystyti Mes-Jausmą. Kolektyvas laimi ir pralaimi kartu!

Aiškios atsakomybės. Produkto savininkas yra atsakingas už reikalavimų sukonkretinimą. Jis aprašo ir „išverčia“, kas pabaigoje turi būti sukurta. Už techninį įgyvendinimą ir technologinius požiūrius yra atsakingas vien tik kolektyvas.

Jokių pertraukų sprinto metu. Jeigu sprinto metu iškyla itin svarbios temos, reikėtų mėginti aptarti šias po sprinto ir privesti sprintą be pakeitimų iki galo. Ypač svarbiais atvejais, reikėtų vietoj pakeitimo sprinto metu nutraukti visą sprintą.

Kolektyvo nariai nesprendžia patys apie reikalavimus. Produkto savininkas yra atsakingas už produktą, taip pat atsakingas už galutinį rezultatą. Jis taip pat atsakingas už reikalavimus ir ypatumus. Kolektyvo nariai klausimų atveju turi pasitarti su produkto savininku ir negali patys savarankiškai priimti sprendimus, kurie peržengia techninių požiūrių ribas.

Šaltinis: https://www.techdivision.com/_Resources/Persistent/a90c984a454ba0b8478694b83f7a8822514b8fc8/Agiles-PM-Whitepaper0502.pdf

Planuojate vertingus pokyčius savo organizacijoje?

Susisiekime

Didžiausios Scrum proceso klaidos

Praktikoje pasitvirtino, kad pradinis nebaigtų darbų sąrašas su didelio abstraktaus lygio suformuluotais reikalavimais sudaromas kartu su klientu. Taip surinktų reikalavimų pagrindu gali būti padarytas pirmas apimties įvertinimas. Mes kalbame apie dėl nebaigtų darbų sąraše surinktus reikalavimus, x sprintų kas 2-4 savaitės su x asmenų. Šiuo paskaičiavimu gali būti nustatyta projekto apimtis jau labai ankstyvoje fazėje. Užsakovas dar turi galimybę paskaičiuotus įvertinimus sumažinti arba nustatyti žemesnę įgyvendinimo ribą. Atliekant projektą į tai bus atitinkamai atsižvelgta. Iš esmės paeiliui skaičiuojamos tik iš tikrųjų atsiradusios apimtys, tuo tarpu bet kuriuo metu galima pasinaudoti projekto valdymo priemonėmis ir kasdien pasižiūrėti į šiuos skaičius ir stebėti juos. Taip išvengiama nemalonių staigmenų!

Taip galima su Scrum – nors tai nėra pagrindinė Scrum idėja – IT projektą įgyvendinti ir su iš anksto nustatytu biudžetu. Šiuo atveju galima, jei biudžeto neužtektų norimoms savybėms, pasitarus su klientu išbraukti vieną arba kitą funkcionalumą arba pritaikyti jį, taip prisiderinant prie nustatyto biudžeto – o tai yra labai svarbu – nesiimant kompromisų dėl kokybės!

ScrumButs

Scrum projekto metu retrospektyvos greitai parodo, kaip galima padidinti kolektyvo efektyvumą ir pasirodymą. Tačiau yra pavojus, kad savi pakeitimai – taip vadinami ScrumButs – atliekami Scrum ir pamirštami svarbūs elementai. Tokiais atvejais Scrum esmė buvo tik dalinai suprasta.

ScrumButs pavyzdžiai:

Mes naudojame Scrum, tačiau

mums nereikia Scrum meistro dėl mūsų mažo kolektyvo

nereikia atskirų užduočių apimties įvertinimo

pratęsiame sprintą, kol pasiekiame tikslą

atsisakome retrospektyvų

(Šaltinis: http://t3n.de/magazin/praxisbericht-scrum-kanban-scrumbuts-agiles-232822/)

Šaltinis: https://www.techdivision.com/_Resources/Persistent/a90c984a454ba0b8478694b83f7a8822514b8fc8/Agiles-PM-Whitepaper0502.pdf

Planuojate vertingus pokyčius savo organizacijoje?

Susisiekime