„scrum“

Kada tinka Kanban, o kada Scrum?

Abu projektų valdymo požiūriai yra Agile metodai, pirmiausia yra kolektyvo mintis. Bendro siūlymo, kada Kanban, o kada Scrum yra geresnis požiūris, nėra. Tačiau galima remtis bazine abiejų metodų charakteristika sprendimui pasirinkti. Pradžioje reikėtų išsiaiškinti sekančius klausimus:

Koks yra projekto sudėtingumas?

Kokio dydžio yra realizavimo kolektyvas?

Kaip greitai ir lanksčiai reikės reaguoti įgyvendinimo metu?

Kokio dydžio gali būti pasirinkti iteracijų žingsniai?

Kokioje projekto fazėje esame (servisas/tolesnis programavimas versus visiškai naujas programavimas)?

Dažnai programinės įrangos projektai yra per maži Scrum požiūriui, kadangi Scrum turi su įvairiais nurodymais ir rolėmis tam tikrą projekto valdymo vadovą. Taigi praktikoje nedideliuose projektuose, pavyzdžiui serviso ir tolesnio programavimo projektuose, Kanban pasireiškė kaip tikslingas požiūris, kadangi jame yra tik minimalūs nurodymai, o planuojami darbai – ypač, jei jie iš pradžių yra sunkiai planuojami – praktiškai pašaukus arba su žymomis ant Kanban kortelių – gali būti įvykdyti. Dėl planuojamų užduočių čia paprastai nereikia nuolatinio aptarimo kolektyve, kaip tai yra nurodoma Scrum kasdieniuose susirinkimuose.

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

Planuojate vertingus pokyčius savo organizacijoje?

Susisiekime

Kanban versus Scrum

Kanban pasiteisino pirmiausia daugelio projektų kolektyvuose, nuolatinėse, blogai planuojamose užduotyse ir mažuose projektuose, kurių negalima dalinti į iteracijas, jis veda link optimizuotos Darbo Tėkmės. Didesniuose, sudėtinguose ir ilgalaikiuose projektuose labiau tinka Scrum.

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

Tiek Scrum tiek Kanban yra glausti (Lean) ir Agile projektų valdymo požiūriai, kurie vieną turi bendro, tačiau iš esmės skiriasi atskirose vietose.

Abu požiūriai yra Lean ir Agile.

Abu metodai naudoja stūmimo principą.

Abiejuose darbas yra dalijamas.

Abu požiūriai riboja darbo progresą.

Abiejuose pirmoje vietoje randasi kaip galima didesnis skaidrumas.

Abu turi tikslą, kaip galima greičiau sukurti funkcionuojančią ir tiekimui tinkamą programinę įrangą.

Abiejuose pirmoje vietoje yra Tėkmė. Kolektyvai organizuojasi patys.

Abiejuose tiekimo planas nuolat gerinamas remiantis empiriniais duomenimis (greičiu ir praėjimo laiku).

Lean principai kilę iš japonų automobilių pramonės. Didžiausias tikslas yra, sumažinti arba sustabdyti sekančius tris išlaidavimo būdus:

Muda – darbas, kuris nesuteikia produktui vertės.

Muri – mašinų ir darbuotojų perkrova.

Mura – procesų nereguliarumas.

Viena turi būti visada apgalvota naudojant Lean metodus – nesvarbu ar Scrum ar Kanban. Su šiais požiūriais ir procesais sukuriami tam tikri nurodymai – ta prasme struktūra. Šių nurodymų įgyvendinimas galimas tik žmogaus, atsižvelgiant į atitinkamą discipliną, komunikaciją ir motyvaciją, taip galima išvengti išvardintų išlaidavimo būdų. Esminės garantijos projekto sėkmei Agile metodai nesuteikia.

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

Planuojate vertingus pokyčius savo organizacijoje?

Susisiekime

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

Pastovi IT projekto kaina

Mūsų požiūriu ir dėl 15-os metų patirties tinklalapių programavimo srityje galime su 100 procentų tikimybe nustatyti, kad programinės įrangos projektų metu iš anksto rimtai ir teisingai galima tik atlikti spėjimus dėl projekto kainos, kadangi yra per daug netikslumų, kurie yra neapskaičiuojami. Todėl pastovios kainos pasiūlymas yra tik iš pirmo žvilgsnio tariamas saugumas užsakovui. Jis tikrąsias išlaidas – o šios dažnai yra daug didesnės nei pradinis pasiūlymas – sumokės kitur, arba betarpiškai už pakeitimų užklausimus arba už aplinkkelius, kaip pavyzdžiui per pagerinimo priemones per kitą tiekėją dėl kokybės stokos bei nebaigtos programinės įrangos. Todėl užsakovui reikėtų žinoti: sąskaitą reikės apmokėti – taip arba kitaip!

