Straipsniai

Scrum išlaidų paskaičiavimas

Dažnai užsakovas nurodo tikslią kainą, kas realybėje turi neigiamų savybių: visų pirma tam tikrus reikalavimus ir savybes iš anksto dažnai sunku normaliai įvertinti, kadangi trūksta patirties ir išsamios informacijos. Antra, didžioji dalis IT projektų yra tokie, kad juos įgyvendinant dažnai atsiranda didelių pasikeitimų. Kadangi reikalavimai – pvz. dėl pasikeitusių rinkos sąlygų – keičiasi arba išaiškėja, kad iš anksto suplanuotus sprendimus – dėl bet kokios priežasties – negalima įgyvendinti realybėje. Po to seka dvi problemos, kurios yra gana svarios ir leidžia pažiūrėti užsakovui į taip atrodantį pastovios kainos saugumą kitoje šviesoje.

Protingai dirbantis tiekėjas skaičiuoja – o jis turi dėl ekonominių priežasčių – įskaičiuoti netikrumus ir apmąstymus dėl trūkstamos išsamios informacijos ir patirties į pasiūlymą, kas gali reikšti užsakovui, kad jis už norimą darbą mokės ženkliai daugiau.

Būtent agentūros labai valdomos kainų. Užsakovas apsisprendžia dėl galimai pigiausio tiekėjo. Tačiau nesileiskime to manipuliuojami: šiandieną nėra nieko dovanai. Taip pat, kaip Jūs neatiduodate savo produktų arba paslaugų už mažai pinigų, taip pat tai darys agentūra. Todėl dažnai atsitinka taip, kad manomai pigiausias tiekėjas gauna užsakymą, tačiau šis jo įgyvendinime dėl biudžeto priežasčių neteisingai veikia, tiekiamas pusiau baigtas produktas ir/arba pabaigoje reikalaujama galutinio paskaičiavimo, kad būtų „švarus“ paskaičiavimas. Todėl taip vadinamas laimikis gali baigtis katastrofa. Blogiausiu atveju eina kalba nebe „vien“ apie pinigus, o galimai apie įvaizdį arba nuostolius.

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

Planuojate vertingus pokyčius savo organizacijoje?

Susisiekime

Scrum privalumai

Išsekimo diagrama

Aktualus programavimo statusas idealiu atveju yra parodomas taip vadinamoje išsekimo diagramoje, kurioje ant x ašies žymimas laiko tarpas, o ant y ašies – užduotys arba istorijos momentai. Grafikas iš kairės viršuje iki dešinės apačioje rodo optimalų projekto vyksmą. Priklausomai nuo aktualios išsekimo diagramos linijos nukrypimo nuo šio grafiko galima labai greitai nuspręsti, ar programavimo kolektyvas spėja su laiku ar yra uždelsimų, kuriuos reikės pasivyti pabaigoje. Kadangi visi projekto dalyviai, taigi ir klientas (!!!), turi prieigą prie šio grafiko, taip garantuojamas didžiausias skaidrumas įgyvendinimo metu. Taip galima kontroliuoti nukrypstančius nuo grafiko ir imtis priemonių, kad sugrąžinti projektą vėl į pradines vėžes.

Scrum privalumai

Agile programinės įrangos kūrimo privalumai yra įvairiapusiški. Pirmiausia tai yra taip, kad Scrum projektai turi didesnį lankstumą, kadangi didelis projektas yra skaldomas į dalinius projektus (sprintus), o šie įgyvendinami atskirai ir vienas po kito. Po kiekvieno dalinio projekto seka apžvalga. Atradimai įsilieja į sekančius dalinius projektus. Taip galima reaguoti į rinkos pasikeitimus arba naujus atradimus ir idėjas, susijusius su produktu, ir atsižvelgti į juos sekančiuose sprintuose.

Vienas svarbiausių Scrum privalumų yra gili kolektyvo dvasia. Reikalavimai ir problemos diskutuojami ir sprendžiami kolektyve. Kryžminio funkcinio kolektyvo ir grupės dinaminio proceso dėka gaunami daug geresni rezultatai. Šalia to patys save organizuojantys kolektyvai dirba efektyviau.

