Straipsniai

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

Paleistas Australiškas projektas verslui

Po kelių mėnesių intensyvaus darbo paleistas projektas YouAre skirtas Australijos rinkai. Verslui skirtame portale įmonės galės skelbti apie savo paslaugas ir jas pristatyti potencialiems klientams. Dirbti su Australijos klientais patiko, nes kai mes dirbame jie miega, o kai mes miegame, jie testuoja mūsų darbus. Procesas vyksta non-stop.

Agile projektų valdymas su Scrum

Norėtume arčiau susipažinti su agile projektų valdymu su Scrum, trumpai paaiškinti roles ir priemones taip pat praktinį elgesį. Nors Scrum neturi labai ilgos koncepcijos fazės, tai nereiškia, kad elgiamasi be plano. Yra visiškai priešingai. Tačiau paskaitykite patys… Tuo tarpu, kai klasikiniame procese pagal taip vadinamą krioklio modelį iš anksto sudaromi detalūs reikalavimai su atitinkamais darbo nurodymais visam projektui, Scrum kolektyvai gauna atitinkamus tikslų nurodymus tik prieš įgyvendinimą ir tik atitinkamamai daliai (prieaugiui) bendrai programuojamos software. Aukštai kvalifikuotas ir tarpdiscipliniškas Scrum kolektyvas aktyviai papildomai prisideda prie planavimo ir koncepcionalaus tolesnio software vystymo. Taip gali būti paprieštarauta pirmai klaidingai nuomonei, Scrum esąs „beplanis“.

Dirbant su Scrum paprasčiausiai nenurodomas tikslus įgyvendinimas, o išvystomas kolektyve, kai šiuo atveju yra labai pranašus grupės dinaminis procesas kolektyve, o einamos žinios nuolat įsilieja į darbą. Scrum sąvoka reiškia: sudėtingų ir didelės apimties procesų padalijimas į dalinius projektus (prieaugius), kurie vienas po kito įgyvendinami į taip vadinamus bėgimus (iteracijas), kurie paprastai trunka nuo dviejų iki keturių savaičių, ir kurių tikslas yra funkcionalios ir kokybiškai aukštos vertės kodo tiekimas. Scrum pripažįsta, kad visas programavimo procesas yra nenumatomas. Svarbiausias Scrum projekto tikslas yra tiekti geriausią software atsižvelgiant į išlaidas, funkcionalumą, laiką ir kokybę!

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

Planuojate vertingus pokyčius savo organizacijoje?

Susisiekime

Kas yra Impact Mapping ir kaip tai yra naudojama?

Impact Mapping yra strateginė planavimo technika ir reikalavimų analizė. Ji padeda įmonėms susikoncentruoti ties projekto darbo tikslu ir skatina tikslingą darbą. Sąsajos kaip Lean Startup arba Continuos delivery darosi vis reikšmingesnės, tuo tarpu įprasta, į išbaigtumą ir tikslumą nukreipta sąvoka „reikalavimas“ vis labiau nustumiama į antrą planą. (Palyginti: http://btdays.de/2014se/sessions/continuous-learning-agile-anforderungsanalyse-mitimpact-mapping).

Šiame kontekste Gojko Adzik sukūrė taip vadinamą Impact Mapping, kuris užsiima problema ir atlieka špagatą tarp plano ir eksperimento (Palyginti: http://de.slideshare.net/springify/software-that-matters-agileanforderungsanalyse-mit-impact-mapping). Projektai turi vienas nuo kito nepriklausomą, dinamišką sąsają su žmogumi, kitais projektais bei organizacijomis ir bendruomenėmis aplink juos. Impact Mapping yra kooperatyvus ir kūrybingas metodas, kuris suteikia geresnę apžvalgą apie vykstantį projektą. (Palyginti: http://de.slideshare.net/springify/softwarethat-matters-agile-anforderungsanalyse-mit-impact-mapping).

Taip veikia Impact Mapping

Impact Mapping sujungia skirtingus metodus vienas su kitu ir pateikia projektus vizualiai. Metodas yra skirtas spręsti sudėtingoms problemoms ir tinka pirmiausia nevienalytėms grupėms. Išankstinių žinių beveik nereikia. Pradžia su Impact Mapping yra visada susijusi su verslo tikslu. Taip projekto tikra nauda gali būti labiau pabrėžta. Impact Mapping reiškia „Poveikio kartografavimas“ ir susideda iš žodžių „Paruošimas“ (Preparation) ir „Kartografavimas“ (Mapping). Pirmoje fazėje reikia nustatyti tikslus, rasti tinkamus matavimo metodus ir nustatyti pirmą atkarpą. Antroje fazėje viskas pateikiama panašiame į Mindmap žemėlapyje ir vizualizuojama (Palyginti: http://www.wolter.biz/tag/impact-mapping/).

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

Planuojate vertingus pokyčius savo organizacijoje?

Susisiekime

Plano varoma plėtra ir vizijos varoma plėtra

Klasikinio projektų valdymo procese visa vystomo sprendimo apimtis yra iš anksto nustatoma ir tiksliai apibrėžiama. Tokioje planavimo ir tikslinimo fazėje – “didelis dizainas priekyje“ – projektų vadovas dažnai įgyvendindamas projektą nustato, kad laikas ir biudžetas yra neteisingai suskaičiuoti arba kad kolektyvas negali apdoroti kliento poreikių ir reikalavimų. Dėl „plano varomos plėtros“ dažniausiai kyla stresas, nepasitenkinimas ir nepakankamas ekonomiškumas. (Šaltinis: http://t3n.de/magazin/praxisbericht-scrum-kanban-scrumbuts-agiles-232822/)

Agile procesas pirmiausia pasižymi tuo, kad projekto pradžioje laikas ir biudžetas nustatomi kaip konstantos. Kartu su klientu yra kuriami reikalavimai, kuriuos bus galima realizuoti šiame lauke. Tuomet kalbame apie „vizijos varomą plėtrą“. Šio veikimo modelio privalumas yra pirmiausia tai, kad klientas proceso metu gali dalyvauti projekte ir nustatyti atskirus „to do“ nuo iteracijos iki iteracijos (taikymo srities valdymas). Skaidrus procesas padeda ne tik programuotojams dirbti tikslingai. Ir klientas jaučiasi geriau dirbdamas su einamu projektu. Vertybių varomo darbo metodo dėka kolektyvas gali pasimokyti iš praėjusių iteracijų ir išmoktas žinias panaudoti sekantiems žingsniams. (Š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