Teisingumo dėlei čia reikėtų paminėti, kad dėl ekonominių priežasčių beveik nebus įmanoma sudėtingo IT projekto metu sudaryti tokios kokybės reikalavimų ir įsipareigojimų sąrašo, kad jis būtų pastovios kainos pagrindas. Pastangas rinkoje nebus įmanoma apmokėti, todėl daugiau kyla klausimas, ar yra prasmės sudarinėti pigesnį alibio reikalavimų ir įsipareigojimų sąrašą.

Todėl Scrum yra visiems dalyvaujantiems sąžiningiausias požiūris. Didelis projektas yra padalijamas į mažesnius dalinius projektus ir atskirai įvertinamas. Paskaičiuojama yra tik tai, kas iš tiesų sukelia išlaidas. Visiškas skaidrumas ir kliento integravimas į programavimo procesą įgalina didžiausią saugumą, nes klientas gali bet kada reaguoti. Tai reiškia, kad jis gali – numatomų biudžeto viršijimo atvejų metu bet kuriuo metu – ir susitaręs su Scrum kolektyvu – veikti prieš tai, o bėdos atveju ir nutraukti projektą. Čia yra privalumas, kad iki tol sukurta programinė įranga arba jos dalys gali būti naudojami toliau, kadangi Scrum tikslas yra veikiančios programinės įrangos bei programinės įrangos dalių tiekimas. Tai reiškia: skaidrumą ir mokėjimą tik už iš tiesų atliktas paslaugas! Tai ženkliai geresnis ir ilgalaike perspektyva visiems dalyvaujantiems ekonomiškiausias sprendimas.

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

Planuojate vertingus pokyčius savo organizacijoje?

Susisiekime

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

Scrum apibendrintai

Susirinkimai ir atviri penktadieniai

Susirinkimai Scrum nėra protokolai „iš apačios“ projektų vadovui „viršuje“. Jie tarnauja kaip viso kolektyvo informacijos šaltinis. Kiekvienas gali kasdieniame susirinkime pasakyti, ką jis padarė, ką reikės pradėti toliau ir taip pat, kas galbūt jį užlaikė. Čia įsimaišo ir Scrum meistras. Jis pasirūpina tuo, kad dėmesio centras susirinkimo metu nedingtų – pavyzdžiui todėl, kad kalba nenukryptų link sugedusio kavos aparato. AOE media taip pat įvedė specialias retrospektyvos formas. Prie to priklauso atviri penktadieniai, kurie būna kas ketvirtį metų pagal įvairius metodus, pavyzdžiui kaip atvira erdvė. Pavyzdžiui paskutinio atviro penktadienio metu darbuotojai aptarė, kokias galimybes AOE siūlo atsiliepimams, atvirumui ir skaidrumui arba kaip galima patraukliau organizuoti serviso kolektyvo darbą. Iš to reguliariai susidarydavo darbo grupės.

Apibendrinimas

Kas nori įvesti Scrum, tam neužtenka vien skaityti knygas: aišku Scrum ir Kanban pagrindai yra lengvai suprantami. Drausmingas įvedimas nėra taip lengvai įgyvendinamas. Tačiau tik jis galiausiai veda į „laisvę“ ir ištraukia iš klasikinio projektų valdymo chaoso. Apsimoka apmokyti (klasikinius) projektų vadovus, kolektyvą ir klientus. Ir Scrum koučeris gali būti naudingas. Scrum yra iš esmės daugiau nei naujas programinės įrangos arba produkto kūrimo instrumentas: Scrum veda link paradigmų kaitos, kuri reikalauja mąstymo pasikeitimo tiek iš viso kolektyvo tiek iš klientų. Sąlyga įvesti agile plėtrą kaip įmonės kultūrą, yra drąsa nuolatiniam pasikeitimui, mokymuisi iš klaidų ir noras pagerinti procesus. Esmė: visi darbuotojai, ne tik vadovybė, turi dalyvauti. Tik tuomet agile plėtra įmonėje bus įgyvendinta.

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

Planuojate vertingus pokyčius savo organizacijoje?

Susisiekime

Kada naudoti Scrum, kada Kanban?

AOE media įvedė ir Kanban: Tam yra skirta daug iškabų su daugybe skirtingų dizainų ir daugybe skilčių. Pradžioje kolektyvai dar neturėjo daug patirties, kada koks metodas yra naudotinas: todėl naudojo Scrum ir Kanban paraleliai. Taip buvo galima labai gerai palyginti, koks metodas kokiam kolektyvui tiko geriausiai. Kanban veda link ženklių pagerėjimų kolektyvuose, kurie dirba ne tik su projektu, su nuolatinėmis, blogai planuojamomis užduotimis ir su mažesniais projektais, kurių negalima dalinti į iteracijas. Dideliems, sudėtingiems užsakymams ir ypač ilgalaikiams projektams labiau tinka Scrum.