Vienas didžiausių Scrum privalumų yra kaip įmanoma didesnis skaidrumas. Visi projekto dalyviai turi prieigą prie neatliktų darbų sąrašų, išsekimo diagramų su projekto pažanga, projekto atkarpomis taip pat kliūtimis kiekvienu momentu, taip gaunamas visiškas aktualaus programavimo statuso skaidrumas. Čia galima laiku reaguoti, kad išvengti nemalonių staigmenų.

Nuolatinės diskusijos grupėje taip pat aptarimo po kiekvieno sprinto metu garantuojamas pastovus kokybės gerėjimo procesas, kuris labai teigiamai veikia profesionalius rezultatus ir ekonominius veiksnius. Dėl dalinio įgyvendinimo programuotojai dirba labiau susikaupę ir susikoncentravę. Dėl darbo kolektyve ir vienas kito parėmimo kyla motyvacija ir darbo rezultatai tampa geresni.

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

Planuojate vertingus pokyčius savo organizacijoje?

Susisiekime

Produkto neatliktų darbų sąrašas

Produkto savininko reikalavimai yra fiksuojami produkto neatliktų darbų sąraše. Produkto neatliktų darbų sąrašas tai pirmenybinis ir į vartotojus orientuotas sąrašas su reikalavimais, į kuriuos reikia atsižvelgti vystant produktą. Idealiu atveju įrašas vartotojų istorijos forma atrodo kaip atsakymas į klausimą „Kas nori ko ir kodėl?“ pagal sekantį pavyzdį:

Kaip vartotojas x norėčiau funkcijų y, kad turėčiau z naudos.“

(Šaltinis: http://borisgloger.com/2011/06/20/scrum-essentials-die-sieben-fragen-der-userstory/)

Kliūčių neatliktų darbų sąrašas

Kliūčių neatliktų darbų sąrašas yra blokadų sąrašas, kurios trukto efektyvų, produktyvų kolektyvo darbą. Šis sąrašas dažnai pamirštamas Scrum artefaktuose. Borisas Glogeris savo bloge nurodo „10 patarimų teisingam kliūčių neatliktų darbų sąrašui“, į kuriuos turi atsižvelgti Scrum meistras.

(Šaltinis: http://borisgloger.com/2010/10/04/das-impediment-backlog-10-tipps/):

a) „Pakabink viešoje vietoje. Geriausiai praėjime, kad matytų visi.

b) Rašyk aktyvius sakinius, pvz. „Mums reikia geresnio kavos aparato.“

c) Neužgauliok formuluojant sakinius, tačiau nieko nenutylėk.

d) Kliūčių neatliktų darbų sąrašas turėtų turėti mažiausiai 10 įrašų.

e) Galvok apie tai, kad visos pagerinimo sritys turi būti apdorotos.

f) Daryk tai tvarkingai: tai yra Jūsų kokybės sąmonės išraiška, ar kliūčių neatliktų darbų sąrašas yra tvarkingas ar apleistas. Mes visi projektuojame nuo formos į turinį: netvarkingi grafikai = netvarkingai suprogramuota programinė įranga.

g) Kliūčių neatliktų darbų sąrašas turi keistis. Parodyk perbraukdamas ir pridėdamas, kad TU kaip Scrum meistras kažką veiki.

h) Nesakyk: jis arba ji turi kažką daryti, būtent tu kaip Scrum meistras turi kažką daryti.

i) Aptark kliūčių neatliktų darbų sąrašą kartą per savaitę su savo vadovu. Nurodyk jam nuosekliai pagerinimo galimybes.

j) Aptark kliūčių neatliktų darbų sąrašą kartą per savaitę su kitais Scrum meistrais savo organizacijoje. Aktualizuok jį nauja informacija.“

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

Planuojate vertingus pokyčius savo organizacijoje?

Susisiekime

Sprinto neatliktų darbų sąrašas

