Straipsniai

Agile projektų valdymas su Kanban

Kanban yra produkcijos proceso valdymo metodas. Eiga orientuota vien tik pagal tikrąjį medžiagos sunaudojimą gaminimo ir naudojimo vietoje. Kanban įgalina sumažinti ankstesnių vietinių produktų kiekį ir produktų, kurie būtų sunaudoti sekančioje integravimo fazėje.“ (Šaltinis: http://de.wikipedia.org/wiki/Kanban)

Apie Kanban istoriją

Žodis Kanban kilęs iš japonų kalbos ir reiškia „žemėlapį“, „stalą“ arba „kvitą“. Principas žinomas dar ir kaip atnešimo, kvietimo arba stumimo principas. Ankstesnis Kanban buvo sukurtas Taichi Ohno 1947-ais metais, kuris su sistema reagavo į nepakankamą Toyota Motor Korporacijos produktyvumą palyginus su amerikiečių konkurentais. Jo idėja buvo produkciją organizuoti pagal supermarketo principą: kai tik vartotojas kažką paima iš lentynos, ši yra tučtuojau užpildoma.

Kanban principas yra suprantamas ir kaip reakcija į kliento poreikius, kurie turi naujus reikalavimus dėl produkcijos greičio, tiekimo pasirengimo ir santykių su tiekėjais. Kanban metodas pakeitė ligšiolinius produkcijos metodus ir buvo įvestas daugybės japonų įmonių, jų tarpe ir Toyotos. 1970-ais metais sistema buvo įvesta ir Vokietijoje ir JAV. (Palyginti: http://de.wikipedia.org/wiki/Kanban#Historische_Entwicklung)

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

Planuojate vertingus pokyčius savo organizacijoje?

Susisiekime

Scrum kolektyvas

Tikslingas darbas. Sprinto pradžioje nustatomi atitinkami sprinto tikslai, kurių reikia būtinai laikytis ir kurie yra stebimi viso sprinto metu. Taip vadinamos išsekimo diagramos pagalba galima sekti projekto eigą kasdien. Sprinto pabaigoje turi būti pateikta veikianti ir pratestuota programinė įranga, kurioje abejotinu atveju geriau praleidžiama kokia funkcija. Tačiau parengtos funkcijos turi kaip galima geriau ir be klaidų veikti, kad būtų galima testuoti realybėje.

Suspausti kolektyvai. Kadangi Scrum pirmoje vietoje yra kolektyvas ir kolektyvo mintis dominuoja visur, kolektyvas turėtų pagal galimybes sėdėti vienoje patalpoje, kad optimaliai paremtų komunikaciją ir Mes-Jausmą. Padalinti Scrum kolektyvai iš principo irgi egzistuoja, tačiau daugiausiai naudos yra iš suspaustų kolektyvų.

Vengti Scrum kolektyvo permainų. Kaip jau daug kartų minėta, Scrum privalumai ir stiprybės atsiskleidžia kolektyve ir nuolatiniame kolektyvo narių bendradarbiavime. Todėl reikėtų vengti Scrum kolektyvo permainų Scrum projekto metu. Ypač dėl pastovumo Scrum kolektyvas gali nuolat atsiskleisti ir pagerinti darbą kolektyve.

Susikoncentruoti ties kokybe. Savarankiškumas taip pat „tiekiamos programinės įrangos“ tema yra Scrum pirmoje vietoje. Tai nereiškia nieko kito, kaip kad tiekiami rezultatai sprinto metu yra atitinkamai testuojami ir gerinami, kad pateikti geriausią ir galutinį rezultatą. Į tai turi būti atsižvelgta sprinto planavimo metu, kad įgyvendintos priemonės dar galėtų būti užtektinai pratestuotos. Atskiri testavimo kolektyvai Scrum nėra numatyti, kadangi rezultatai to nereikalauja.

Š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

Patarimai Scrum planavimui

Jokio išsamaus planavimo / pasiruošimo. Scrum perdėtos pasiruošimo fazės yra nereikalingos. Vietoj to reikėtų bandyti, kaip galima greičiau pradėti įgyvendinimą ir naudoti nuolatinius atsiliepimus sprintų apžvalgos tolesniam vystymui ir pagerinimui. Netgi produkto neatliktų darbų sąrašas gali pagal poreikį būti sukurtas po pirmo sprinto pradžios.

Nesusikoncentruoti ties priemonėmis, kurios supaprastina Scrum procesą. Dažnai yra bandoma iš anksto (dar prieš įsisavinus Scrum) rasti atitinkamas programinės įrangos priemones, kurios atspindi Scrum procesą ir supaprastina jį. Pradžiai užtenka tušinukų ir popieriaus, kadangi pradžią su jais dažnai galima pavaizduoti netgi paprasčiau ir greičiau.

Kasdienis Scrum – trumpai ir aiškiai! Kasdienis Scrum susirinkimas neturi būti skirtas tam, kad būtų aptartos didelės problemos arba sunkumai ir ieškomi sprendimų būdai. Vietoj to susirinkimas turėtų būti trumpas ir aiškus. Probleminės diskusijos turėtų būti vedamos su atsakingais asmenimis pabaigoje atskirai. Scrum meistras stebi diskusiją ir pasirūpina tuo, kad viskas vyktų kaip galima kryptingai.

Savarankiškas darbas. Scrum kolektyvai dirba patys save organizuodami ir pasirūpina užduotimis savarankiškai. Užduočių priskyrimas yra nebūtinas ir dažniausiai kontraproduktyvus.

Scrum meistras dirba kartu. Scrum meistras gali būti pavadintas Scrum kolektyvo koučeriu, kuris pasirūpina tuo, kad Scrum procesas funkcionuotų kaip galima sklandžiai, o kolektyvas susikoncentruotų ties įgyvendinimu. Aktyvus dalyvavimas projekte yra nebūtinas ir turėtų būti bet kokiu atveju vengiamas. Tas pats galioja techniniams nurodymams, kurių Scrum meistras turėtų būtinai vengti.

Š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

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

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