Savęs motyvacija ir skaidrumas

AOE media įmonės vadovybė ir programuotojai tuo pačiu atrado agile vystymąsi sau. Pionieriai iš įvairių įmonės skyrių bendrai susikūrė agile metodų įvedimą, kurie stipriai susiję su savęs motyvavimu ir apsisprendimu ir taip labai tinka prie įmonės mažos hierarchijos ir agentūros vertybių. Agile vystymosi metu vadovybė vis daugiau mąstė apie vidinius veiksnius kaip dalyvavimas, atsakomybė arba motyvacija, kurie kyla iš asmens arba užduoties.

Kad darbuotojai savo užduotis – kaip Scrum ir Kanban – gali rinktis iš projekto patys, veda link didesnio pasitenkinimo darbu ir nuostabių rezultatų. Ypač Scrum įgalina didelį skaidrumą. Iš vienos pusės kolektyve, iš kitos klientui: išleidimo planai reguliarių aktualizavimų kiekvienos iteracijos pabaigoje dėka nebėra tylus noras, bet jau realybė. Ir taip tęsiasi iki sutarties formavimo: AOE media siūlo klientams pavyzdžiui savo sukurtą agile pastovių kainų sutartį.

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

Planuojate vertingus pokyčius savo organizacijoje?

Susisiekime

Scrum ir Kanban

Kaip veikia Scrum?

Kiekvienas Scrum projektas prasideda tuo, kad taip vadinamas produkto savininkas sukuria produkto neatliktų darbų sąrašą, pirmenybinį užduočių sąrašą kolektyvui. Jei produkto savininkas yra netiesiogiai klientas, šis gali užduotį perleisti ir proxy produkto savininkui, kurį pasiūlo užsakovas. Visos užduotys sudarytos iš sprintų (iteracijų), tiksliai nustatytų dviejų savaičių laikotarpių. Planavimo fazėje – sprinto „planavime“ – kolektyvas pasiima užduotis iš produkto neatliktų užduočių sąrašo, kurias realiai galima įgyvendinti nustatytu laiku. Bendrai nusprendžiama, kaip bus dirbama (kolektyvo susitarimas).

Kai produkto savininkas yra atsakingas už projekto sėkmę ir investicijų grįžimą, Scrum meistras rūpinasi tuo, kad visi suprastų procesą ir jo laikytųsi. Taip pat jis prižiūri, kad kolektyvas galėtų netrukdomai dirbti. Kiekvieno sprinto rezultatas yra projekto prieaugis (pavyzdžiui veikiantis kliento prisijungimas), kurio kokybė atlaikė peržiūros procesą ir kurį galima tiekti klientui. Toliau sekanti retrospektyva tikrina pabaigtą sprintą, atsižvelgiant į Scrum proceso kokybę: Kaip jaučiasi kolektyvas? Ar veikia priemonės? Kito sprinto pradžioje kolektyvas renkasi sekančias užduotis iš produkto neatliktų darbų sąrašo, kurias produkto savininkas nustatė kaip ypatingai svarbias – ir sekantis sprintas prasideda.

Kaip galima pritaikyti Kanban?

Daugybė agentūrų naudoja Scrum ir Kanban skirtingiems projektams ir kolektyvams. Priešingai nei Scrum, Kanban yra metodas, kuris turi užtikrinti nepertraukiamą darbo eigą (Flow). Tam yra vizualizuojamos visos užduotys ir procesai (taigi ir problemos, kurios šiom trukdo) ir daromos suprantamomis. Tai vyksta iškabos pagalba, kuri yra padalinta į eilutes ir skiltis (Lanes). Į šią iškabą keliauja visos užduotys bilietų virš atskirų skilčių forma. Kiekviena skiltis reiškia darbo žingsnį. Taip projekto dalyviai gali bet kuriuo momentu matyti, koks statusas yra priskirtas kokiai užduočiai.

Šalia to yra riba paraleliai vykstančioms užduotims. Tai reiškia, kad skiltyje „Plėtra“ pavyzdžiui vienu metu gali būti tik keturi bilietai. Tikslas yra, kad kiekvienas darbuotojas pagal galimybes dirbtų tik su viena užduotimi, o ne su keliomis paraleliai. Už to slypi darbo eigos mintis: bilietai turi eiti pagal galimybes vienodai ir be didelių laukimo pauzių arba blokadų per neatliktų užduočių sąrašą. Kas trukdo darbo eigą, yra analizuojama ir galimai šalinama. Šiuo būdu galima vizualizuoti proceso problemas ir jas viena po kitos išspręsti. Priešingai nei Scrum, Kanban vizualizuoja tik aktualų procesą, tačiau šio reikšmingai nekeičia.

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

Planuojate vertingus pokyčius savo organizacijoje?

Susisiekime