Sprinto neatliktų darbų sąrašas yra užduočių sąrašas, kuris yra sudaromas Scrum kolektyvo ir sprinto metu apdorojamas. Užduotys yra kasdien perrašomos ir aktualizuojamos. Sprinto neatliktų darbų sąrašo dėka projektas tampa skaidresnis bei sudaroma apžvalga, kuris kolektyvo narys dirba ties kuria užduotimi ir kokios užduotys dar turi būti įgyvendintos. Šiame aspekte naudojama užduočių lenta (Šaltinis: http://borisgloger.com/scrum/scrum-flow/die-scrum-artefakte/).

Wikipedia aiškina sprinto neatliktų darbų sąrašą panašiai:

Sprinto neatliktų darbų sąrašas skirtas apžvalgai apie sprinte atliktinas užduotis. Šiam tikslui gali būti naudojama užduočių lenta. Ji sudaryta iš keturių stulpelių. Pirmame stulpelyje („Istorijos“) pakabinamos vartotojų istorijos, kurioms įsipareigojo programavimo kolektyvas šiame sprinte (produkto savininkas nustato jų eilės tvarką). Trys sekantys stulpeliai skirti užduotims, kurios atsiranda iš atskirų vartotojų istorijų (ir kurios buvo nustatytos 2-ame sprinto planavime). Pagal darbo statusą užduotys yra arba atviros („Atliktinos užduotys“), tvarkomos („Darbas progrese“) arba atliktos („Atliktos“). Kasdieniame Scrum kiekvienas programavimo kolektyvo narys aiškina, ties kuria užduotimi jis dirbo vakar, ir ar ši buvo atlikta. Užduotys, kurios nebuvo užbaigtos per dieną, yra pažymimos raudonu tašku. Taip kliūtys gali labai greitai būti nustatytos.“

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

Planuojate vertingus pokyčius savo organizacijoje?

Susisiekime

Sprintas

Sprinto ribose, kurios reiškia 4 savaičių iteraciją, atliekamos sprinto planavime aptartos ir kaip svarbiausios nustatytos užduotys (vartotojų istorijos). Sprinto metu programavimo kolektyvas susikoncentruoja ties vartotojų istorijose suformuluotais reikalavimais, kuriems buvo įsipareigota sprinto planavime. Scrum meistro užduotis yra pašalinti bet kokius trukdžius arba kliūtis, kad kolektyvas galėtų susikoncentruoti ties veikiančios programinės įrangos paruošimu ir tiekimu. Scrum meistras negali teikti kolektyvui nurodymų, jis tik padeda kolektyvui pasiekti apibrėžtą tikslą.

Centrinis sprinto tikslas yra, pateikti dalį potencialiai tiekiamos programinės įrangos. Netgi, jei dėl laiko priežasčių arba dėl netikėto sudėtingumo tam tikri sprinto aspektai negali būti įgyvendinti (kaip numatyta), sprintas baigiasi pagal laiko planą – ir privalo parodyti pabaigtą, veikiančią darbo dalį. Taip klientas gali po kiekvieno sprinto nuspręsti, ar jis dalį bendro projekto jau gali bandyti įgyvendinti produktyviai arba sujungti kelias leidimo dalis ir vėliau pateikti online – verslo vertė klientui Scrum yra pirmame plane.

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

Planuojate vertingus pokyčius savo organizacijoje?

Susisiekime

Sprinto apžvalga ir retrospektyva

Sprinto apžvalga

Sprinto pabaigoje seka taip vadinama sprinto apžvalga, kurios metu programavimo kolektyvas pateikia produkto savininkui, o pirmiausia tai ir vartotojui 1-ame sprinto planavime aptartų reikalavimų realizuotą programinės įrangos sprendimą. Produkto savininkas tada nutaria pagal iš anksto suformuluotus kriterijus, ar rezultatas gali būti priimtas ar ne. Tuo tarpu tikslas turi būti pasiektas 100 procentų. Jei tam tikri reikalavimai negali būti visiškai išpildyti, šie produkto savininko perimami į sekantį sprinto planavimo susirinkimą kaip nauja arba pakartotina vartotojo istorija. Tas pats galioja naujoms idėjoms ir reikalavimams, kurie iškyla sprinto apžvalgos metu.

Retrospektyva

Baigiant sprinto apžvalgą seka labai svarbi Scrum projekto atkarpa. Scrum kolektyvas (produkto savininkas, Scrum meistras, programavimo kolektyvas) susitinka taip vadinamai retrospektyvai, kurios metu diskutuojamos bet kokios sekančio sprinto problemos, mokymaisi ir pagerinimo galimybės. Iš principo čia dar kartą kritiškai apžvelgiamas praėjęs sprintas, pažymimi teigiami ir neigiami atradimai, su tikslu, rasti pagerinimo potencialą naujam sprintui. Kai kalbama apie pagerinimus, kurie susiję tik su kolektyvu, šie ir sprendžiami paties kolektyvo. Bet kokie kiti trikdžiai perimami Scrum meistro į taip vadinamą kliūčių neatliktų darbų sąrašą ir perduodami produkto savininkui, kas šis įvertintų juos sekančiam sprintui.

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

Planuojate vertingus pokyčius savo organizacijoje?

Susisiekime

2-as sprinto planavimas

2-ame sprinto planavime programavimo kolektyvas įsipareigoja, kad prieš tai pristatyti reikalavimai bus įgyvendinti. Taip vadinami reikalavimai padalijami į taip vadinamas užduotis, kurios paprastai neturi trukti ilgiau nei vieną dieną. Užduotys paskelbiamos taip vadinamoje užduočių lentoje, taip sudaroma apžvalga apie aktualų sprintą, jam priskirtas užduotis ir atitinkamą statusą. Ir šiam susirinkimui per sprinto savaitę turėtų būti skiriama apie 60 minučių laiko.

Kasdienis Scrum

Sprinto metu programavimo kolektyvas susirenka kasdien taip vadinamame kasdieniame Scrum. Tai reiškia maksimaliai 15 minučių trunkantį susirinkimą, kuriame kolektyvas aptaria aktualų programavimo statusą ir paskutines atliktas užduotis, taip pat šiai dienai numatytas užduotis. Konkrečiai kolektyve aptariami sekantys klausimai: Ką tu veikei vakar? Ar vakar susitvarkei su tuo, ką buvai suplanavęs? Ką veiksi šiandien? Kokias užduotis tu atliksi iki sekančio susirinkimo? Viskas tvarkoje? Ar yra problemų, kurios trukdo tau atlikti užduotį?

Jeigu paaiškėtų, kad atskiros užduotys pavyzdžiui negali būti atliktos vienos dienos metu, šios gali būti suskaldytos į mažesnes užduotis. Jeigu atsirastų klausimų ar problemų, kurios negali būti išaiškintos 15 minučių eigoje, Scrum meistro užduotis yra pasirūpinti šiaip punktais. Šie punktai Scrum meistro yra surenkami taip vadinamame kliūčių neatliktų darbų sąraše ir toliau apdorojami.

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

Planuojate vertingus pokyčius savo organizacijoje?

Susisiekime

 

Scrum susirinkimai

Rolės

Klientas

Ši rolė aprašo – kas nėra taip jau keista – klientą. Jis yra užsakovas, paprastai finansuoja produktą ir paleidžia produktą į apyvartą. Klientas turėtų būti tampriai susijęs su produkto savininku, kurio tikslas yra, nustebinti klientą su tiekiama programine įranga.

Vartotojas

Kaip vartotojas suprantamas vėlesnis programinės įrangos naudotojas. Tai gali tuo pačiu metu būti klientas, kas tiesa nėra privaloma. Vartotojai Scrum procese, yrač sprintų peržiūroje, turėtų dalyvauti, kad įvertintų tiekiamą rezultatą ir duotų atsiliepimus.

Menedžmentas

Menedžmento užduotis yra, sukurti pagrindines sąlygas sėkmingam Scrum projektui. Prie to priklauso reikalingų resursų paruošimas, taip pat Scrum kolektyvo parama, šalinant visokius išorinius faktorius, kurie galėtų pakenkti Scrum projekto sėkmei.

Scrum susirinkimai

1-as sprinto planavimas

Taip vadinamame 1-ame sprinto planavime pristatomi produkto savininko reikalavimai programavimo kolektyvui. Paprastai išreiškus produkto savininkas paaiškina programavimo kolektyvui, ką reikia daryti. Šio susirinkimo metu gali dalyvauti ir vartotojas, t. y. tikras programinės įrangos naudotojas, kuris kolektyvui – kartu su produkto savininku – gali paaiškinti, kaip jis įsivaizduoja atitinkamus funkcionalumus. Programavimo kolektyvas turi laiko, susipažinti su reikalavimais, išsiaiškinti klausimus ir visiškai suprasti reikalavimus.

1-ame sprinto planavime nustatomi ir priimtinumo kriterijai bei vartotojų pripažinimo kriterijai kiekvienai istorijai, kurie tikrinami taip vadinamos sprinto peržiūros pabaigoje. Kiekvieno sprinto tikslas yra naudojimui tinkamos ir pratestuotos programinės įrangos išleidimas. Šio susirinkimo laiko apimtis gali būti 60 minučių per sprinto savaitę (papratai sprintas trunka 2-4 savaites). Sprinto planavimo susirinkime aptarti reikalavimai gali būti žymini sprinto neatliktų darbų sąraše ir ten stebimi.

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

Planuojate vertingus pokyčius savo organizacijoje?

Susisiekime

Programavimo kolektyvas

Programavimo kolektyvas yra atsakingas už produkto savininko neatliktų darbų sąraše užrašytus funkcionalumus. Scrum ypatybė yra ta, kad programavimo kolektyvas sprinto pradžioje taip vadinamo sprinto plane kartu tikrina reikalavimus ir to pasekoje nurodo susitarimą sprinto ir ten nurodytų reikalavimų įgyvendinimui ir įsipareigoja įgyvendinti ten aprašytus reikalavimus. Tuo tarpu reikalavimai vartotojų istorijų forma yra bendrai vertinami ir padalijami į taip vadinamas užduotis, kurios paprastai trunka maksimaliai vieną dieną. Viso programavimo metu kolektyvas yra pirmoje vietoje, o ne vienas programuotojas.

Kolektyvas laimi kartu ir turi kartu organizuotis, jei iškyla netikėtos problemos arba vienas programuotojas atkrenta. Tame yra svarbu tarpdiscipliniškas suvokimas, būti ne tik programuotoju, bet ir perimti testines užduotis ir taip gauti didesnį suvokimą ir papildyti vienas kitą. Pagal projekto dydį ir reikalavimus programavimo kolektyvas susideda paprastai iš trijų iki devynių programuotojų. Programavimo kolektyvai Scrum organizuojasi patys, tai reiškia, kad jie aptaria detalius įgyvendinimo metodus bendrai kolektyve ir stebi vienas kitą. Tolesnės rolės, kurias žinome iš įvairių kitų sąvokų ir programavimo metodų, tačiau kurios nepriklauso prie Scrum rolių, yra klientas, vartotojas ir menedžmentas.

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

Planuojate vertingus pokyčius savo organizacijoje?

Susisiekime

Scrum principai ir rolės

Scrum principai

Scrum apibūdina – ypač palyginus su klasikiniais programavimo metodais – trys sekantys principai:

  • Skaidrumas: pažanga ir projekto trikdžiai yra fiksuojami kasdien ir visiems matomai.
  • Patikrinimas: reguliariomis atkarpomis tiekiamos ir įvertinamos produkto funkcijos.

  • Prisitaikymas: reikalavimai produktui nenustatomi vieną kartą ir visiems laikams, jie yra vertinami po kiekvieno dalinio produkto tiekimo ir reikalui esant pritaikomi.

Scrum rolės

Produkto savininkas

Ši rolė gali būti interpretuojama kaip prailginta kliento ranka. Produkto savininkas teikia reikalavimus ir strateginę judėjimo linkmę įskaitant prioritetų nustatymą reikalavimams arba užduotims. Šie yra, kaip vadinamos vartotojų istorijos, aptarus programavimo kolektyvui, saugomos produkto neatliktų darbų sąraše. Taip iš vartotojo pusės yra aprašomos pageidaujamos ir reikalingos funkcijos. Produkto savininkas bėgimo pabaigoje patikrina, ar pateikta programinė įranga atitinka vartotojo pripažinimo kriterijus ir gali būti naudojama. Produkto savininko sprendimai yra lemiami, nes šis yra atsakingas už galutinį rezultatą ir ekonominius aspektus. Produkto savininkas dažnai skiriamas užsakovo ir sudaro tiltą tarp kliento ir likusio Scrum kolektyvo.

Scrum meistras

Tuo tarpu, kai produkto savininkas yra atsakingas už projekto sėkmę, Scrum meistras garantuoja Scrum procesų sėkmę. Jis moderuoja susirinkimus ir rūpinasi tuo, kad iškilę sunkumai Scrum procese būtų pašalinami. Prie jų priskiriami nepakankama komunikacija ir išoriniai trikdžiai. Scrum meistras dirba kartu su programavimo kolektyvu ir perima vien tik administracines užduotis, neturėdamas teisės duoti darbo nurodymų. Scrum meistras veikia kaip kolektyvo „koučeris“.

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

Planuojate vertingus pokyčius savo organizacijoje?

Susisiekime