Straipsniai

Kanban privalumų apžvalga

Kanban galima pritaikyti įvairiose srityse ir naudotis principu gali tiek mažos agentūros ir startuoliai, tiek tradicinės MVĮ, didesnės interneto platformos bei tarptautinės įmonės.

Skaidrumas. Problemų ir darbų pavaizdavimas ant Kanban lentos garantuoja geresnę apžvalgą apie projekto pažangą, taip galima geriau nustatyti aktualias problemas.

Greitas užduočių apdorojimas. Riboto bilietų skaičiaus apdorojimas veda link trumpesnių darbo paketų trukmių.

Įvairialypis panaudojimas. Kanban galima panaudoti ne tik vien programinės įrangos kūrime. Principas tikslingai ir efektyviai veikia ir kitose srityse, kaip pavyzdžiui remontas, sistemos administracija, marketingas arba pardavimai.

Greitas įvedimas. Kanban įvedimas yra iš patirties susijęs su mažai pasipriešinimo. Kanban yra lengvai suprantamas ir visiems dalyvaujantiems priimtinas.

(Šaltinis: http://www.it-agile.de/wissen/methoden/kanban/)

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

Planuojate vertingus pokyčius savo organizacijoje?

Susisiekime

Taip veikia Kanban

Svarbi Kanban užduotis yra parodyti turimas problemas ir darbus ir juos vizualizuoti. Svarbią rolę atlieka taip vadinama Kanban lenta, kuri pavyzdžiui gali būti sudaryta iš baltos lentos, kortelių ir lipnių lapelių. Kiekviena užduotis pavaizduojama ant kortelės ar pan. Šio metodo privalumas yra padidintas skaidrumas dirbant su projektais. (Palyginti: http://www.it-agile.de/wissen/methoden/kanban/). Kanban orientuojasi į Lean principus ir yra paremtas Pull principais (Pasiėmimo principas), kurių metu darbas nėra dalijamas vadovo, o darbuotojai arba kolektyvo nariai savarankiškai pasiima savo darbą. Šis yra tvirtinamas ant Kanban lentos su taip vadinamomis Kanban kortelėmis.

Užduotys keliauja iš kairės į dešinę kol atkeliauja iki skilties „Baigta“. Skiltys gali būti suderintos su atitinkamais reikalavimais. Kanban teikia gana mažai nurodymų ir labai prisitaiko prie atitinkamų individualių poreikių, kas liečia programavimo procesus, roles, tiekimo planavimus ir t.t. Darbo progresas – paraleliai vykstančios užduotys – apribojamas, kad būtų sumažintas kelių užduočių atlikimas vienu metu, o užduotys atliekamos tikslingiau. Kanban centrinis taškas yra Tėkmės-Principas. Bilietai turi tolygiai ir kuo trumpesniu laiku eiti per sistemą (http://www.it-agile.de/wissen/methoden/kanban/).

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

Planuojate vertingus pokyčius savo organizacijoje?

Susisiekime

Kanban projektuose

Kanban ir Scrum pritaikomi skirtinguose projektuose. Kanban priešingai nei Scrum yra metodas, kuris turi garantuoti nepertraukiamą darbo eigą. Tam visos numatytos užduotys ir procesai vizualizuojami su lentos pagalba, kuri yra padalinta į eiles ir skiltis. Ant lentos randasi užduotys bilietų forma. Kiekviena skiltis reprezentuoja vieną darbo žingsnį ir projekto kolektyvas gali bet kuriuo metu pasižiūrėti į užduoties statusą. Tikslas yra, kolektyvo neapkrauti skirtingomis užduotimis, labiau užtikrinti koncentruotą darbą ties viena užduotimi („Riboto darbo progresas“). Taip garantuojamas vienodas bilietų apdorojimas be ilgų laukimo laikų ir blokadų. Centrinis aspektas yra Tėkmės-Mintis. Kanban vizualizuoja aktualų procesą, tačiau nieko nekeičia.

Kanban yra agile metodas, kaip evoliuciškai pravesti menedžmento pasikeitimus. Procesai pažingsniui yra optimizuojami ir gerinami. Keičiant mažesnius aspektus, sumažinama kiekvienos priemonės rizika. Kanban privalumas yra ir mažesnis dalyvaujančių pasipriešinimas. (Palyginti: http://www.itagile.de/wissen/methoden/kanban/)

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

Planuojate vertingus pokyčius savo organizacijoje?

Susisiekime

Kanban programinės įrangos kūrime

Deividas J. Andersonas perdarė pagrindinę Kanban idėją ir pritaikė ją programinės įrangos kūrimo poreikiams. Rezultatas yra pažangus procesas, kurio metu nuolat gerinami ir optimizuojami darbo metodai. Šiuo požiūriu visą laiką derinamasi prie esamos situacijos. Kanban Privalomos-Būsenos nėra. Kanban kolektyvai laikosi sekančių principų:

Darbo eigos ir darbo vizualizavimas.

DP ribojimas (DP = Darbo Progresas, darbo eiga).

Darbo eigos valdymas ir matavimas.

Proceso taisyklės turi būti aiškios.

Pagerinimas patikimais modeliais ir moksliniais metodais.

(Šaltinis: http://www.heise.de/developer/artikel/Software-Kanban-im-Einsatz-1235465.html)

Tikslas yra integruoti Kanban mechanizmus į sistemą, kuri leidžia nuolatinius pagerinimus ir pakeitimus. Proceso eigoje kolektyvo nariai taip gali prisidėti ir optimizuoti darbo eigą. Žmonių galvose turi pirmiausia atsirasti Kaizeno-Mintis. Pagal ją pasikeitimai vyksta ne žmoguje, o žmogau pastangomis.

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

Planuojate vertingus pokyčius savo organizacijoje?

Susisiekime

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